SECRET OF CSS

My Approach to Technical Hiring After Conducting Over 100 Interviews | by Nuno Barreto


From small and medium-sized companies

1*JNgrJosel PQGTm4l oToQ

It is quite common to hear Software Engineers and other technical people complaining about the way technical interviews are conducted. Some of the common complaints are:

  • “The process is too time consuming for someone that has a full time job and a family!”
  • “The questions and code tests have nothing to do with the real work I would be doing!”
  • Leetcode type questions are easier for fresh graduates than for someone that has been working for more than 5 years.”
  • “You don’t ask plumbers to fix some pipes before you hire them! Why ask programmers to program?”
  • “I have been a software developer for more than 10 years, and I have an active Github account. Why don’t they go and see that code instead of asking me to solve dumb problems?”

I have lost count of how many interviews I went to, for companies ranging from small startups to Big Tech. And all of them seem to have their own opinions of how the interviews should be.

Well, after conducting hundreds of interviews myself as a Hiring Manager, I also have my own opinions and practices that have worked well for me.

On my first Tech Lead position, I had to hire all of my team. Since it was my first time, I had the help from other Managers on the team, and ended up following more or less what they were doing at the time. There was no overall strategy involved, just a conversation around their experience.

My first hires then actually advocated for having some kind of code testing involved on the next interviews, and I ended up accepting it. We added some code with bugs printed on a sheet of paper, and the candidate had to find the problems on the code. The offer was normally presented on the spot if a good candidate was found.

On the next company, I adopted their common practice, which was a first interview to access fit for the role / company, a “take home assignment”, and a final interview to give an offer to the most successful candidate. No chance to present it. Worked ok, but we were hiring mostly inexperienced people.

After that, influenced again by the Managers on a new company, I experimented with what we called “Work Days”. After an initial interview to access fit with generic questions, I would invite the candidate to come and work with us for a full day. We would normally have a short list of 2–3 candidates that were invited per position open. On this day they would be given a real (or close to real) task that involved discussing a problem with members of our team, deciding on a solution for that problem, having lunch, and then develop / design / prototype it. They would then present it at the end of the day to the whole team. It was an awesome way of getting to really know the candidate, and for the candidate to know the company. It worked very well when people accepted to do the work day, but more senior and experienced people rarely had time or will to do a work day.

After that experience, I finally started to develop and use my own approach which I describe bellow. This approach was inspired by my own experience as a Hiring Manager, but also by my experience on the many interviews I already went too.

I firmly believe that skills can be learned. Not only technical skills, mind you. But also people skills, soft skills, management skills, etc. I am sure that everyone can learn anything they are inclined to. I admit that some people may have certain characteristics that make it easier to learn certain things and become extraordinary in them, but everyone that is willing can learn. So I hire for the right mindset.

This means that I am not only looking for what the person is today, but for what the person has the potential to become. Of course, they have to have a basic set of skills necessary to fulfil the minimum requirements for the role, but they do not need to have more than that, as long as they have the right mindset: Open to learn, broad experience, or interests, history of progress in their field, and nice people to work with. I am also looking for people that are used to think out of the box and that have a good level of autonomy.

I also understand that, when not working at a Big Tech company, it is not realistic to demand a huge effort in terms of the hiring process. It is difficult to find people in technology. And almost no one is available to go through a set of many high-demanding interviews if in the end, you are a start-up that has a cool product but a lower budget for salaries. So I aim to maximize the output with the minimum amount of time spent. I also try to maximize asynchronous time in interviews and accommodate the availability of the candidates.

After some tweaking, and inspiration from others, this is the approach I am using right now.

Job Ad

I try to create a simple job ad that has the following sections:

  • Brief description of what the company is, and what it does.
  • Clear role responsibilities, only the most important (7 maximum).
  • Must have realistic requirements, with lot’s of keywords of what we use.
  • Nice to have requirements, they have to be separate so people don’t fail to apply if they don’t have them.
  • Clear instructions on how to apply and what to expect.

Choose Candidates

After receiving their CVs, I go through them doing my best to focus on the technical skills that are required for the job. Not on the nice to haves, and certainly not on age, gender, and other silly things. If the person has the skills necessary, they deserve a chance to show why we should hire them.

It’s important to note that I also look at all the information on the CV in detail if the person has the necessary skills. The same way I expect candidates to read the job ad carefully and get to know my company, it is my job to respect them and carefully read their CV. For me it’s silly to be asking things that are clearly explained on the CV.

First Interview (30–45 minutes)

On the first interview, I aim to:

  • Explain well the company and the role, and make sure it’s clear for the candidate.
  • Understand what the person likes about this job, and how it fits in their career path.
  • Ask about anything that was not clear to me after reading the CV.
  • Explain the recruitment process.
  • Explain the take home assignment (which not everyone gets).

Take Home Assignment (1–2 hours)

For each role, I identify 2–3 top candidates, and then send them the take home assignments, together with the detailed instructions on how to do them.

The assignment is an high level explanation of a problem that is similar to what the company actually does, and focuses on System Design of such solution, as well as communication (email to Product Owner with questions, or something similar). This way I evaluate both technical depth, and communication skills. It is not detailed on purpose, and normally has missing information. Even for junior candidates it works quite well.

The person has normally around a week to do the assignment, but the indication is that they should spend between 1 an 2 hours doing it. They are asked for availabilities for the second interview, so that they can do it in the time that is comfortable for them.

Once finished, they send the result of the assignment in the format that makes sense for them: Code, powerpoint, whiteboard, pen and paper scan, all is valid. But it has to be sent a day before the second interview, and be presented at the interview.

Second Interview (1 hour)

I always invite one of the team members to participate on this interview. Both of us will have seen the challenge response in detail, and we will be prepared to ask questions about the challenge.

The first part of the interview starts with the candidate presenting how the challenge was solved, and then we ask questions to understand what other alternatives were thought, the reasoning behind the solution, and then some questions about how different the solution would be if X or Y happened.

This is again aimed at evaluating technical depth, and communication skills.

After that, I ask several behavioural questions, with the format: Tell me of a time when such and such happened, and how did you deal with that situation? The aim is to understand how the person acts in different scenarios, and was inspired by the way Amazon does the interviews around their Leadership Principles.

Offer

After all the interviews of the second rounds are done, I have a meeting with the team member that participated in the second interviews, and we decide together which candidate we want to choose.

Once we decide on someone, I send an offer by email describing in detail de offer and the benefits. Sometimes there is some negotiation involved, but I always aim to present an offer that is competitive, and rarely have a margin of negotiation. This is clearly stated on the offer, explaining that this is the best I can offer according to the budget and what other people earn in the company. Of course, for me to able to do that, Current employees do need to have their salary updated every year.

Once the candidate accepts the offer, then I pass the process to the HR department. I also make sure to contact the candidates often until the start of the contract, so that they feel included.

Feedback

One of the worst feelings for me when applying for positions is being ghosted by the recruiters. So I aim to this for every candidate:

  • Everyone gets an email telling them if they passed to the next phase or not.
  • For candidates that get to be interviewed, I try to add on that email what we really liked about them, and why we decided to carry on with other candidates.
  • When there are delays on the process, I try to inform all the candidates by email.

It’s important to note that this approach works well for small and medium companies, that can have reasonable average salaries.

Bigger companies need to have a more standardised hiring process, and they also have a lot more candidates available. They also pay considerably higher salaries compared to the average on the market. So I understand why when they are hiring, they have you go through a process that is high demanding both in terms of time and skills (technical or others).

You have to have a realistic and pragmatic approach, where you recognise if your company really can afford to hire “rockstars”, or if the fit for you is actually the competent average engineer that is capable of doing the job. From my experience, if you hire something capable with growth potential, you will be amazed with what they will be able to do if you invest in them. Some will become “rockstars”.

I am looking forward to your opinion, we are all still learning. Please add your experience.



News Credit

%d bloggers like this: