3 ms·
There's some trade-offs here, because there does need to be some sense of how good a developer they are if you're hiring them as a developer: the distribution o
by PaulRobinson 9y ago
There's some trade-offs here, because there does need to be some sense of how good a developer they are if you're hiring them as a developer: the distribution of skills is so broad at each "level" (junior, mid, senior, principal), and cultures so different you need some way of understanding if they really do have 5 years experience of LanguageX, or 3 months of it repeated 20 times...
What I prefer to do is ask them to show me some example code they think is "good" (ideally their own, but perhaps from an open source project), and some that is "bad" (ditto), and write a paragraph or two on _why_.
Colleagues prefer to ask people to do coding exercises, and that's fine, I won't criticise, I've done it before, but I hate the fact we are asking people to do toy problems that don't represent real World problems.
My favourite process that I don't get to do much now (I have to conform to somebody else's policies these days), is just to sit and talk through a candidate's favourite project or problem.
Why did they choose that problem? What tools did they use? Did they consider alternatives? If it was a personal project did they write tests, and why/why not? If it was something they were paid to do, how did they input vs other people, etc.? Get a sense of them, try and build some empathy for what makes them excited.
Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app.
And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone.
All more useful to me and my assessment of somebody than asking them why manhole covers are the shape they are, how many windows there are in a nearby city or asking them to build a scaffold generated app that nobody would ever use.
- Cakez0r 9y ago> Why did they choose that problem? What tools did they use? Did they consider alternatives? If it was a personal project did they write tests, and why/why not? If it was something they were paid to do, how did they input vs other people, etc.? Get a sense of them, try and build some empathy for what makes them excited. > Get somebody in a room with a coffee and just listen to what makes them not shut up about some code they worked on. It can't be the be-all and end-all, but it's better than asking for another todo list app. > And then I also like to do an architectural thinking exercise. "Let's pretend we're building [well known piece of software] from scratch. What do we need to build, what do we need to think about?". Go through it, you draw their idea on the whiteboard, not them. Ask which technologies they know about for each piece. Find the edge of their comfort zone. I've seen your interviewing approach in action and it works brilliantly. This is pretty much a step-by-step of the way my last hiring manager interviewed and he never failed to build very strong dev teams.
- TimJYoung 9y agoI can't agree more. If a company asks cookie-cutter questions and gives out cookie-cutter exercises to complete, then they shouldn't be surprised when they also make a number of bad hires that were just developers that knew how to pass these "tests". On the other hand, as you say, if you sit down, ask them to talk about their experience, and shut up and listen, you're going to learn really quick if they are a BS artist or actually know what they're doing. I also really like your idea of working through problems with the interviewer. I imagine it gives the interviewer some pretty important insight into how well the person breaks down a complex task into some semblance of an architecture, as well as how good they are at keeping such an architecture clean and simple.