Ah, the dreaded coding interview. Hated by so many, and with good reason! I've been working in tech for 12 years, so I've been both the interviewer and interviewee many times.

---

Honestly, I think the tech interview process has significantly improved in the past few years, but it still has a long way to go. I've also come to terms with the fact that interviewing is seriously difficult. At different points in my career, I thought I had the answer to making interviewing better, but every option has its drawbacks.

Let's talk about a few common interviewing strategies and where they succeed and fail.

# Interviewing Strategies

I've seen 3 schools of tech interviewing over the years. A full day of on-site interviews, a take-home with a few follow-up interviews, and contract-to-hire.

# Full day on-site

This was the "standard" tech interview for many years. It typically consists of a recruiter call followed by 1-2 technical phone screens. These usually involve pair programming but often are "easier" questions than you're likely to face later on. If those go well, companies will often fly you to their office for an on-site or (in COVID times) set up a full-day interview panel over Zoom or Google Meet. If these go well, you get an offer!

# Things I like

I like that the interview is extremely time-boxed. If you're busy with a current job, family obligations, etc. -- it's nice to have a maximum number of hours spent interviewing. This is even more true if you're interviewing at multiple places.

Years ago, it was common to be asked completely unrelated compsci questions no matter your skillset or what position you were interviewing for. I "think" this has changed in recent years. Many interviews I do as a JavaScript developer focus much more on web development than more "back end" concepts like advanced data structures and algorithms.

# Things I dislike

Having 5-7 strangers come up with random questions and ask them to you on the spot is stressful! You can study for hundreds of hours but forget to study a concept like "radix sort" and get asked to implement one first question! Some places offset this by sending you a list of possible topics beforehand. Other companies insist that you use Google or StackOverflow whenever you need them during the process. It's still stressful going into a panel where any subject in computer science is on the table.

Full-day on-site interviews bias towards folks who perform well on the spot. I can't count the times I forgot how to spell a word or forgot the name of a common JavaScript method when in a small room with a stranger, marker in my hand.

# Take home interviews

A few years ago, take-home interviews became very popular. Typically you'll still have an initial call with a recruiter or hiring manager, but then, instead of a phone screen, you'll be sent a take-home project to complete on your own time. Sometimes these are vague (a writing prompt like "build an image carousel"), and other times they are very specific (a HackerRank link that tracks time spent or a partially complete project for you to work on).

Typically, companies that do take-home challenges structure the follow-up "on-site" interviews around the completed project. Maybe they'll ask you to add more features, walk through the code you wrote or discuss trade-offs you made along the way.

# Things I like

Take homes result in way less performance anxiety. You can sit down in the comfort of your own home with a nice cup of coffee and work at your own pace. No one is watching, so you can use Google or look up "silly" things at your leisure. It simulates real programming work much more closely.

# Things I dislike

Unless the question is strictly time-boxed, you are essentially competing for a job against the person who spent the most time on the project. Once I had a company send me a prompt, and in the email, they said, "You should spend no more than 4 hours on this project." I finished and sent it in. Later, I received a rejection during which they told me all about the incredible submissions they had received with complete documentation, 100% test coverage, or extra features added on top of the prompt. I felt so foolish for only spending 4 hours on mine.

# Contract-to-hire

Contract-to-hire has been around for a long time but has made a recent resurgence in the tech industry. The idea is that after passing an initial phone screen with a recruiter or hiring manager, you're brought on to do real work for which you receive real compensation. Some places offer full-time employment for a month or two. Others just ask for a few hours a week, which you can do on top of your current job.

# Things I like

Contract-to-hire probably gives the best signal of how you work. You don't need to study or perform well under pressure. It also is a two-way street! You get a chance to see how the company really works and how well you fit in. Also, money is nice!

# Things I dislike

Contract-to-hire has the highest time commitment by far. It's just not an option for folks who:

• Are on visas
• Are already stretched too thin
• Don't have a current job and need health insurance

# They all sound bad; what should we do?

I think switching up the format is the wrong approach. Switching from an on-site to a take-home feels like a lateral move. Instead, companies should focus a lot more on giving candidates the best experience possible. This includes:

Unconscious bias training.
Lists of approved questions.
Asking candidates for feedback on the process.
Creating an interview rubric.
Analyze interviewer feedback.

Let's dive into a few of these things!

# Unconscious bias training

What are unconscious biases?

Unconscious biases are social stereotypes about certain groups of people that individuals form outside their own conscious awareness. Everyone holds unconscious beliefs about various social and identity groups, and these biases stem from one's tendency to organize social worlds by categorizing.

I've worked at a few places that offered bias training for new interviewers, and I found it excellent. A lot of easy tips for helping create a more fair and equitable interview process. I think some sort of "Interviewer training" should be mandatory at medium to large companies. Making sure everyone is representing the company well and helping create a diverse and successful workforce.

# Lists of approved questions

I could go either way on this one. Lists of coding challenges leak out, end up on Leetcode, and can be a pain to maintain. I still think it's essential to make sure each question asked is fair and appropriate for the candidate based on the role.

# Asking candidates for feedback

This one can be a bit tricky. Candidates are unlikely to give you honest feedback while still waiting for a potential job offer. I've seen this done well a few times when companies send out an anonymous survey after the on-site site. Other times recruiters can do a good job convincing you that whatever you say will have no bearing on the interview outcome.

You could also do this by making sure someone at your company spends time on sites like Glassdoor reading the anonymous feedback.

# Creating an interview rubric

So much can happen in a 45-minute interview. It's difficult to distill it all down into a "hire" or "no hire" result. I think companies must spend time devising a rubric to help interviewers evaluate candidates. Things like:

• Did the candidate figure out a brute force solution?
• Was the candidate able to talk through their approach?
• Did the candidate receive feedback well when prompted?

This way, you can collect lots of data and use it to improve your hiring pipeline, interview questions, and expectations.

# Analyze interviewer feedback

One of the best parts of devising a rubric and having a list of approved questions is getting a lot of data to learn from! It's nice to see things like:

• Average score given by each interviewer (Maybe a 4/5 from one person is the same as a 5/5 from another!)
• Questions that candidates often do poorly on.
• Interviewers candidates enjoy talking to.

# A note on kindness

I've had the privilege in my career to end up with competing job offers multiple times. While I'd be lying to say that salary and perks didn't play a role in my decision-making process, I think it's important to note how important kindness is for me.

Every time I've had a tough decision to make, I've chosen to go with the kinder company. A transparent recruiter. A hiring manager who is easy to talk to. A friendly interview panel where it felt like they wanted me to succeed. That makes a huge difference, and so far, I've had no regrets about my strategy.

Be kind!

---

• ← The age of the devtool startup
• Switching to DevRel from Engineering→