re: Hiring process of your dreams VIEW POST

VIEW FULL DISCUSSION
 

Hey there. My two cents:

For junior devs I'd only test their motivation and if they align with company culture. Talk about programming, ask questions (fundamentals) and look how he/she reacts to them especially when they don't know the answers. You'll see a pattern right there.

As for experienced ones - imho, it is very important to ask why they're changing jobs, also, find out if the candidate still has the passion for programming (doesn't mean he/she still does). Basically, test for motivation to learn/improve themselves. Then test for culture and only then give 15 to 45 mins of coding. You don't need these stupid whiteboards, meaningless hackaday project sessions after coding let seniors talk to them, talk about a project you're working on, see if the candidate asks any questions. This last one is very important. It not only shows that the candidate is interested but also shows his experience.

These are very broad strokes but the main idea is that, in my opinion, testing for motivation, culture and character (discipline, no bullshit attitude, curiosity, etc) will yield better colleagues than them passing some algorithm test. As far as coding skills go - not everyone is equal and everyone has their style, I would definitely leave quite some space for improvement (this is what code review is for actually) if I see the fire in candidate's eyes.

And that's it folks. Cheers! :)

 

I once interviewed a coder for an entry-level data entry position (he needed a job and had limited legal options) who, when I explained the bad data he'd been cleaning up, asked me what approaches I'd looked into for preventing the bad data.

I didn't end up hiring him, but did get a chance to brag on him to my boss when we ran into him over lunch, and my boss got him a way better job that's led to him being one of the most valuable new employees at my workplace.

Questions to other coders most definitely do show quality of thinking!

code of conduct - report abuse