As part of my current interest in hiring, I realised that I have very little idea of how to interview people who have no background in programming for software developer positions (with the intent of training them on the job).
The best I can do is think back to when I first interviewed for a programming job – there were some good interview questions, which largely consisted of idealized descriptions of algorithms (I don’t want to share them because as far as I know the companies in question are still using them and I don’t want to spoil their interview process). They seemed like a pretty good test at the time, but I have no idea how much I benefited from my background in mathematics.
Any tips?
If you’re willing to share specific interview tasks with me, that would be great. If you don’t want to do that in public my email is, as always, [email protected]. General advice is also appreciated.
Thanks.
I’ve never been an interviewer, but since so much of a software developer job is about how well you collaborate with other people, I would ask them questions about working with people in whatever job or jobs they’d already been doing. Also, trying to figure out whether they have the mindset of going and reading documentation and/or asking other people, instead of going into brain-lock, when they need to do something new. These are things that aren’t just about programming.
I’ve never thought asking people to write code on the whiteboard or solve puzzles was very useful, so I don’t think that not being able to do that for someone who hasn’t programmed before is losing you very much anyway :-)
I was actually imagining hiring people straight out of university, which makes using previous jobs somewhat difficult.
RE puzzle solving: I’m not sure. I’ve found coding tests to be extremely good indicators of candidate quality for experienced candidates, and if the puzzle solving is close enough to a programming test with the language details stripped away I think it’s probably a reasonable thing to do.
The point about them knowing how to seek further information rather than going into brain lock is a really good one. Thanks. I wonder how to test for that.
As a recent grad I was interviewed a fair bit, and as a manager I’ve done a fair bit of interviewing, sometimes of very junior engineers or people still studying. It seems that a lot of companies do use “logic” puzzles / brain-teasers – I’ve noticed a lot of repetition and I don’t think the set of popular problems is actually very big.
Personally, I’ve not had much luck using logic puzzles with candidates because I find it hard to tell the difference between “brain-lock” and people just clamming up under the fairly surreal pressure of being asked to solve an “impossible” problem in front of an experienced engineer. But if you’ve got a candidate who is obviously relaxed and confident, they can be a useful exercise.
Assuming a mathematical background, I’ve had better luck with non-obvious extensions of basic maths / probability questions. Drawing white/black counters from a bag, reasoning about boolean functions. It’s easier to guide even nervous candidates through these sorts of problems, and it’s a good way to see if they can apply principles that they understand to solve new problems rather than simply regurgitate learned answers.
But I have to say, even with all that, my experience has been patchy. It’s pretty easy to filter out the people who are obviously unsuitable, but I’ve ended up (on two or three occasions) feeling only marginally enthusiastic about people who have turned out to be exceptionally valuable coworkers.