DEV Community

Molly Struve (she/her)
Molly Struve (she/her)

Posted on

What does your Junior interview process involve?

I recently got a lot of questions about what to expect from a junior interview and what I look for. Since I have a very narrow view I wanted to open it up to the community. No need to be overly specific about problems, just a general idea of the sessions you do and what makes a candidate stand out for you would be hugely helpful for those trying to prep!

Top comments (29)

Collapse
 
molly profile image
Molly Struve (she/her) • Edited

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.

Collapse
 
rommik profile image
Roman Mikhailov

The Takehome problem approach should be the way to interview everybody IMHO. Ask candidates to solve a problem in a job ad, use that code to continue the interview process. Instead of the usual hr_phone_interview-meet_manager-meet_team-code_test-meet_Some_VP-get-offer way

Collapse
 
etampro profile image
Edward Tam

I think that would work until someone posts the solution online and everyone is submitting the same code, effectively turning it into an unscreened interview.

Thread Thread
 
rommik profile image
Roman Mikhailov

Of course, the next step is to do an in person interview and drill the candidates on their work and choices they made. It's very difficult to get through the second stage when the first one was accomplished by cheating.

Interesting that just a few weeks ago we had this exact situation. A candidate was copy pasting blindly some SO code verbatim. Now days, it's easy and fast to find out where the code is copied from :)

Finally, change the test projects with each hiring session so that they sufficiently different.

Thread Thread
 
codemouse92 profile image
Jason C. McDonald

@molly_struve and @rommik : Finally, I find others on DEV who do the same thing I've been doing for years: a take-home coding challenge, which is further discussed in the final interview.

@etampro I don't know about other teams, but I keep an archive of all previous solutions, and also do web searches. I have spotted copy/paste answers before. In any case, such applicant always falls apart when the final interview comes around, because they don't actually know the code well enough to modify it live.

Collapse
 
bdlb77 profile image
Bryan Leighton

this is a great interview process! One of my favorite interviews I've done was when they were more interested about company culture fit before even getting into a coding interview

Collapse
 
dclements9 profile image
DylanC

From someone who will have to interview in a few months for a junior role, this seems like the perfect situation.

Collapse
 
quintanagreg444 profile image
quintanagreg444

Thank you.

Collapse
 
laurieontech profile image
Laurie

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.

Collapse
 
sergix profile image
Peyton McGinnis • Edited

I agree completely.

Critical thinking is an essential facet of working in any aspect of software and there's rarely anything wrong with asking questions if it will help you accomplish your task.

Programmers who research on their own and have the ability to quickly pick up an API or learn an unfamiliar library's syntax (especially in today's world of npm) if they find it will help solve their problem are some of the most efficient programmers out there.

Collapse
 
tim0807 profile image
Tim • Edited

That's great. I hope to get an interview with someone with the same mindset and methods. On my very limited journey into coding, my curiosity has been my number one reason for the (very small at this stage!) wins so far. If there is anything I hear that I don't know I have always jumped onto Google. To find a career where my curiosity to solve problems is rewarded would be phenomenonal.

Collapse
 
sleeplessbyte profile image
Derk-Jan Karrenbeld

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.

Collapse
 
tim0807 profile image
Tim

That's great! I recently began a career change (from 7+ years in the commercial construction sector) with the goal of becoming a full stack developer. I am currently in the JS phase of learning and am loving it! CSS definitely provided some hiccups but managed to solve them with patience. Can I ask, would you guys hire a junior with html, CSS and JavaScript knowledge (portfolio obviously)? Also would node.js be sufficient on the backend or would it be better for me to learn something like python? Appreciate any info at this stage, just trying to feel my way into this new space.

Collapse
 
lukewduncan profile image
Luke Duncan • Edited

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.

Collapse
 
hermetheus profile image
Allan

Where do I sign up!! 10 years of customer service & management experience trying to make the switch to developing! Lol. Nah for real though it gives me more hope for me that I can eventually land a gig in software engineering. Been working hard for over a year now! Can’t stop me now!

Cheers

Collapse
 
fsuffieldcode profile image
Fabian

That's great to hear as a junior dev with a wealth of customer service experience.

Collapse
 
nataliedeweerd profile image
𝐍𝐚𝐭𝐚π₯𝐒𝐞 𝐝𝐞 π–πžπžπ«π

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.

Collapse
 
vinayhegde1990 profile image
Vinay Hegde

No matter what anyone's experience level whether junior, senior or anything more, this is absolutely spot-on @natalie !

In most cases, strong fundamentals, enthusiasm & a genuine willingness to learn will take us miles ahead than the best bootcamps money can buy.

Collapse
 
molly profile image
Molly Struve (she/her)

Honesty is also very important to me

100% AGREE! I have no problems if they don't know, I do if they pretend to when they don't.

Collapse
 
steelwolf180 profile image
Max Ong Zong Bao

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.

Collapse
 
mandaputtra profile image
Manda Putra • Edited

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.

Collapse
 
betatier profile image
Saskia

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.

Collapse
 
millebi profile image
Bill Miller
  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.
Collapse
 
tim0807 profile image
Tim

Love your second point. I actually use a big mirror to write out my problems/ plan of attack.
Would it be common for companies to have a whiteboard for this type of thing?

Collapse
 
codemouse92 profile image
Jason C. McDonald

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.

Collapse
 
molly profile image
Molly Struve (she/her)

This is awesome! Thanks!

Collapse
 
guruguy00 profile image
Ken Darling

This is something that has been on my mind as well, we are looking to heir a jr dev to the team in the upcoming months and I have no idea what we should be looking for or even what the interview process should look like.

Collapse
 
onexdata profile image
Nick Steele

A Junior basically has no skills, so it's really about who they are and how they will grow while under you.

The first thing I do is suggest a code test. If they tell me they don't do code tests and think they are stupid I would probably hire them on the spot, as code tests are stupid and meaningless and tell you nothing and waste everyone's time.

After I tell them that was a joke and that code tests are stupid, I look for how they act as people. I give them a lot of room to brag or otherwise hang themselves by talking about things they don't understand all the way. If they make things up or their knowledge is way off, I end the interview early.

If they clearly know their skills and where their knowledge ends, I ask them what they are interested in. If they're interested in learning, and especially if they are excited about learning, I hire them.

If they're interested in helping others, and especially if they are excited about helping others, I also hire them.

If they're assertive (not cocky, not selfish, not boastful, but assertive), I also tend to hire them.

If they don't use stop-think sentences (like "the buck stops here", or "that's when the rubber hits the road"), or use them seldomly, it shows they go out of their way to think for themselves and that also gets them brownie points.

If there is an opportunity for me to show them they are wrong about something and they take it well, they also get brownie points. Blame isn't real and being wrong is exciting and should be celebrated, if they know this then they will go very far very fast.

If they don't trip any of the above flags, they go into the maybe pile or I consider other skills or personality traits, but they usually trip at least a few of the above flags.

We don't usually talk about code.

Collapse
 
peterdavidcarter profile image
Peter David Carter

You want someone you can hire who's going to go on to be the best in the company.