Skip to content
This repository has been archived by the owner on Nov 15, 2019. It is now read-only.

Project Summary and Progress

John Van Pham edited this page Oct 11, 2017 · 8 revisions

Project Summary/Requirements

  • The tool should allow a non-technical HR recruiter to easily (and automatically) create a new private GitHub repo with the candidate added as a collaborator (give the candidate permissions to make commits and upload their submission).
  • The repo should be independent in that candidates should not be able to view others’ code. Optionally, there could be a ‘default’ repo containing a technical problem to clone for each new repos, which can then be modified as needed.
  • Once the candidate has communicated to the recruiter that they have finished, the recruiter should also be able to add technical reviewers to the repositories so that submissions can be reviewed once the applicant has completed the exercise. Reviewers should be able to give feedback on the candidate through the tool, which can then be viewed by the recruiter for the final decision.
  • Security is important and only recruiters should be able to access the tool.

Typical workflow of this Github Recruitment Tool

The recruiter is responsible for assessing the suitability of new candidates/applicants for vacant developer positions at MYOB. In addition to interviews, these candidates must be assessed for their technical skill. This technical assessment can be done consistently through our tool, meeting the customer's (MYOB's) project requirement. A typical workflow is as follows:

  1. The recruiter logs into the website to gain full access to the tool.
  2. The recruiter adds a new candidate using the "New Candidate" button. This will create a new candidate in the database, email the candidate, and create a Github Repository with a forked problem (Github itself will also email the candidate an invitation to this repository).
  3. The candidate starts coding on the problem. Note: By coding using Github, MYOB will be able to see the candidate's coding style and techniques as well as skill by tracking their commits in addition to their actual code solution.
  4. After the time allowed for coding (for example one week) elapses, the recruiter will mark the candidate as done. This will remove them from the repository (as per user story given).
  5. The recruiter will now send an email to the Development Manager by clicking "Email Manager". This email contains instructions which the Dev Manager will forward to all potential Technical Reviewers who are interested in assessing the performance of the candidate and providing feedback. The email will include two links for the Technical Reviewers, one to add themselves as a Reviewer (which will add them into the system and add them as a collaborator to the github repo) and the second link to provide their feedback about the candidate.
  6. Technical Reviewers assign themselves to the candidate (limit of 3). After reviewing they provided feedback, whenever there is new feedback the recruiter is emailed. The progress status of each candidate is updated accordingly to show how many feedback responses have been received.
  7. Once the recruiter has finished perusing the technical feedback and the candidate is either hired or rejected, the recruiter can then delete the candidate from the system. (For future development we suggest an archived page, there was not enough time to implement this).

Completed User Stories (14):

  • P1. Investigate whether GitHub provides APIs to create and manage repositories
  • P2. As a Recruiter, I want to clone a GitHub repository containing a coding problem and the candidate, so that submission formats are consistent.
  • P3. As a Recruiter, I want to be able to easily add candidates as collaborators to the cloned repositories so that the candidate can work on his or her submission.
  • P4. As a Recruiter, I want to be able to email reviewer(s) and give them access to the candidate's code with a * multi-use feedback form, so that I don't have to manually collect this information.
  • P5 As a Recruiter, I would like to notify the candidate with instructions about the coding problem prior to being added to the repo, so that the candidate knows what to do after receiving the problem.
  • P6. As a Recruiter, I want to be able to do the above in a graphical, user-friendly tool, so that I don't need to learn GitHub.
  • P7. As a Techical Reviewer, I would like to be able to give specific feedback for each solution, so that I can inform the recruiter how technically capable the candidate is.
  • P8. As a Technical Reviewer, I would like to have the visibility of the feedback restricted, so that I can restrict candidate from reading comments that are for internal staff only.
  • P9. As a Technical Reviewer, I would like to send out the feedback to recruiter, so that I can inform them as soon as I am done.
  • P10. As a Recruiter, I would like to be able to track a Candidate's applications progress so that I know who to follow up on.
  • P11 As a Reviewer, I want the candidate's access to the repo removed before I start reviewing, so that I don't see new changes as I'm reviewing.
  • P12. Setting up the infrastructure and hosting the website so that it can be accessed by reviewers who are not logged in.
  • P13 As a Recruiter, I want to be able to mark the candidate when they are done, so it is obvious when I need to add send out emails to dev managers.
  • P14 As a Development Manager, I would like to be notified when there is a candidate to review, so that I can invite reviewers to review their code.

Passed Acceptance Test:

  • For P1: You have verified that the Github APIs allow you to clone a repository, set permissions and add collaborators.
  • For P2: Recruiters are able to clone an existing Github repository with a coding problem in it.
  • For P3: Recruiters can add a candidate as a collaborator per cloned repository.
  • For P3: Each repository should be easily identifiable as the candidate's.
  • For P4: Recruiters can add reviewer(s) to a candidate's repository with permissions which allow reviewer(s) to clone the code.
  • For P4: Reviewer(s) receive an email link to the repository and a form to fill out their review.
  • For P5: Candidate receives email prior to receiving the Github invitation with a predetermined template
  • For P6: The recruiter can clone repositories for each candidate, add them as collaborators to their respective repositories and assign reviewers.
  • For P7: Reviewer can fill out a form and submit it.
  • For P7: Form contains sections on Solution Design, Separation of Concerns, Solution Readability, Knowledge of Technology, Test Comprehensiveness, Test Quality, Feedback for HR.
  • For P7: Feedback for HR should have a text box for recommended skill level (Do no pursue, Junior, Intermediate, Senior)
  • For P7: Each section should have a text box for comments and a scale from 1-5, 1 being novice and 5 being expert.
  • For P8: Candidates and anyone not involved with the candidate's review process cannot see the feedback given about their code.
  • For P9: The technical reviewer can notify the recruiter when they are have collated all the feedback from other reviewers and have made a verdict.
  • For P10: Recruiters can see which stage each candidate is at (Doing problem, Finished problem, Being reviewed, Finished review)
  • For P10: Recruiters can see how long it has been since progress has been made.
  • For P11: Candidate can't access the repository once reviewers have been added.
  • For P12: The app is hosted on AWS.
  • For P13: Candidate list should display the status of each candidate's progress.
  • For P13: The button for marking a candidate's status as done should change based on the status.
  • For P14: Recruiter can send an email invitation to development managers with a link for people to opt-in as reviewers.

Failed Acceptance Test (None)

Velocity

At the end of each sprint, the team adds up effort estimates associated with user stories that were completed during that sprint. This total is called velocity.

Estimated Velocity:

We have a total of 11 user stories, each with 3 points. Hence the total number of point for this project is 33. The project is divided into 8 sprints, hence we projected to achieve 4-5 points after each sprint.

Actual velocity:

Upon finishing 4 sprints, we have achieved a total of 12 points, 4 points for each sprint. Hence, the actual velocity is the same as the estimated velocity and we are on track on finishing the project.

Velocity table

Sprint Estimated Velocity Actual Velocity
0 42 42
1 34 36
2 26 26
3 18 16
4 8 6
5 0 0

Burndown chart

Burndownchart