What does your Junior interview process involve?

What I look for in Junior Engineers

• Enthusiasm: They are excited to be there and they are excited to learn. They want to do good work and they are inquisitive and not afraid to attack a problem. When things get hard they keep pushing forward and asking questions trying to figure out the problem. This DOES NOT mean candidates need to code outside of work. What candidates do with their own time is none of my business I just want to see that when they come to work they are ready to go and put their best foot forward.
• Ask Questions: Rather than simply accepting that it "just works" they want to know why and how it works. They ask questions like what is happening under the hood here? This is good, but could it be better? What performance implications does this block of code I just wrote have?

Interview Process:

• We do one of the two depending on the experience. A junior who might have a little professional experience(0-1yr) or just overall seems more comfortable we will do an in-person coding challenge. Those fresh out of bootcamp we will give a take-home problem. Often we will ask what they want to do.

  • Takehome problem: We have a take-home problem which is a skeleton application and we ask the candidates to fill out the logic. We expect it to take candidates an hour or two. We then use this code when the candidate comes in for an in-person interview. We ask them to discuss their code, why they made certain decisions and how they might improve it.
  • In-person Coding: A small ruby skeleton application where we ask the candidates to fill out the logic of one method based on a set of tests written for that method. No tricks, no one line answers, the problem is literally from our codebase. We have pry(Ruby debugging tool) in the project and candidates are encouraged to use it or print statements for debugging. They are encouraged to talk through their solution and google whatever they need to. The idea is to get a feel for how they approach a problem, communicate, and work through issues and less about the actual solution.

• Resume Chats/Culture Fit: We always do interview chats and culture fit sessions where we just chat about what is on the candidates resume, what makes them tick, and more importantly, get a feel for what THEY want out of the job. Fit is a two-way street and we want to make sure we meet all the candidate's needs.

My interview is the same as my mid-level interview but judged for a lower level. I give them a problem they likely are familiar with but wouldn't do a lot. Then I watch them google and debug. They don't have to get it right or even make much progress! I'm just looking to see how they solve their own problems. They can also ask questions. If they have those skills then they're in a good position to succeed no matter what projects they wind up on.

We recently hired new juniors and this was the process:

• In the job description I gave a list of 10+ word groups and they have to tell us if they have used it (0), know it (1), know of it (2), don't know it (3).
• I (+1) talk to them during a video call and quickly give an explanation of the project(s) they'll work on. We ask them if they have questions about the project. We answer anything they ask (unless it's a company secret).

During this pre-screening we invite them to ask questions because in our experience, the candidates that are enthusiastic about what we have to tell and ask questions are the candidates turn out to be the best colleagues. Some candidates definitely are shy or are afraid to speak up, which is why I usually have a few questions that will result in them asking the question anyway without them knowing. It's not about the (quality of the) execution but the willingness.

If the person on my side agrees (almost always yes), I invite them to come to the office (if need be, fly them in) and tell them to bring their CV (not resume) if they have any.

At the office, there is a short interview:

• Walk me through your CV! I want to know what you loved and didn't like, and why you did what you did. Most of this is just to make someone feel comfortable telling about their experience and answering questions.
• I ask them about their goals, what they want to achieve, learn, produce, accomplish.
• I ask them about the product they'll be working on and ask for their opinion. In our working culture interns and juniors have a say and are invited to most to all meetings and can contribute. This is the first time they can do that.

Finally I ask if they have time to stay for ~4 more hours, or if they have time in the next few days to come for about 4 hours. They can give me their day-rate or I will decide it based on what we pay other candidates if they feel uncomfortable.

This is when we'll work with them, usually with more people from the team they'll actually work with. And they get paid for that work.

• No take home
• No code interview

If there is consensus after this first half-day by the team, they can come on-board, with a month as try-out so that both they and we can separate ties without any obligations. Fire at will doesn't exist here.

We look for Junior Engineers who have a strong background in another discipline. A trend that we've picked up on is a lot of Juniors with experience in Customer Service end up being very successful. Most likely it's because they can put themselves in our customers shoes. And they have good experience learning products.

In a candidates first interview, we look for enthusiasm, how well they have researched the company (shows real interest) and overall team fit/personality. In terms of code, we are looking for a clear understanding of key concepts in their code (whether it be professional, personal projects, bootcamp projects). These concepts usually include DRY, understanding of CRUD, testing.

Once they've been approved by the team (we are a team of 4 engineers) - we make candidates build out a simple CRUD Rails App. Basically creating short links from website urls. And then having the ability to send those short links via SMS text. We allow as much time as needed for the candidates to complete (within reason). We also give full control over design, code, testing and more. This gives us a true understanding of how the person thinks and what their true understanding of basic concepts is. We usually don't even say you need testing or anything, just to see if they end up writing tests.

We are not big fans of in-person coding. When a candidate has completed the project, even if it is not up to our standard, we usually like to sit with these people and cover why they should be doing xyz while including things that we liked with the project.

But overall it's enthusiasm. The great thing with juniors is that you have a chance to mold their mind. And hopefully it's the first real production codebase they will be working with - so it's a great chance to really get a junior thinking their way around your codebase and the way you want them too. It truly is awesome. I love hiring junior talent and seeing them grow. We actually just send our Customer Service lead to dev bootcamp - and she starts full-time on the development team in August! We are super excited.

With lower-level interviews, I assume they know nothing, or nearly nothing. I'm looking for passion and perseverance. Do you just give up straight away? Or do you chip away at a problem until you can solve it? You can teach someone how to code, but you can't teach them enthusiasm.

Honesty is also very important to me. If an interviewee tells me they don't know something, that adds credibility to everything they've said before as it takes guts to admit to something like that at a junior level.

I think one of the few criteria for with junior especially for junior developers it is their attitude and willingness to learn.

They will stand out to me since the last thing I want is to work with is someone with a bad attitude.

If I was the Interviewer, I'll just ask about git and willingness to learn, and be honest with them about deadlines, how your company finish some jobs/sprint basically how the company works. I always wish the company scare me out on interview with "this bad things that could happen if you're a developer, it could be company fault or yours depends"

My first interview was like Senior/mid level Dev Interview :( we talk about background jobs, redis, websockets, CI/CD. I failed but I learning a lot about architecture.

Oh and the take-home coding was: create a chat app using redis, make it run on two cluster, use background jobs to delete chat message every 10 minutes.

We do pretty similar interview questions independent on the seniority of the candidate.
Normally we present a problem and ask the interviewee to design a system which solves it.
We start with the first thing that comes to mind and then iterate over that to get more into detail, discuss pit falls and edge cases.

This way the experience doesn't matter too much as it's rather about understanding the problem and explaining your way of thoughts to the solution.

1. If you mention something on your resume, be prepared to discuss it!
2. Practise coding on a whiteboard, perfect syntax is rarely important, but being able to have basic code structure is important
3. Be able to do a high level design of something and be prepared to break some part of it down into smaller pieces.

What we're looking for from above:

1. We expect that you can describe something useful that was in your resume and start a discussion about how you solved a problem or accomplished a task.
2. There will almost always be a small coding question to see how you tackle a problem and make mistakes and (of course) fix them. We're mostly interested in how you think through a problem than if you can actually code on a whiteboard. You'd be surprised at how many candidates completely fail at being able to code a "for" loop on a whiteboard. Find a friend to ask a "stupid" question (that they know the answer) and see if you can explain how to solve it on a whiteboard.
3. Many times an interview will have a "coding" section and a "design" section. We're interested in if you know how to break a problem up into smaller segments and how those segments interact. In many cases it's a very open problem that allows us to dig deeper into a strength or weakness of the candidate.

I do basically what you described, @molly_struve .

What I look for in an intern is:

• Humility and willingness to learn.

• Basic coding skills — this is an internship, not CS-101.

• Good (if unpolished) communication skills.

• Self-discipline and a sense of responsibility for their own work.

• A passion for their craft.

• A healthy perspective on workplace diversity.

My hiring process is an initial interview, a take-home coding challenge, and a final interview. (This whole process is full-remote.) I've been refining it for several years, and my hiring success rate has gone up with every improvement.