Moving to Project-Based Interviews for Juniors 📦
Co-Authored by Elena_in_code and Paola Cucurullo, Frontend Software Engineers at Packlink
Packlink is actively working on including junior talent among the engineering team members in different areas: frontend, backend, QA and data.
In the last few years there’s been a change in how people are learning to become programmers. Junior profiles nowadays can come from universities, other formal courses, bootcamps or even self taught. Currently in Packlink we have people from all four sources. With this change also came different profiles, people with different backgrounds, different professional experiences and more diversity.
When a company is hiring juniors, it’s investing in the future. For our team, we believe that juniors are a necessary addition for many different reasons such as: new perspectives, a strong sense of ownership, and giving our more experienced teammates the opportunity to develop themselves as mentors, sharing their knowledge and learning from their mentees, etc.
But… What is an entry-level software engineer?
An entry-level candidate is a person who has been trained in software development but never before had any working experience in a professional environment, so working at Packlink will be their very first working experience in this field. It will be that moment when all the theory is put into practice and you realize there is so much to it.
How did we challenge our process?
The hiring process at Packlink involves the whole dev team, and has three main steps (nothing too unusual): technical interview, code challenge and a final step that includes a code challenge review and conversations with HR and Product. Throughout the process, future Packlinkers are assigned to a team based on a rotational system, whose members will take turns being present through the different stages. This way both multiple teammates and the candidate can assess whether or not there’s a fit, not only with our technical requirements, but also our team culture and ways of work.
This process has served us well, and we’ve built a team that is cohesive and works well together. It’s a pretty standard process that experienced techies have gone through multiple times and are comfortable with. But when we started to interview for entry-level and junior positions, we came across something that is actually blatantly obvious: People with limited work experience also have limited technical interviewing experience. I know, right? DUH! So we decided to open up our empathic hearts and think back to when we were doing our first processes — how we felt in those first terrifying calls — and think through how we could adapt to the different life experiences of our candidates.
The first thing we figured out is that even with all the experience in the world, we all get nervous before an interview. This is one of those unavoidable truths of life for everyone; even if they already have a job, they’re going to get nervous, but then again… it’s so much worse for someone who’s trying to crack into the development workforce for the first time, isn’t it? Regardless of their previous job experiences and how they learned to write code, there’s simply less experience for them to pull from when asked questions like “have you worked with XYZ library before?”.
Another unavoidable truth is that not everyone has the same personality or communication style. Some people are more outgoing and will tell you all about their life without you asking, some crack bad jokes during the interview because they’re uncomfortable, and some are shy and don’t really volunteer a lot of information. We could discuss introversion and extroversion and everything in between for hours, but the gist of it is that if we put this fact of life together with the nerves thing we get a nice little cocktail ready to give us bad results. We need to be able to conduct our candidate interviews in a flexible way that allows us to assess the candidate regardless of how nervous or reserved they are.
One more thing: our team had kind of grown used to interviewing for roles that require a lot of experience, because that was what was needed at the time. A small team needs players that can make fast decisions and produce quickly. But now our focus is changing towards building a bigger, more solid and diverse team that can handle the future of the company. So we realized that we also need to adjust what we’re focusing on during the conversation; are we looking for know-how, or attitude? When it comes to filling those limited-experience roles, we want to find people who will want to learn, want to share their different perspectives, and fit in with the team, so we need to flip the switch and focus on attitude instead of looking for someone who checks all the boxes of our tech stack.
Although not the only change we made, our main focus was on the initial interview which usually is the first contact between members of the team and the candidate. The Frontend area accepted, in one of our weekly meetings, the proposal of changing from a question-based interview to one centered around a project that the candidate has worked on during their studies, that they hopefully will know inside and out and feel passionate about. Based on what the candidate says, the interviewers will try to cover some basic topics, ways of working, problem solving, resources and will to learn.
So we turned the typical quizzing into a conversation, now what?
We think of this development as a living process, so we are actively including feedback from new joiners and interviewers to make it better, more inclusive and to give everyone a chance to explain why they are the best next fit for the team.
