Navigating frontend interviews in 2022: onsite interview — live coding challenge

The live coding challenge is your quintessential "programming interview". You sit with a laptop and work on a problem in front of your interviewer. It’s not enough to be good at coding, unfortunately. Live coding is its own skill.

This is the third post in a series about what to expect from the frontend interview process in 2022. Here’s where we are in this series:

1. Overview and reverse interviewing
2. Researching your company
3. Informational phone screen
4. The onsite interview — live coding challenge
5. The onsite interview — behavioral
6. The onsite interview — systems design
7. Offer and negotiation

Tactics

A few tactics you can use to maximize your chances of success:

1. Clarify the requirements first
2. Share an outline of your approach
3. Talk A LOT
4. Get it working before optimizing
5. Practice, practice, practice

Let's talk through each of these:

1. Clarify the requirements first

Take notes while your interview is giving the prompt. Avoid asking them to repeat themselves.

If you hear the prompt and start coding right away, you’ve almost certainly made a mistake. Ask questions to make sure you’ve understood the details.

Think through edge cases in advance. If you’re building a UI, think about invalid user input, error messaging, different screen sizes.

If you’re doing a more backend JS problem, think through the different range of inputs, e.g. invalid data types, negative numbers, empty arrays, null, etc.

Ask your interviewer what edge cases your solution needs to cover.

Interviewers (intentionally or unintentionally) leave things vague. Clarifying requirements is your job as an engineer. Do it during the interview too

2. Share an outline of your approach

Before you start working, talk through what you’ll solve first and where you anticipate running into problems

This has 2 benefits:

1. It clarifies your own thinking
2. It helps the interviewer follow your train of thought

Oftentimes, interviewers will offer guidance when you get stuck. If you don't provide an outline, they may have no idea what direction you’re taking and be unable to help.

3. Talk A LOT

The worst way to solve a live coding challenge is silently. These challenges assess your communication as much as your coding.

There should rarely be long stretches of silence. If you’re sitting silently staring at your screen, talk about what you’re thinking about.

As a hiring manager, I'd rather hire someone who gets 75-80% of a problem right and is a great communicator than someone who nails the problem and doesn't talk at all. No one wants to work with someone who has all the answers and can’t/won’t explain themselves

4. Get it working before optimizing

As with many things in life, it’s easier to bang out a rough draft then go back and edit. So don't worry about code cleanliness or performance on your first pass.

Getting a working solution is going to earn way more points than beautifully-optimized code that doesn't solve the problem.

In the vein of “Talk A LOT“, explain that this is your approach before you go about it. Most interviewers will assume this is what's going on, but better to be explicit

5. Practice, practice, practice

Coding in regular conditions is quite different than coding in a high-pressure, timed environment with someone looking over your shoulder and expecting you to talk the whole time

There are a few sites where you can do mock interviews with peers or experts, free or paid:

• Interviewing.io (paid)
• Exponent (paid)
• Pramp (free)

Interview styles

In our experience, there are two flavors of problems you're going to deal with:

Leetcode-style

This style of interview is based on sites like Leetcode and Hackerrank. You can expect to find questions such as “find the contiguous subarray of an array that produces the largest sum in the most efficient way possible”. In other words, stuff you never do as a frontend engineer.

Companies often put artificial constraints on you during these questions: no Googling or running your code. Your company may even have you write code on a whiteboard. It’s mind-boggling that companies are still asking people to write code on a whiteboard in 2022, but it still happens.

Thankfully, this style of interview has fallen out of favor with many companies assessing frontend candidates. However, it’s still popular for historical reasons. Interview culture takes a long time to change.

It's worth noting that the types of questions that a company asks about during its interview process says a lot about the types of talent it attracts and retains.

If your company is relying on coding challenges like this, it's not actually testing whether or not someone is good at frontend development prior to hiring them as a frontend developer. You may join a company only to find that no one around you knows how to write CSS.

Practical

Companies are increasingly simulating your work environment as best as possible in their interviews. What this looks like specifically is:

1. Code in whatever IDE/editor you want: VSCode, Sublime, Atom, Emacs, vim, etc.
2. Look up whatever you need to look up on Google, Github, Stackoverflow, etc.

This type of question allows companies to get more of a sense of how you perform in the normal course of doing your job. It also allows them to ask more complex questions in the UI/UX sense.

Quick pitch for the exercises on frontendeval to help prepare you for these questions.

Other than general guidance about practicing, here are a few things to pay attention to when you search for information:

1. Never copy and paste code you find on Stackoverflow or anywhere without carefully reading it and understanding what it does. It reflects extremely poorly on you if you fail to consider the context and limitations of code you’re introducing into your solution.
2. For the same reasons as thinking out loud when you code, don't search in silence. Talk through your process and tell your interviewer what you're looking for.

Remote interviews

COVID has moved so much of tech corporate culture online so you may end up doing this interview remote. Also, regardless of whether your “onsite” interviews are in-person or remote, you’ll likely have one technical phone screen as well that takes place remote.

The above resources in “Practice, practice practice” will have you interview remotely, so you’ll get some practice with this if you follow this guide.

Specifically, ask your interview what tools you’ll be using for remote interviewing: a remote coding tool or screensharing your own environment.

Remote coding tool

Coderpad and Codepen are among the more popular tools used to issue remote coding challenges, although there’s a broad ecosystem of other tools.

Most tools for this purpose are intuitive to use, but you're going to want to familiarize yourself with them in a high-pressure time-sensitive context. The two tools listed either have free or demo versions, so get comfortable with them in advance.

Things to look into:

1. Keyboard shortcuts
2. Adding libraries
3. Syntax highlighting and auto-indent nuances
4. How to run and debug code. Codepen in particular has a not-so-obvious console feature that doesn’t show errors.

The tool used for your interview is often a giveaway of what the type of problem to expect. If the tool has a visual component with HTML/CSS, like Codepen, you may be asked to implement a UI. If the tool has only a code component (and potentially a console for running the code), you'll be doing a JS-only problem.

Screensharing your computer

Some companies allow you to use the environment on your own computer to complete the coding challenge. This is a good opportunity to showcase how productive you are in your particular editor/IDE.

Get used to screensharing your entire computer screen if you’re used to only sharing a specific window. If you’re allowed to look at documentation or Stackoverflow, your interviewer will want to see your search process as well. You may need to switch between terminal, editor, and browser frequently.

Remember to silence your computer's notifications and close all your other browser tabs to avoid any embarrassing situations.

Wrap up

Just to reiterate one more time: live coding is very different from your day-to-day job. It exercises different skills, and you need to practice it!

Note: none of this is an endorsement of live coding as a way to assess candidates. There is plenty of research on how the timed elements bias the interview process. But these things aren't going away anytime soon. We want you to be set up to succeed regardless of how silly they are.

What’s next?

In the next post, look at how to prepare for behavioral interviews. Follow @frontendeval and stay tuned for more!