58

After working with my boss at a previous job he's decided to start a contracting firm and I'm in the first handful of people to help get things started. It's been a few months and now we're looking to expand and hire a more junior developer.

I've helped my boss hire knowledgeable senior level people that I was going to work directly with. It was easier to ask hard questions and if they had a correct answer then I could believe they were good for the job. If I ask a senior person hard questions that they don't know the answer to, I start to have a feeling it may not be a good fit.

Trying to come up with questions for a junior level has me second guessing how to receive their answer. If I ask a junior person easier questions and they don't have an answer, is it because I asked a slightly too hard question for a junior? Should they know this answer? If they got it right, did I ask too easy a question? In theory it makes sense to ask them some technical questions but also some "are you capable of learning what you need to know in order to do your job" kind of questions but that's turning out to be hard in practice.

How can I ask the right questions and set my own expectations properly for interviewing a junior candidate?

| improve this question | |
  • 25
    What are your current expectations regarding their role? If you don't have that figured out it will be tough to find candidates to fill the role. – sf02 Feb 11 '19 at 18:44
  • 25
    The fundamental problem here is that you have a bad interviewing technique, and now you're asking how to make that already bad technique work in more scenarios. You should never be looking for correct answers to trivia questions. You should be eliciting signal on analytical ability. – Eric Lippert Feb 12 '19 at 15:49
  • 1
    Hire a few interns and view it as an extended interview – SPYBUG96 Feb 12 '19 at 17:30
  • I would argue that senior positions aren't just about knowing stuff, but attitude and learning ability. If someone has a "can do, will fix" attitude, and learns from their mistakes, then they'll likely make a better senior than someone who is scared of making changes and makes the same mistakes. – UKMonkey Feb 13 '19 at 0:10
  • If you're asking a junior questions, they're no longer good for the junior role. The junior role shouldn't exist, except maybe for people who have not graduated yet or have absolutely no experience (in which experience/skill questions are pointless)... – insidesin Feb 13 '19 at 0:55

10 Answers 10

Active Oldest Votes
134

As a slight frame challenge to your question, you need to get some clarity on what the role requires and then ask questions specific to that. In other words, I have the feeling that your real problem is that you don't have a clear idea of what skills you want in this person. Find that out and the questions will follow.

Stop over-thinking "easy" versus "hard" questions. Write down what the person needs to be able to do and then ask them questions about what you've written down.

| improve this answer | |
  • 38
    I've made lots of mistakes and done my best to learn from them. – dwizum Feb 11 '19 at 20:28
  • 1
    @dwizum The only thing I'd expand on here are a couple examples of how "easy" and "hard" are subjective: for example, I find a lot of Electrical Engineering questions "easy" (calculate resistance, impedance, etc.) and I'm a senior dev, but I'd bet there are a lot of seniors out there who find those questions "hard", because it's not something they need to use. As you said: skill requirements first, questions later. – Der Kommissar Feb 12 '19 at 14:42
113

For a Junior, it's less about what they know, and more about who they are.

If they don't know the answer to a technical question, follow up with something like?

You said you don't know. How would you find out, and then implement it?

For the tech questions themselves, have sets of Basic, intermediate, and advanced. Climb the difficulty tree until you get an "I don't know, then ask that question above.

Ask more soft questions like:

Your senior has assigned you a task. You feel like it's beyond your abilities, what do you do?

or

How long do you see yourself staying as a junior? How would you hone your skills to be worth more to the company?

Also, keep in mind that the more junior people are also inexperienced in interviews and may blow tech questions that they know.

Go for more of the "How would you" type questions as opposed to "what is" type of questions.

most importantly

Interview for fit. Your eventual goal is to advance a junior in your company, the better a fit they are, the easier it will be to upskill them, and eventually train the next junior(s) that apply.

You can teach people more tech skills, you can't teach a jerk to be a decent person

Again, this is why you want to interview more for ability to expand and learn than for raw tech skill. If they're lacking in a few areas, you can get them up to speed. If they're going to be a disruption, nothing will cure that.

| improve this answer | |
  • 3
    I strongly second your answer, and would like to add that for junior people in an IT setting (OP has a website saying he's a developer and loads of rep on SO) it's important to make sure they know how to learn, and are curious and motivated. I see the hiring process as part of my job as a trainer for developers, and I've spoken about this at open source conferences in the past. – simbabque Feb 12 '19 at 10:31
  • 1
    While I totally agree with what one is looking for in a Junior, I'm pretty doubtful about the suggested questions. They seem like standard questions everyone knows how to answer "right" and thus they don't tell you much about how the person is but how the person thinks you want him to be. For how they solve problems it's more clear how they approach things by giving them some problem and then either solve it with them together and/or provide him a set of tools and check if he can work with them (with assistance if necessary). – Frank Hopkins Feb 12 '19 at 10:53
  • 3
    @Darkwing I've used this method. It works. You don't need to find an all-star, but you do need to be able to screen out the screwballs. I did a tech interview of one fellow, and he couldn't answer one question, but had a great attitude, we hired him, he did great. – Old_Lamplighter Feb 12 '19 at 13:24
  • 2
    Great answer. In my experience, you can teach tech, you can't teach attitude. In general, you want someone who works well with others, has a healthy attitude about feedback and a willingness to learn and grow. Personally, I like to see candidates who demonstrate the ability to sacrifice, because it's a nod towards one's ability to deal with adversity. Which is very important in tech. Being able to start a task on something you have complete ignorance on and be able to make progress without constant guidance. In short, they need to be learners. Simple as that. – ShinEmperor Feb 12 '19 at 14:36
  • 1
    @RichardU Yes we can. And I'd say likely equal or worse drag depending on the jerk-level and idiot-level ;) Therefore I'd personally aim to check for both. But yes, it was only meant to give you another point of view - whether to integrate that or not is obviously totally up to you. – Frank Hopkins Feb 12 '19 at 14:37
12

The top answer is very good and should suffice I guess. I only want to add a small detail as a person who was interviewed for a junior position several times not so long ago. Sometimes during an interview I had an impression while being asked ('hard'?) tech questions that interviwers were rather trying to show off their knowledge than to know about mine: favourite subject seems to be little used language features or technical details (like garbage collection process) which I normally never had need to use. This is very confusing and makes junior think that he knows nothing at all. What would be more welcome is giving a simple task with describing implementation process in common words, like creating models, ease of extending them, defining what they should do, and sometimes more important, what they shouldn't do.

| improve this answer | |
  • 2
    You've hit a good point here... those "hard" questions, very obscure language features, very few people can answer. I would suggest to answer: "Google". And then follow up "thats a very specific language feature that not everyone knows, I would google it, read up on it, study the subject and then think about how it is applicable to the problem at hand. If necessary, Ill then ask for help" - thats a GREAT generic answer that a junior can give to those questions. Another one is "I dont know the answer, but could you tell me, and then can we discuss it" - another positive one – vikingsteve Feb 13 '19 at 11:59
  • 1
    Yes, the good old "we measure the things that are easy to measure, not the things that are actually useful". It's very easy to make a test with 30 trivia questions with 30 correct answers. It's also almost entirely useless, and frustrating for a good candidate who just happens not to know or care about such trivia. Mind you, it can help for very senior positions, where you just want people who know things inside out and you get a good conversation out of it. You usually care more about how the people think (and talk) about the questions rather than whether they hit the correct answer. – Luaan Feb 13 '19 at 12:25
  • It's useful to have one or two "hard trivia" type questions that a candidate is unlikely to know up your sleeve, purely as a surefire way to elicit an "I don't know" answer and probe further how they would handle that situation, but beyond that they are fairly useful as mentioned above and potentially just there to stroke the interviewers ego as the answer alludes to. – Heydiddly Feb 13 '19 at 12:30
4

First, decide what you want the person you're hiring to actually do. Based on that, decide which skills and knowledge are important for this role. You probably want to align with your boss on those points.

Make sure that your job description and list of qualifications accurately reflect that. In terms of the job description, make sure that you accurately describe what you want the person to actually do and accomplish - describe the job, not the kind of person you're looking to hire. Once you have that, come up with your "people description" - i.e. what kind of person you're looking to hire and what your desired qualifications are. Make sure that that aligns with your job description. A good people description should describe someone who is likely to be able to do what your Job Description specifies.

A "qualified" candidate is someone who meets the requirements in your "people description."

Based on the job description and the people description, you should come up with a list of questions that'll help you know whether the person in question meets the requirements in your people description. Rank your questions in order of easiest to hardest, so that you can determine the person's skill level.

Some good questions could include, for example, reversing a string without using string.reverse (yes, some people actually get this wrong), sorting a list, or the classic FizzBuzz challenge.

| improve this answer | |
3

It's not a great idea to put a junior on the spot in an interview. I think a far better approach is to set them a simple coding task and give them a certain amount of time to complete it. It will show their ability to learn and solve problems. You could even set this test before inviting them in for a face to face interview.

I cannot code while people watch me, it's awkward. I have always hated interviews where I'm asked to do this. Of course asking some probing questions to judge someone problem solving abilities is good but try keep it general not specific, if that makes sense?

| improve this answer | |
  • 1
    +1 on sending a task before the interview. On the job you won't be writing code on a whiteboard with no access to the internet. They may cheat by getting someone else to do the task so its best to verify the results a little. – Qwertie Feb 12 '19 at 6:15
  • 1
    that's true they might cheat, but during the interview you could ask questions directly related to the task which would help you figure out whether they cheated or understood what to do – Pixelomo Feb 12 '19 at 7:12
  • It depends. If you want to hire juniors who will stay as juniors "for ever", and just extract the maximum quantity of grunt work from them before they find a better job elsewhere, maybe you don't need to "put them on the spot". If you hope they will grow with the company and become seniors, that's a different interview scenario. – alephzero Feb 12 '19 at 12:59
  • @alephzero ah the typical mindset of someone who looks down on self taught professionals – Pixelomo Feb 13 '19 at 0:16
2

I've done this many times over the last few years when recruiting students from the local college. We started off doing technical tests, however found that it was a poor indicator of a student potential, with students ending up performing much better in their role than their test results would suggest.

After trying a few different approaches, the one I found works best is to ask them to bring in as many examples of past work as possible, including college assignments, hobby work, and any work experience they might have done. Then we give them a computer and ask them to show us what they've done and talk us through the code etc.

This way you don't have to make any assumptions about what they might have already learned and you don't miss relevant stuff by asking the wrong questions. If they learned a lot from the projects they show you, and completed them without too much help, they should be able to confidently explain to you what concepts they learned along the way etc, whereas if they had a lot of help they won't talk about the project for very long.

| improve this answer | |
  • 2
    This is a good approach IMO. The important thing to evaluate is not "what they did", but "can they tell a coherent story that explains what they did so you can understand it". That also weeds out those who didn't really "do anything" at all, but are hoping to fool you with something they don't understand but looks impressive. – alephzero Feb 12 '19 at 13:02
2

Always start with FizzBuzz. It excludes far more candidates than it should. You should resist the urge to do much else for technical screening. Many homegrown coding tests are simultaneously unnecessarily difficult and similar to the interviewer's own classwork, which creates a biased interview process where only candidates with a background similar to the interviewer get considered.

Past there, you shouldn't be looking at anything generic. You want to identify the skills necessary for the job at hand. Generic programming is covered by FizzBuzz, but do you need someone who already knows, say, CSS or Java? If you can't sponsor the candidate learning the language on the job, you'll want to cover something about, say, CSS priority rules or margin vs padding for CSS, or how to update Maven/Gradle dependencies by hand. Again, you want simple - just enough to prove exposure beyond classroom basics.

Skills also aren't purely technical. Does your candidate need to do his/her own requirements gathering or design documentation? English fluency matters here. Is it client-facing? Time to break out the structured behavioral interview (and protip here: always ask these questions in the past tense, e.g. "Describe a time that you addressed a complaint from an irate customer," never "How would you address a complaint from an irate customer?")

So, in summary:

  • FizzBuzz, but no programming puzzles
  • Make a list of other required skills
  • Evaluate required technical skills with basic sanity checks
  • Evaluate required soft skills with predefined behavioral questions
| improve this answer | |
  • 1
    The first paragraph is garbage. Never use FizzBuzz, it's too popular a test and it's a joke. Your process should already screen out anyone who can't do that, it's the most trivial process of all time. The rest is better, but it's worth noting that in software, trivia questions are mostly useless - those can be looked up when needed (I work in css frequently and wouldn't be able to tell you the rules of priority effectively - I could give some idea but I'm not sure which is more specific between .class.class2 and a > .class, and when working... that doesn't even matter) – Delioth Feb 12 '19 at 21:37
  • 1
    FizzBuzz still screens out well over half of junior applicants. I never ran rigorous numbers on that in a cross-posting sort of way, but it wasn't just a little bit over half. It ranged from damn near 100% for internships to probably 60-70% for a job that tolerated some mid-career technology skills transfer. – Alex H. Feb 12 '19 at 21:41
  • 1
    @Erik I don't think you get the sheer amount of people Fizzbuzz eliminates, despite being "too popular" and well known. It's an extremely simple thing to do that wouldn't stop an actual programmer for more than a minute or two, and still weeds out a very large proportion of your average applicants. My numbers aren't quite as bad as Alex's, but definitely at least a third of the people I've interviewed simply couldn't think algorithmically at all - and some of those were people with "10 years of software engineering experience". – Luaan Feb 13 '19 at 12:32
  • 1
    @Delioth I mean, if you're implying that we should have non-technical staff take a more heavy-handed role in sorting programmers' resumes, that's certainly an approach that's been taken before. It has its own share of pitfalls, and Fizzbuzz is definitely the lesser of two evils here. – Alex H. Feb 13 '19 at 22:38
  • 1
    Phone screens are shit. Use them if and only if there's a real cost to the interview, like flying them out to your office. Take-homes aren't a ton better. Someone who is dishonest in their resume will also be dishonest in a take-home technical exam. I'm all for variations in approach, because not everyone has the same needs, but I'll hold the line on both of those. Absolute waste of time. Let HR do the phone screen to make sure you can legally hire them and they're not complete morons, but that's the end of the value there. – Alex H. Feb 13 '19 at 23:01
2

Important: junior candidates are always nervous or possibly hyped up, far more so than senior ones. It might be their very first interview. So be careful about judging their personality from that one interview alone, as they don't tend to be quite themselves.

Judging personality and soft skills is overall hard and recruiters have diverse talent for that. Everyone think they are great at it, but only a minority of recruiters actually are. Always good to be two people interviewing, even if the second person is only there to get a feel for the candidate's character.

One way to go is to look at what they have already achieved rather than what you think they might achieve. Grades, spare time work, school projects, anything. Grades might not say necessarily say much about knowledge, but they tend to be a good indication for an ability to learn new things. Or at very least the ability to perform well even when given boring tasks :)

If it's a programming job, like this sounds like, give them a tricky question but let them solve it by using the internet. "Fizz buzz" might be ok as a filter, but nobody sits around coding "fizz buzz" for a living. Rather, they continuously face problems which they haven't solved before, far more often so for rookies. Knowing how and where to find information is important.

Then you can ask them how they found the result, which is probably as important as the result itself. Did they Google it and grabbed the first thing that popped up? Credible source or some fishy tutorial?

| improve this answer | |
  • +1, junior candidates will very often badly sabotage themselves purely through nerves. I found as a junior that the best interviewers were the ones who could put me at ease and let me feel more comfortable in that scary interview environment. – Heydiddly Feb 13 '19 at 12:33
1

I see some answers suggest not doing the normal interview questions. I disagree. But I also disagree that there should be "easy" or "hard" interviews. What you want are standard interview questions covering a range between easy and hard which you can ask everyone.

A good candidate will breeze through the easy questions, and if they're clearly better then you can skip ahead. For a less skilled candidate, you can judge their abilities by where they stall in the list of questions.

| improve this answer | |
0

I'll come at this from a different perspective. But in short, when I'm assessing a junior I want to know "Can you learn?", "Can you be autonomous?", "Will other people work well with you?"

Independence, intelligence and agree-ability are important attributes for a junior. Don't misread agree-ability as being a "yes man", read it as being open to different ideas, people and criticism. Being honest about who you are, your abilities and where you need to grow.

So, I think it's worth doing a technical exam, but it wouldn't be weighted heavily. The "soft skills" side of things would be very important because we know you don't know anything. The question is" Can you grow on your own and within our team?

But if a junior can demonstrate an ability to LEARN things on their own, self directed, that's the ideal candidate. (I was that sort of junior and I did extremely well in my company. So I typically expect it of juniors)

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged .