Refactoring the coding interview

Being interviewed: Senior developers and code assignments

I have switched jobs recently, and I found myself doing some interviews. I have never been nervous nor feared interview processes as I tend to approach them with a learning attitude, both as interviewer and interviewee. However, I found some code assignments too demanding for some candidates.

I have seen a lot of bloggers on the last three months posting (or complaining) about code assignments in the interview process so, why am I also blogging about this? Because I will be talking from my recent experience about what I enjoyed, disliked and loved and what I am looking for when I’m being interviewed.

---

Companies need filters, because we might get thousands of applications per posting, and with some tools like Greenhouse, Freshworks or Lever, we can automate part of the process, where any candidate is sent directly to one of those screenings. But what is the appropriate screening process for candidates?

Basic algorithms or programming assignments on Hackerrank or similar platforms are a good filter for entry level positions but only adds some time delays on more senior candidates. Good candidates that are actively looking will take less than one month to find a new job and companies want to move faster than their competitors on this high-demanding environment, so any delay on the process can make a company to lose an opportunity.

When you reach some level of seniority, it is not selling yourself anymore. You are also buying.

When I was younger I faced all my interviews trying to sell myself, to rise above the rest of the candidates. I wanted to get a job and learn, so I almost did my research outside of the interview process. I was the one applying to jobs, so I was the one who felt scrutinized.

As I have acquired more skills and experience, I have also noticed new habits when I look for new opportunities. I rarely browse for openings but either contact some trusted recruiters, use my contacts network or directly, write HR managers on the companies I might be interested in. But, during the interviews, I am the one scrutinizing them.

The interview process

I did that with Thoughtworks and lastminute.com last month, as well as replied to some recruiters that were contacting me.

I discarded a lot of interviews when the process felt copy — pasted. Those recruiters that took time to talk with me and see if we were aligned got me in the process, while those with automated pipelines sending me standard emails got discarded almost immediately. Not to talk about those taking two or more weeks to reply to an email…

Seniors, leaders, or managers will rarely be applying to positions but positions will be offered to them, so having them to go through a long process without feedback or previous information is almost instant no from them.

Also, there is a relation between experience and age, and that often implies that senior candidates potentially have families. This, tied with sometimes very high demanding responsibilities, make difficult for the applicants to find time to do the coding challenge. Who can spend a weekend coding for an interview after fifty hours working without seeing the family?

We, candidates are not just selling ourselves but also buying companies.

We don’t get a job, we join a company, follow a leader or work with a team.

But I need to know if you can code!

Exactly! But not only that! You need to know if I can solve problems within your team. If I can understand your code, improve it, fix things. And doing an assignment at home, does often not prove that.

I have had candidates leaving a process because the assignment was going to take much time, or they were not allowed to use the language they felt more comfortable with, or candidates failing a code screen because they did not know the estimated amount of time or number of questions in advance and could not plan according. This even happened to me on a process, doing the assignment with low bandwidth(took 15 minutes to upload a 45 minutes typing session) when after finishing the upload a new question appeared on the wild, no prior notice… leaving my time-box completely blown.

Let’s walk through types of screens / interviews and a basic list cons and pros for companies and candidates based on resources/time dedicated to the interview, how prone to keep the interest of the candidate the process is and how easy is to validate software engineering skills or other soft skills.

The technical filter

The technical filter feels like a quiz, not an interview. In this kind of filter, interviewer asks several questions to the candidate, no matter how comfortable he or she is feeling. This is a company-buying-workforce type of interview. The candidate is not usually engaged in a conversation, and it requires a senior engineer with people soft skills to do it right (to make it more like a conversation or a two-way interview). Most companies have this filter earlier on the process and more than often it is the very first conversation between the company and the new possible hire.

PROS

• It helps a lot to filter out unaligned candidates (technically).

CONS

• It requires a senior engineer to perform the interview.
• Candidate might feel like in an exam. Senior candidates need to buy the company and this process does not give them much information about it.

The coding screen

Here, the candidate is given a time constrained series of problems in a tool or service like Hackerrank. Usually, algorithms, data-structures or database knowledge is tested but can grow as complex as the company needs.

PROS

• For the company, it helps out to filter junior level engineers.
• Fast to give feedback to candidates.
• No need of own engineers to get involved in the process at this stage as recruiters themselves can direct the candidates to the exercises.

CONS

• Senior candidates might find the problems too easy and loose interest in the job or reject to invest time without some calls first.
• The candidate might have a bad day, connection issues or just choose a bad solution with no reaction time to adapt. This might lead to loosing qualified candidates too early on the process.

The home assignment

Similar to the code assignment above, the home assignment just takes longer, needs some research or specific knowledge and engages the candidates with more complete solutions.

I have seen this kind of filter too often lately. I have been asked to spend a significant amount of time working on a problem, posting the code to a repository and then engaging with part of the company’s engineering team in an offline conversation via merge requests.

PROS

• Gathers a lot of information about how the candidate approaches a given problem (research, architecture, reading existing code if a template project is given to him or her…).
• Involves the candidate with the team, that is, helping him or her to understand how his or her future coworkers deal with his or her code.

CONS

• The candidate might not feel comfortable enough with the toolset (i.e. asked to work on a given framework, library or language).
• It might need a significant amount of time from the candidate (I have seen assignments that took a couple of full time days).

Whiteboard / master class

I was once this kind of interviewer (sorry!). There is a simple problem with a simple solution that can spawn a conversation about performance and several advanced topics. Usually this problem falls in the comfort zone of the interviewer who can drive the conversation wherever she / he wants.

PROS

• Gets to know the candidate.
• It is arguably easy to drive the candidate through different concepts / skill sets.

CONS

• Requires a lot of practice from the interviewer and a senior engineer to perform the interview.
• Can get the interviewee nervous if the interviewer misunderstands the skill set of the candidate and goes through difficult questions too early.
• Fairly subjective and not easy to standardize.

Code interviews re-imagined

Why we do refactor our code but not our habits or other processes as frequently as our code? Code interviews have been like above for decades now. Sure we have new tools and reports, but the interviews itself keep being the same format.

This is how some processes have evolved in the last years:

The WIP assignment

Similar to the assignment above, but way simpler and with one premise in mind: once finished, if the code passes to the next interview / stage, it will be refactored based on new constraints in a pair-programming session (see below)

This what I did at lastminute.com, a simple assignment that took around one hour to complete, using my language and tools of preference.

PROS

• Leverages the home assignment to be shorter and easy, establishing a base for the next interview.
• Done properly leaves space to the candidate to make the choice on language and tools of his or her preference.
• Can also drop candidates if the code is not good enough.

CONS

• Still requires some effort from the candidate.
• Needs to be reviewed by some engineers (hopefully won’t take as much time as the full assignment).
• The company needs people with some experience in the language and framework the candidate might have chosen.

The pair-programming session

At Thoughtworks, you get a pair-programming session. There is a task you need to tackle with your buddy and during the session your buddy swaps with a new buddy. You can choose the language of your preference, and you can use some external tools if needed.

This is also how the second part of the WIP assignment above works on other companies (i.e. lastminute.com) and to be honest, felt amazing to evolve your own code as part of the pairing session.

Other companies use a similar approach, for example, tackling a long-standing non important bug in real code together with the candidate and trying to solve as part of the onsite interview day.

PROS

• Engages the candidate within the team. It is a pair-programming session, so the buddy is responsible also to help the candidate to solve the problems they face.
• Identifies not only coding skills but also other skill like analytical mindset, communication skills and / or working under pressure.
• Feedback is given by two or more interviewers, not just one (on the same interview).
• Senior enough candidates who architect the solution themselves feel owner of the proposed solution while junior candidates can follow their buddy’s guidelines.

CONS

• The company need to book two engineers to interview each candidate.

Conclusion

If I had to summarize this post in a TLDR it would be something like

Senior engineers do not need an interview filter. Their CV or LinkedIn profile is the filter and some reading and checking from recruiters or other engineers is mandatory prior to invite them to the onsite interview.

I strongly agree with that statement (after all is mine), specially after a month of being interviewed almost every week. I enjoyed those processes that involved me, gave me feedback and were two-way communication lanes. They required from me the same amount of effort they were putting in the process.

They never asked me for some time which did not involved a two-way communication and even when I had a WIP assignment, it was properly communicated and short (took less than one hour). The interviews did not feel like exams, but conversations, and we were exchanging ideas, opinions and knowledge. This is the right way to do the code interview, working together to solve a problem.

As a close friend once said to me:

Be aware: seniority is different from leadership. Companies that are looking for senior engineers might be looking also for leaders, but that is not always the case. Make sure both you and the company you are being interviewed at are aligned.

Seniority <> Leadership.

If you want more than a senior position, but the company has already people leading teams, you might not find space to grow and feel happy.

And being happy at work makes the difference between stressed and ownership.

Originally published in Medium