Cfrgtkky

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.

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.

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.

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.

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?

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.

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?

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

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.

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)