There have always been different approaches to hiring in tech.
Most famously, How would you move Mount Fiji type questions. In my first professional interview with a really large bank that you know about, I was asked a similar question by other developers who worked on a trading room floor. The interview consisted of various brain teasers and rapid fire questions designed to put a candidate through what it’d be like on a trading floor.
Having just gotten out of the Army during wartime, this seemed more silly than useful to me. Luckily for me, I did not get the job, and a little over a year later, the finance sector crashed and all of those traders/programmers were looking for other work.
Since then, almost 10 years ago now, I’ve been hired and have done my share of hiring. I’ve dealt with interviewers that wanted me to take a personality exam, an online coding quiz, writing a few small web applications (reproducing search, creating a site that showed the weather, and implementing UI features with various frameworks), and even more of those brain teasers everyone loves to hate. I’ve even done practical coding, coding with unit tests, and even a few interviews that focused especially on writing database queries. My success rate isn’t 100% — I’ve failed as many as I’ve passed. But each time, the interview showed me what the company was looking for (or rather, what they thought they were looking for).
In the case of the Trading Floor exam, they were trying to simulate actual live conditions. Why the software would be so crappy that it would fail during trading is beyond me, but apparently that happens enough to hire for it.
In other cases, they just wanted to see if I could code — there are enough programmers (!) out there that can’t that interviewers have to screen candidates somehow.
I know this because I used Fizzbuzz and determining if a string was a palindrome to weed out candidates. I’m somewhat embarrassed to say that even after letting some candidates work on either of these problems for 30 minutes, they couldn’t produce working code.
So I changed tactics; and started to ask candidates to show me some code they were proud of. One candidate produced an entire ream of paper worth of printed out code. I’m not sure what it did; all I can remember is watching the candidate pull out that ream and go “Here.”
Luckily some time after that I was able to interview at The Motley Fool; and their interview really reflected the sort of culture fit they were looking for.
The interview started out with an online quiz taken before the in-person interview was scheduled; essentially asking about parts of the C# language and .NET framework to weed out those that didn’t know it well. It didn’t just include trivia (is a String a value or reference type?), it included parts that would bite you if you had actually used the language or the .NET framework in production.
The in person interview was a little more chaotic — there was an hour of onsite coding in Notepad++; and then four hours of interviews with various members of the team. One person asked me how I’d model a rubik’s cube in code. That was an interesting hour (and by far the scariest).
At the end of it, however, I understood exactly what the Fool wanted; they wanted someone who was smart, could get things done, and (more than anything else) was a culture fit. So much so that they’d have you sacrifice lunch and spend 6 hours interviewing (I don’t think they hire that way any more, but if you are ever interviewing for the Fool, eat a large breakfast).
Each company I have interviewed at showed a bit of what they were looking for during the interview, and the interview itself became a way to understand whether the company was a good fit.
A more recent trend has been to ask candidates to do *X* in an hour. *X* could be anything, a small application; designing an architecture scheme for a system, whatever. That *X* is important.
Let’s say (hypothetically, of course) you’re looking for a developer and you want them to do something in an hour. What should that thing be?
Should it be some general programming problem where you’ll see what they can do (like implementing a calculator using TDD?)
Or should it be something more proscriptive — like implementing something in a specific framework using specific tools?
The danger with the latter approach is that if you’re too proscriptive, you may actually measure something other than you intend to. Even if my stack is in C#, .NET, Bootstrap, and ASP.NET Webforms (incidentally, that’s the exact system I’m working with now), should I ask a developer to implement Bootstrap for *X*? More over, should I ask them to use specific plugins for the bootstrap framework?
No. If I’m measuring whether a developer can code; I should gear the hour towards problems that can determine if they can write code.
If I’m measuring whether a developer can use Framework X efficiently, then I should interview for that — but be aware that it’s not a fair test of whether or not they’re a good programmer.
So this leaves me with a question for you: What should a programmer be able to do in an hour? Should they be able to take a foreign plugin from a framework they may or may not have intimate knowledge of and implement a trivial/non-trivial feature in it inside an hour?
It’s a question I can’t answer. Some days I can spend an hour on a problem and resolve it, some days I can’t — it just depends on the nature of the problem and its documentation.
With the proliferation of frameworks and problems we attempt to solve, I have a hard time understanding where programming begins and implementing a specific framework ends. Should I hire for the former? Or the latter? Should I hire based on whether a programmer can solve an arbitrary problem in an hour? Are there really times where you only have an hour to solve a problem?
Unsatisfyingly, I have no answers here. I don’t know what a programmer should or shouldn’t be able to do in an hour. Sometimes I feel like I’m a great programmer, other times I’ve wanted to quit programming in my stack completely because of some silly issue.
So I ask you: What do you think a programmer should be able to do in an hour?
I’ll take issue with your premise. I don’t think you want to find out what they can do in an hour under artificial and, more to the point, unfamiliar circumstances. I think, at best, you can only determine order of magnitude differences between developers under those conditions – maybe not even that. Try using another developer’s IDE and tools under a non-stressful situation then imagine that your job is on the line and you only have an hour. Each of those things contributes to the possibility of false negatives.
At The Nerdery we approach it in a completely different way. We give you a code challenge to do on your own time with your own tools with a reasonable amount of time to complete it. The interview then becomes more of a code review and a discussion about your code – why you picked a particular tool or architecture, how you went about solving the problem. We have both an objective sample of your code that compares easily with other candidates because it’s the same problem AND an opportunity to have a reasoned, less stressful deep dive into your thinking and capabilities. It was the best interview experience I’ve ever had – because it was my code, developed my way, without someone looking over my shoulder.
I don’t like the ‘what can you do in an hour’ approach for the same reasons. I don’t think it can accurately measure how good of a programmer you have. I do my best programming when relaxed, awake, and without distractions… I’m neither relaxed or without distractions in an interview.
I do like showing code I’ve done on my own time and talking in depth about the challenges I faced and my strategies for overcoming them. Really, the question, “Do you work on side projects on your own time,” is one of the best, especially if they brought material from one of those projects to show.