Assumptions:

1. An employee will always belong to the same job group. However, amount paid is calculated appropriately if an employee has different job groups in the time report
2. For a given employee on a particular day, hours worked will always be upto 24 hours
3. Date format will remain same in the CSV - d/mm/yyyy
4. All fields and their values will not have leading and trailing spaces
5. There are only two job groups and their hourly rates are fixed: A - $20, B - $30
6. There will be minimal traffic to the application. However, if in case the traffic is huge, we can persist the payroll report

Design decisions:

1. Designed only two tables - job_groups and time_reports.
2. I haven't created a separate table for employee as it has only one attribute. Therefore, no need to check for uniqueness of Emplyee ID.
3. Rails root url is set to time_repots page. This page has option to upload a CSV Time Report and link to view the Payroll report.
4. Used Service objects such that Controller is thin.
5. Services are placed under app/ rather than lib/ as they are application specific.
6. Used RSpec for testing.
7. Used SimpleCov for measuring test coverage of the application.
8. As per SimpleCov report, 93.84% of code is covered

Instructions on how to build/run your application

prerequisite

1. RVM (non mandatory)
2. Ruby 2.3.0
3. Rails 4.2.0
4. Bundler

Installation Steps

1. If RVM is available
   • Execute rvm gemset create payroll to create gem set specific to app.
   • Execute rvm use ruby-2.3.0@payroll to select the gem set.
2. Execute bundle install to install the gems required by the application.
3. Execute rake db:migrate to create necessary tables
4. Execute rake db:seed to create job groups "A" and "B"
5. Execute bundle exec rspec for test report
6. Execute rails server to run application in local server
7. Application can be accessed by url: http://localhost:3000/
8. Other URLs in application:
   • Upload CSV: http://localhost:3000/ & http://localhost:3000/time_reports
   • List of Job Groups: http://localhost:3000/job_groups
   • Payroll report: http://localhost:3000/payroll_reports

A paragraph or two about what you are particularly proud of in your implementation, and why

Application is divided in two parts. One is to parse the Time Report CSV file and persist it to TimeReport table and the other one is to pull the data from TimeReport, process it and display as Payroll report. This seggregation allows the partner to choose between either uploading the CSV files or viewing the Payroll report. Moreover, application uses Services such that controllers are slim down.

Wave Software Development Challenge

Applicants for the Software developer role at Wave must complete the following challenge, and submit a solution prior to the onsite interview.

The purpose of this exercise is to create something that we can work on together during the onsite. We do this so that you get a chance to collaborate with Wavers during the interview in a situation where you know something better than us (it's your code, after all!)

There isn't a hard deadline for this exercise; take as long as you need to complete it. However, in terms of total time spent actively working on the challenge, we ask that you not spend more than a few hours, as we value your time and are happy to leave things open to discussion in the on-site interview.

Please use whatever programming language and framework you feel the most comfortable with.

Feel free to email [email protected] if you have any questions.

Project Description

Imagine that this is the early days of Wave's history, and that we are prototyping a new payroll system with an early partner. Our partner is going to use our web app to determine how much each employee should be paid in each pay period, so it is critical that we get our numbers right.

The partner in question only pays its employees by the hour (there are no salaried employees.) Employees belong to one of two job groups which determine their wages; job group A is paid $20/hr, and job group B is paid $30/hr. Each employee is identified by a string called an "employee id" that is globally unique in their system.

Hours are tracked per employee, per day in comma-separated value files (CSV). Each individual CSV file is known as a "time report", and will contain:

1. A header, denoting the columns in the sheet (date, hours worked, employee id, job group)
2. 0 or more data rows
3. A footer row where the first cell contains the string report id, and the second cell contains a unique identifier for this report.

Our partner has guaranteed that:

1. Columns will always be in that order.
2. There will always be data in each column.
3. There will always be a well-formed header line.
4. There will always be a well-formed footer line.

An example input file named sample.csv is included in this repo.

What your web-based application must do:

We've agreed to build the following web-based prototype for our partner.

1. Your app must accept (via a form) a comma separated file with the schema described in the previous section.
2. Your app must parse the given file, and store the timekeeping information in a relational database for archival reasons.
3. After upload, your application should display a payroll report. This report should also be accessible to the user without them having to upload a file first.
4. If an attempt is made to upload two files with the same report id, the second upload should fail with an error message indicating that this is not allowed.

The payroll report should be structured as follows:

1. There should be 3 columns in the report: Employee Id, Pay Period, Amount Paid
2. A Pay Period is a date interval that is roughly biweekly. Each month has two pay periods; the first half is from the 1st to the 15th inclusive, and the second half is from the 16th to the end of the month, inclusive.
3. Each employee should have a single row in the report for each pay period that they have recorded hours worked. The Amount Paid should be reported as the sum of the hours worked in that pay period multiplied by the hourly rate for their job group.
4. If an employee was not paid in a specific pay period, there should not be a row for that employee + pay period combination in the report.
5. The report should be sorted in some sensical order (e.g. sorted by employee id and then pay period start.)
6. The report should be based on all of the data across all of the uploaded time reports, for all time.

As an example, a sample file with the following data:

date	hours worked	employee id	job group
4/11/2016	10	1	A
14/11/2016	5	1	A
20/11/2016	3	2	B

should produce the following payroll report:

Employee ID	Pay Period	Amount Paid
1	1/11/2016 - 15/11/2016	$300.00
2	16/11/2016 - 30/11/2016	$90.00

Your application should be easy to set up, and should run on either Linux or Mac OS X. It should not require any non open-source software.

There are many ways that this application could be built; we ask that you build it in a way that showcases one of your strengths. If you enjoy front-end development, do something interesting with the interface. If you like object-oriented design, feel free to dive deeper into the domain model of this problem. We're happy to tweak the requirements slightly if it helps you show off one of your strengths.

Documentation:

Please modify README.md to add:

1. Instructions on how to build/run your application
2. A paragraph or two about what you are particularly proud of in your implementation, and why.

Submission Instructions

1. Clone the repository.
2. Complete your project as described above within your local repository.
3. Ensure everything you want to commit is committed.
4. Create a git bundle: git bundle create your_name.bundle --all
5. Email the bundle file to [email protected]

Evaluation

Evaluation of your submission will be based on the following criteria.

1. Did you follow the instructions for submission?
2. Did you document your build/deploy instructions and your explanation of what you did well?
3. Were models/entities and other components easily identifiable to the reviewer?
4. What design decisions did you make when designing your models/entities? Are they explained?
5. Did you separate any concerns in your application? Why or why not?
6. Does your solution use appropriate data types for the problem as described?