Lately I’ve been talking with students at programming bootcamps about their overwhelming fear that they’re not learning quickly and thoroughly enough to find employment afterwards. I think it’s generally produced more by the intensive crunch-time atmosphere of the schools and growing recognition of how big and complex programming is than by an actual deficiency in skills.
At Tandem, we’ve hired five apprentices in the last 2.5 years, all fresh from programming schools. I’ve interviewed candidates and been part of the selecting which candidates to make offers to. I’ve also met a dozen more similar recent grads at clients: we’ve seen a number of companies that mostly or only hire new developers, probably because of salary costs. A few times now my contracts have been more about mentoring new devs than banging out features. All considered, I’ve had a good amount of opportunity to evaluate new developers from the new programming schools. Most students have been from DevBootcamp Chicago, but I’ve also met students from Starter League, App Academy, Mobile Maker’s Academy, Turing School, The Iron Yard, and probably more.
So I’d like to talk about what we look for in candidates for apprentice and junior developer positions and how we evaluate them. I hope this helps students who are studying to be developers understand how they’ll be evaluated when they finish their programs, and I hope other employers will also publicize their strategies.
Evaluating
The thing I most want to see in candidates is improvement. I don’t expect to see amazing Rails chops, I expect to see someone who is genuinely curious, experiments, studies, and will keep learning new things. I don’t expect to see much competence, but I want to have confidence that they’re on the right track to continually acquire more. To really hammer this home: it’s not about how much a junior dev knows, it’s about how much they’re learning.
Candidates need to have the instinct to look up documentation and make sense of it, whether that’s the Rails guides, RubyDoc.info, StackOverflow questions, or some dev’s random rambling blog post where they puzzled out some obscure Rails feature two years ago by reading the source. This gives me hope that they can solve some of their own problems and learn things above and beyond what they get through pairing.
Candidates need to be able to write syntactically valid Ruby in an editor with syntax coloring. Their code has no syntax errors 9/10 times, and that other time they can almost always fix it on the first try. It’s just too painful to watch people struggle with nesting parentheses, quotes, or ‘end’s.
Candidates need to actually read error messages. Some new developers will get an exception and do one of two wrong things: 1. get stuck and throw up their hands 2. instantly flip back to their editor and change a random piece of code. I know they’re a foreign language at first, but the error messages do actually mean things about the code (and they emphatically do not mean “you’re dumb”). If nothing else, they give you the name and line number of the file you should start in. And you have to reread them when you change code and it’s still broken, because code will often break in a slightly different way that gives you more information about what went wrong. (There’s a really good debugging strategy hiding here, too: if you’re stumped on what an error means, try making a change that will cause the error to happen worse or earlier.)
Finally, candidates need some basic Ruby knowledge. Just an idea of what functionality is available, like “well, I have a bunch of things, I’ll put them in an array” or “I could use ‘split’ or maybe someone has already created a gem to parse a CSV file”. Also some knowledge of what goes where in Rails – not a lot, because Rails is big and complicated, but some idea that you put database code in the model, decide what to do in your controllers, use helpers as a junk drawer, etc. More Ruby and Rails knowledge is always nice, but this is not a pressing concern.
This my basic requirements for hiring a junior developer. I don’t expect a wizard who can conjure websites out of thin air. I expect someone with some basic skills who won’t get totally stuck more than once or twice a day.
It’s a nice bonus to see that the candidate has made a small site or app so I can read more of their code and see that they can finish things. But, it’s only a bonus because it’s not vital that a junior dev can finish a site on their own and it also evaluates whether they have the free time to do something on top of or after school.
Interviewing
Programming interviews are generally pretty terrible. Interviews are really stressful and not especially meaningful for understanding whether someone can do a job.
So we do things differently at Tandem, and encourage our clients to do the same. We have the candidate sit down with an experienced developer and spend an hour pairing on a real codebase. They’ll do this two or three times with breaks in between. We’ll spend some time (perhaps lunch) away from a keyboard to tell them more about what Tandem is like and answer questions.
The last time I interviewed apprentice candidates I set them up to debug a real bug I’d recently fixed in a client app. It required following a value from controller to view, and fixing it revealed another bug that could be fixed in a few different ways. This let me see that they could read other people’s code, navigate Rails, reason about errors, look up related docs, experiment to understand the code, and write a basic test. I wouldn’t be concerned by the quality of the code and test they produced unless it was incredibly bad (and this didn’t happen with any candidate).
Every candidate fixed the same bug. Yes, it was kind of boring for me to re-fix a bug four times. But boring is a feature: it gives me more room to pay attention to the candidate and how they’re working through something I understand very well. I want interviewing to be less subjective and random: if every candidate had a different feature or bug my evaluation of their ability level could easily be overwhelmed by how easy the task happened to be.
I want interviewing to be a lot less subjective, too. I deliberately don’t want to interview for “cultural fit”. As a consultancy, we’re constantly working with new teams of developers. If we can’t adapt to different personalities in our office, we’d never be able to adapt to clients’ different personalities. And “cultural fit” is also a great place for bias to seep into the process, where I’d subconsciously be evaluating “do they look like previous developers I’ve met?” rather than “can they do this job?”
Or worse! I could evaluate candidates based on some useless metric like how confident and clever they can be under the stressful conditions of an interview. That skill is not at all relevant to or predictive of their day-to-day job of writing code.
We also want to lower the pressure of the interview by telling candidates exactly what they’ll be evaluated on, what skill level we expect, what the day’s schedule will be, and also give them room to relax privately during the process. The less of that stress there is, the better we can approximate what it would be like to work with them.
The Bottom Line
New developers don’t have a realistic assessment of how much they’ve learned and what employers will reasonably expect of them. I’m sharing this description of what I look for in candidates and how I assess them in the hopes that other folks at other companies share their thoughts so we can build a shared consensus of expectations. Feeling useless and overwhelmed is really lousy, and the better employers communicate what we want the more likely it is we’ll get it. Please chime in.
