First-off: the second, “hard”, question is actually far easier than it may seem at first glance¹.

Not only that, but I think presenting — even more junior — candidates with hard problems, is great, for a number of reasons.

For one — even though you may be recruiting for a Junior Developer, to do Junior Developer things for Junior Developer money, you want to try and get an appreciation for which candidates have the potential to grow, and how fast.

The purpose of the technical/coding interview isn’t just to have a pass/fail based on whether or not the candidate gets the “right” answer, or even to score them on how close they get, it’s to give them the opportunity to show you what they know and how they go about applying it. Their approach to problem solving, and how they communicate their process is what you’re really looking at.

If you only present “easy” questions to candidates for your Junior Developer role, if you don’t stretch them, if you don’t give them that opportunity to shine, you could be passing over a lot of top talent because without holding their toes to the fire a little it’s harder to see the differences between them all

tl;dr

I don’t think of presenting “hard” problems to candidates as throwing roadblocks in their way, I think of it as giving them opportunities to show why they would be good hires.

_______________________________________________

[ 
[ 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0 ],
[ 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 1, 0 ],
[ 0, 1, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1 ]
]

Then you just need to trim the 0s from the beginning and end of each stratum, and count how many 0s remain trapped, e.g.:

[ 
[ 1 ], // 0 zeroes
[ 1, 0, 0, 0, 1, 1, 0, 1 ], // 4 zeroes
[ 1, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1 ] // 2 zeroes
]

I’m a Software Developer at Shuttlerock where I write mostly Ruby and Typescript. I also dabble in any language that takes my fancy.

I’m a Software Developer at Shuttlerock where I write mostly Ruby and Typescript. I also dabble in any language that takes my fancy.