The way a company hires developers can say a lot about their culture. Is there a very strict HR followed process, tests and the type of those tests, culture-fit interviews, etc. While the point of all this is to test the candidate, it can give great insights to the other side of the table. In this competitive market, you can be sure that candidates are taking notes while being interviewed.
The concept of false positives
Tests are the gate to the company, however testing talent is hard. While you may keep some bad apples from joining your company you may loose some amazing people in the process; every test is flawed in some way and yours are too.
This article from Zack Holman relates exactly the issues with tests. If you are looking for product devs building CRUDs applications, you want to be sure your tests cover that and not just throw around a algorithms quiz.
Startup: We’re hiring people to reinvent and change the world!
Interviewer: Please shift this char onto this array.
— Zach Holman (@holman) December 29, 2015
Refining hiring
Becoming better at hiring is a refinement process, new managers will often make the same mistake and refine their process until they become better at it. For me, there is always 3 important areas I want to cover.
- Company fit
- Technical Expertise in the field we are hiring
- Can you cover the team over other areas
The company fit
Culture fit is done through a first interview over lunch and beer, on-site, or by Skype. We talk about
- What the company did before
- What we do now
- What we want to do in the future
- How we work
- Our challenges
- Current Tech stack
Then we ask more about the person, brief review of what he did before, what he is looking for in the next position. Then we ask about one project he is proud of; I want to know what makes him excited about this project and how he solved the problems in it.
There are two goals with this interview. I want the candidate to understand our company as much as possible to be sure he want to work with us, and I want to know if the person is a good fit with our team, what he can bring to the table that our team is missing. That’s great insights for the candidate too, as much as you want to tell me what you want to do, you should focus on how you see helping the company and the people in front of you.
The tests
There is no better way to see how a dev works than by looking at his code. Unless the applicant has made strong open source contributions, you will have to create a test for that. You can ask technical questions, but asking questions will never talk more than code.
The tests are two folds. The first one is to do something related to the open position at home. For a front-end developer, it could be to build a UI with Backbone or React to list restaurants near you. A back-end test could be to write an API class.
You should focus on one task but also give hints on how to take the test further, like writing unit tests, better UI, other features etc. Remember that your goal is to get as much information possible making the test as short as possible.
The candidates will do the minimum, and that’s ok. However when someone do more you should take mention, it’s possible this person is excited about the position, this is often reflected in the person behavior at the on-site interview.
On-site coding
The last thing I find interesting doing is doing a small session of pair coding. Again we are not talking about looking at a b-tree on a whiteboard or something like that. We open our codebase and work on a new feature or bug currently in the sprint. This helps us understand how fast this person can pick up our code.
On the candidate side, it gives him a great preview of our code base, processes, interaction with the team.
What’s next
Hiring is hard, the important thing is never to stop refining your process.
… we had a group called "Bar Raisers" who mainly torpedoed candidates that lacked "CS Fundamentals". We passed on so many good people.
— Trek Glowacki (@trek) January 26, 2016