Interview
This is our actual process to interview a candidate for any available position in the team, as front end developer, software engineer, full-stack developer, etc. The important thing in our process is simple, we’re looking for people who are smart and get things done, as Joel Spolsky says in The Guerrilla Guide to Interviewing.
“People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. People Who Get Things Done but are not Smart will do stupid things […]”
So, let’s use the time to interview wisely. Generally, the steps are the following.
Meeting the candidate
1) Someone schedules the interview. This means that there has already been the first approach and they talked about the company, the product, and what we are looking for. In short, the first filter has passed.
2) The second interview is technical. The idea is to take our exercises as a basis and read it together with the candidate. The plan is to propose ideas and solutions to the problem and then implement them. For example, for the backend test, there is an important point that mentions that the solution must be asynchronous, here we can ask:
- What does the term asynchrony refer to?
- What type of architecture do you think is appropriate?
The plan is to understand if the person has an idea of how to solve the problem (get things done) and proposes solutions (smart). This will also help the candidate to understand very well what is the objective to develop in the problem.
The time set aside is one hour, but ideally, it should last a maximum of 30 minutes. The remaining 30 minutes is to write comments regarding the interview.
It is important to tell the candidate that will have a period of one week to solve the problem, and it will be qualified based on the considerations of the problem and the points to be evaluated.
3) It is important to establish that if the link to the repository with the instructions is sent, a week will be counted. For example, if we are interviewing today (Wednesday) but the candidate can start working on the test on Friday, then the test will be sent on Friday and the due date will be until the following Friday. This consideration is important since it is possible that the candidate is in a difficult work period and needs a little more time to organize.
4) During the development of the test, the candidate would have answers. It is important to be aware of the mail to clarify them.
Reviewing the solution
When the candidate submits the solution, it is necessary to review the repository. It’s important to review based on the points that come in the description of the challenge. Depending on the result, a decision is made. For example:
- This is a link to the resolved challenge from a candidate.
- Based on our challenge, we’re going to evaluate if the work delivered satisfies the considerations described on the backend challenge.
- After reviewing the solution, we need to write feedback. Based on Points to Evaluate:
- Code: The project contains good syntax and the candidate used Rubocop. Some parts of the project contain old syntax. I can give him 8/10 points, generally.
- Use of third party API: FedEx gem is used correctly and is well defined.
- Git log: The messages are not clear.
- Tests: The project contains just two tests, but are clear and well defined.
- Based on Considerations:
- I don’t understand where is applied the asynchronous logic.
- The homologation of statuses is well defined in a dictionary.
- He used a retries policy to retry de API call.
- I can see a Factory Pattern that allows adding more carriers with effortless.
- Finally, send the feedback to the person who ask to you for the review.