Interviewing Junior Developers

In one sense, I’ve only ever interviewed for one developer position: the one I currently have at Daylight. I had actually applied for a graphic design internship when I got my first development job (“we’ll hire you as a programmer”, “um…okay”). After I left, I freelanced. So in another sense, I’ve interviewed for dozens of jobs, albeit short term contracts.

What I have never done is take a test during an interview. Whenever I read the questions on these tests, I’m simultaneously shaking my head at the person who came up with such inane and random questions, and also filled with self doubt and disappointment that I didn’t know the answer to every single one, always regarding JavaScript. No, I don’t know what “use strict” means (I would guess requiring stated data types/strong typing?). “Explain how JSONP works (and how it’s not really AJAX).” Ummmm?

Admittedly, I don’t use a ton of JS in my day-to-day, other then your typical JQuery this or that. I have written one JavaScript application many years ago–and that was 100% vanilla JS for a TV browser, which of course only supported a subset of JS. It taught me a lot. Like how putting 10,000 lines of code in one file is a bad idea.

So for the first time in my life, I’m having to interview people for a junior-level position. In a way, it seems harder then a senior-level position; you can’t give them a test, because they don’t know anything. You can’t even really compare how much one person knows to another; they will probably catch up to each other in a few months anyway. You have to evaluate potential and aptitude. In a 45 minute interview.

This process is making it really clear why diversity in hiring is such a problem. When you have such little time to evaluate people, you tend to cling to the things you know, the things you can relate to, especially when you can’t cling to specific job skills and requirements. The people who excel at hiring look past all these things and can somehow read a person for their potential as an employee in a very short amount of time.

This skill takes practice, which is terrifying, as it means you will probably hire some people who weren’t exactly what you were looking for. I came up with a few interview questions that might be relevant for junior-level developers:

  1. What developer resources do you regularly read or listen to? This shows me if they spend time keeping up in the industry, although I’m realizing that since they’re new, they’re spending most of their time just getting to a baseline of knowledge. Might be a better mid-senior level question.
  2. What about programming gets you excited? 6 week code schools are all the rage–are they really into this, or did they just see a news story about how programming is the new nursing?
  3. Where do you see yourself in 5 years? In terms of development — if they see themselves making iPhone apps, then a web agency probably isn’t the place for them
  4. What brought you here?* Why are they moving into development? Especially if it’s later in life?*
  5. What’s your learning style? When you run into a road block, how do you push past it? If the answer is “ask my teacher”, that’s a red flag. They must be self-educating and self-directed.

These are just a few of the questions we asked, and they are so open ended, you can end up with some very wide-ranging answers. Another problem comes when people try to say what they think you want them to hear; I beg of people, do not do this! That’s how you end up in a job that’s not a good fit. Interviewers aren’t just trying to figure out if you’re right for them, they’re also trying to figure out if they’re right for you. I don’t want to hire someone who’s really into iOS development, we don’t do that. Or someone who likes to spend a lot of time perfecting things; agencies are fast-paced, and that person would be better off in-house.

I have no real answers as to how to determine someone’s potential, but I guess we’ll find out soon if I have a sense of it. Fingers crossed.