5 ms·

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our t

We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask for 100 lines of code and not more than 2 hours. They take as much calendar time in days as they need, most have full time jobs, and let us know when you're done. The candidate then comes back, typically in 2 to 7 days and hosts a code review in front of our team. I give strict instructions before hand: The purpose of the review is to learn how they thought through the problem and how they solved it, not to criticize their style and approach. 3. If we decide we like them to this point, the third interview is with managers from other functions. How well does the candidate communicate, come across to non-developers, express interest in the company and role, etc. It's a check point to look for concerning weaknesses, as well as get buy in from the broader organization. We like this approach because it allows the candidate to code in a much more natural environment. They can take the time they need and comfortably solve. No one spends their professional career coding on a white board. This approach so far has yielded excellent results. We ask developers how much time they took in the programming task and why they chose the one they solved. The programming task is telling, not in the quality of their code and how long they took, but how much did they get into it? We have had the range from candidates who did not complete it at all and opted out, to candidates who stumped 40 year veterans with elegant code. In every case, we learn how well they can express their thoughts, and importantly, their level of love for the discipline. This is as important to me as any other attribute.

maxwelldone 6y ago
I love this approach. As someone who generally asks a lot of questions, your first round would give one a good idea if it's worth proceeding to other rounds or not. BTW, are you guys hiring?
ammanley 6y ago
Sounds like a place worth working for
BrissyCoder 6y ago
This rules... I advocated for a similar approach with take home tests at my last position. I used this on candidates and never had a bad hire. Unfortunately this approach was overridden by more senior management in favor of on-site technical tests (programming tasks, IQ and whiteboard problems). The prevailing wisdom was that you couldn't trust people not to cheat on take home programming tasks - a proposition that I find entirely ridiculous and in any case would be quickly mitigated by the on-site code review you use.
- nomel 6y ago
  We had a long stretch of resumes that were exaggerated, borderline lies, causing a bunch of wasted time, so we had to come up with a pre-screen. The fact that the resumes were basically false meant that trust probably wasn't something to rely on for a pre-screen. So, we came up with an easy 5 minute question, which seemed reasonable. So far, our 5 minute test has failed spectacularly. Knowing what a good answer is requires too much interpretation of the subtleties of the answer, so it's not very useful for the managers who may not be the greatest at coding. I think we'll tweak the question a bit, but we're kinda stuck. How do others handle pre-screening?
mlthoughts2018 6y ago
Sorry but no way. You send me a programming task you expect me to do in my personal time, and you’ve just revealed you practice extreme ageism, discriminate against parents or people with elder care responsibilities, and many more negative and disrespectful signs. It shows excessive entitlement on your side, indicating a poor working environment. Out of consideration for finding a healthy, reasonable employer, I would reject you immediately, and so should everyone. It’s not a matter of some candidates liking your process and not others - the process you describe solely perpetuates destructive and exploitative interview behaviors for everyone, even people free of outside responsibilities who can have the luxury to make room for a multi-hour take home exam within a month or two of being assigned.
- 11thEarlOfMar 6y ago
  The median age of my team is 60. We give candidates all the time they need, as in a week or more. We explain the process when we ask them to interview, and if they prefer a white board interview instead of a take home, we can do that. So far, no one has taken that option. You're right that some people object to being asked to do programming (though none that we've asked to come in have objected) and some people think they should be compensated, which we don't do. I point out that the code review, for example, takes my team of 4-5 engineers 1-2 hours of their time, so we are matching the candidate's time spent with my team's time. In any case, it's certainly not for everyone, and we're flexible.
  - mlthoughts2018 6y ago
    None of this makes it better. “We give candidates all the time they need” (which you suggest is something insanely short notice, like 1-2 weeks) is not an answer. What about people who cannot give you time outside of 1-2 hour blocks within business hours of a weekday, as in they can never work on your assignment apart from that. You’re just openly admitting that you won’t assess that whole cohort of humans. I urge you to reconsider. You are determining a process that you happen to fancy, maybe because it makes you feel like you’re a visionary of interview process or you’re going against the trend, but you’ve got blinders on about your commitment to this and what it means for people who just happen to have obligations. The standard whiteboard hazing trivia is bad enough, and 4+ hour long marathon on-sites that require weeks of study and taking vacation days just to interview are ridiculous. But your method is not much better. You’re still perpetuating this myth that somehow, unlike virtually every other profession on the planet, software engineering requires intense examination of on-the-spot demonstrated skill, rather than simple conversation probing past experience and domain knowledge. We just do interviewing completely ass backwards in software. Part to assert gatekeeper superiority, part to judge fealty. It’s just bananas.
confidantlake 6y ago
Unfortunately I have done take-home assignments and then been ghosted by companies. If I am a candidate I don't know if you are going to ghost me or review my submission. It is tough because I do think this is a better signal than whiteboarding, but there is an asymmetric time commitment.
- 11thEarlOfMar 6y ago
  I can't speak for other companies, but the point at which candidates do the programming task is after they've come in and met 3 or 4 of us. It would be really awkward in my opinion to then not have them back after they've completed it. By that point, we really want to have them in and we hope they do really well. We have 4-5 engineers in the code review for 1-2 hours. That time more than matches the candidate's commitment, which I think is equitable.
  - confidantlake 6y ago
    I like your approach. Seems to solve the async time commitment problem. Also the candidate doesn't have to do the takehome if it seems like an obvious mismatch when they come in and meet the team.

maxwelldone 6y ago

I love this approach. As someone who generally asks a lot of questions, your first round would give one a good idea if it's worth proceeding to other rounds or not. BTW, are you guys hiring?

ammanley 6y ago

Sounds like a place worth working for

BrissyCoder 6y ago

This rules... I advocated for a similar approach with take home tests at my last position. I used this on candidates and never had a bad hire. Unfortunately this approach was overridden by more senior management in favor of on-site technical tests (programming tasks, IQ and whiteboard problems). The prevailing wisdom was that you couldn't trust people not to cheat on take home programming tasks - a proposition that I find entirely ridiculous and in any case would be quickly mitigated by the on-site code review you use.

nomel 6y ago
We had a long stretch of resumes that were exaggerated, borderline lies, causing a bunch of wasted time, so we had to come up with a pre-screen. The fact that the resumes were basically false meant that trust probably wasn't something to rely on for a pre-screen. So, we came up with an easy 5 minute question, which seemed reasonable. So far, our 5 minute test has failed spectacularly. Knowing what a good answer is requires too much interpretation of the subtleties of the answer, so it's not very useful for the managers who may not be the greatest at coding. I think we'll tweak the question a bit, but we're kinda stuck. How do others handle pre-screening?

mlthoughts2018 6y ago

Sorry but no way. You send me a programming task you expect me to do in my personal time, and you’ve just revealed you practice extreme ageism, discriminate against parents or people with elder care responsibilities, and many more negative and disrespectful signs. It shows excessive entitlement on your side, indicating a poor working environment. Out of consideration for finding a healthy, reasonable employer, I would reject you immediately, and so should everyone. It’s not a matter of some candidates liking your process and not others - the process you describe solely perpetuates destructive and exploitative interview behaviors for everyone, even people free of outside responsibilities who can have the luxury to make room for a multi-hour take home exam within a month or two of being assigned.

11thEarlOfMar 6y ago
The median age of my team is 60. We give candidates all the time they need, as in a week or more. We explain the process when we ask them to interview, and if they prefer a white board interview instead of a take home, we can do that. So far, no one has taken that option. You're right that some people object to being asked to do programming (though none that we've asked to come in have objected) and some people think they should be compensated, which we don't do. I point out that the code review, for example, takes my team of 4-5 engineers 1-2 hours of their time, so we are matching the candidate's time spent with my team's time. In any case, it's certainly not for everyone, and we're flexible.
- mlthoughts2018 6y ago
  None of this makes it better. “We give candidates all the time they need” (which you suggest is something insanely short notice, like 1-2 weeks) is not an answer. What about people who cannot give you time outside of 1-2 hour blocks within business hours of a weekday, as in they can never work on your assignment apart from that. You’re just openly admitting that you won’t assess that whole cohort of humans. I urge you to reconsider. You are determining a process that you happen to fancy, maybe because it makes you feel like you’re a visionary of interview process or you’re going against the trend, but you’ve got blinders on about your commitment to this and what it means for people who just happen to have obligations. The standard whiteboard hazing trivia is bad enough, and 4+ hour long marathon on-sites that require weeks of study and taking vacation days just to interview are ridiculous. But your method is not much better. You’re still perpetuating this myth that somehow, unlike virtually every other profession on the planet, software engineering requires intense examination of on-the-spot demonstrated skill, rather than simple conversation probing past experience and domain knowledge. We just do interviewing completely ass backwards in software. Part to assert gatekeeper superiority, part to judge fealty. It’s just bananas.

confidantlake 6y ago

Unfortunately I have done take-home assignments and then been ghosted by companies. If I am a candidate I don't know if you are going to ghost me or review my submission. It is tough because I do think this is a better signal than whiteboarding, but there is an asymmetric time commitment.

11thEarlOfMar 6y ago
I can't speak for other companies, but the point at which candidates do the programming task is after they've come in and met 3 or 4 of us. It would be really awkward in my opinion to then not have them back after they've completed it. By that point, we really want to have them in and we hope they do really well. We have 4-5 engineers in the code review for 1-2 hours. That time more than matches the candidate's commitment, which I think is equitable.
- confidantlake 6y ago
  I like your approach. Seems to solve the async time commitment problem. Also the candidate doesn't have to do the takehome if it seems like an obvious mismatch when they come in and meet the team.