linkedin Skip to Main Content
Just announced: CoderPad Play! Engage your team with fun technical challenges.
Back to blog

How to Run Front-End Developer Interviews That Don’t Suck


Interviewing developers is hard.

Even if you’ve been doing it for 14 years, you’re spending a lot of time and energy to ensure you find the right candidate AND show the candidate why they should want to work for you.

And, of course, there’s always the risk that you spend all that effort on the wrong candidate. The one who lied about their coding skills, doesn’t work well on a team, or simply doesn’t know how to communicate.

Many factors go into creating a good interview – the size of your company, the type of role you’re interviewing for, and candidate experience level are but a few.

✅ One process consideration is the number and type of interviews and assessments you’ll use. Are you a big company with lots of applicants? You may want to use a screening tool like CodinGame. Are you interviewing for more senior roles? You may want to skip straight to a live interview coding session with CoderPad

Front-end engineers don’t just need to know how to code navigation menus and drop-downs. They need to understand design basics, how to interact with the back end, and how to turn design requirements into a functioning user interface.

We’ll show you how to create suitable front-end interviewing questions, how to structure your interviews, how to assess a candidate during the interview, and how to get excellent candidate feedback.

We break it down into three parts:

  1. Interview preparation: How to develop good questions for every experience level
  2. During the interview: How to structure them and what to watch out for in the moment
  3. After the interview: How to collect and implement feedback

Interview preparation: Developing good questions

Preparing for the interview is perhaps the most essential step in hiring a front-end engineer – or any engineer. A prepared interviewer shows the candidate that you care about their interview experience and that your company is a place that the candidate would want to work at.

The most important aspect of preparation is matching your interview questions with the candidate’s level of experience and background. We break down how to create good junior, intermediate, and senior developer interview questions in a moment, but here are some points you should keep in mind at every level when choosing or creating interview questions: 

  • What tech stacks is the candidate used to? If you’re flexible or willing to upskill a new hire on the tech you use, then you can create a Plain Text question and let them answer it in the language of their choice. If you’re looking for experience with a specific framework or language, then you should only create questions written utilizing that framework or language.
  • What experience is transferable? For example, can a candidate with Angular experience apply similar/common concepts from Angular to work through your question in Vue?
  • Does the question represent an actual job task? Don’t insult your prospective coworkers with computer science trivia or algorithm questions – make sure the question reflects what they’d actually be doing on the job. This ensures you’re evaluating skills that are actually relevant to the role and mitigates bias that favors people with traditional backgrounds.

Flexibility is key here. It’s easy to assign the easy question to the junior engineer or the difficult question to the React developer with seven years of experience. But what about the senior back-end engineer with lots of JavaScript experience but no front-end framework experience?

By the end of this section, you should have a better idea of what kinds of questions fit most appropriately with a candidate’s experience level. So let’s begin.

Junior developers

When crafting a question for junior developers, focus on basic coding principles and concepts.  For the front end, this usually means understanding JavaScript, HTML, and CSS fundamentals.

You may want to start junior candidates with a take-home assessment that can quickly tell you if they have the minimum skills needed to succeed on your team.

If they pass the assessment, follow up with a live interview where you review their take-home results and allow them to build upon the code they wrote. Since junior developers generally need more assistance during the interview, it helps to create a question that lends itself to a pair programming exercise.

Some things to think about when you create a question for a junior dev – can they use math functions correctly for displaying HTML elements? Can they resize images like pictures and bars in a bar chart?

The question will depend on the specifics of your business, but you should focus on the junior engineer’s ability to carry out essential UI development.

In this example question below, we ask candidates to render a simple bar chart from a given set of data. This is similar to some of the usage charts we provide in our dashboards and therefore represents a task a junior developer would carry out at CoderPad.

Intermediate developers

With intermediate developers, you should emphasize evaluating their ability to carry out business logic and styling.

A good exercise for these developers is to have them build a ubiquitous feature they use all the time. For example, drop-down menus and navigation bars are often taken for granted, making them good places for intermediate engineers to show that they understand the underlying styling and logic encompassed by these UI concepts.

We often ask prospective intermediate candidates to recreate a drop-down menu to see their thinking process and what they put time into versus what they sacrifice.

A nice-looking HTML element is good, but if they spend their whole time on styling and very little on making it work correctly, that can be a red flag. If they can’t get the drop-down to populate from an API call to fetch the values, they’re sacrificing necessary business functionality and may not be a good fit for your team.

You can also see how they cope with the design challenges that come up:

  • How do they populate drop-down menus? 
  • How do they ensure the drop-down and other elements on the page don’t overlap one another?
  • How does the drop-down interact with other page elements?

Good intermediate questions usually have multiple facets – like CSS styling and business logic – that the candidate can focus on during the interview. Which facet the candidate focuses on can be an important signal for both their strengths as well as where their development priorities lie.

Consider asking them about the different technologies they’d interact with as a front-end developer at your company and how those other technologies work together. They might not know how to use those technologies directly, but they should know how they fit into the application technologies’ grand scheme.

For example, how would they consume a message from an Apache Kafka topic? What are the fundamental differences between GraphQL and traditional RESTful API requests?

In this example we ask the candidate to recreate a tabbed UI interface, much like the browser tabs you have at the top of your screen right now.

Senior developers

We recommend focusing primarily on the complex business logic they’d be working on for senior engineers. These questions should be more open-ended, as these are the types of challenges that senior engineers will usually face on the job.

For example, at CoderPad, we have a handy form that allows you to create questions to use in interviews. We often ask senior-level engineers to mimic creating a form like this. Some of the business logic they have to consider:

  • How do they validate different fields for the correct data type?
  • How do they ensure required fields are filled in?
  • How do they ensure that field B, dependent on field A’s value, fills in with the correct default value?
  • What data structures are best suited for defining the shape and flow of the form?
  • How can they create the form such that it is flexible enough to handle future changes to field groupings?

Senior developers should also understand how different technologies fit into your application’s architecture and how they interact with the front end.

In this example we ask senior developer candidates to use a GraphQL API to gather data from a website and then display that data in the UI.

Final question creation tips

Have questions sanity checked.

Have your teammates or other interviewers check your questions to make sure they make sense.

Create questions that allow you to turn the interview into a discussion.

Discussions will give you a better gauge of a candidate’s fit on your team than silent observation. Try to create questions that allow you to dig deeper into a candidate’s code and thought process.

Keep in mind there is a time limit! 

Don’t try to get a candidate – even senior developers – to build a whole website in 60 minutes. Focus on the more essential aspects of the job they’d be doing; a candidate can produce meaningful work without creating a pixel perfect UI.

Leave room for creativity.

There is seldom a single way to solve a front-end problem. Structure your questions to allow the candidate to start implementing a solution, then iterate on that solution through discussion and pair-programming.

Consider having multiple questions per experience level, especially for intermediate and senior-level engineers.

For example, if you’re having trouble recruiting for a specific language or framework – like React or Angular – you can increase your candidate pool by interviewing candidates with related experience.

If you need a React developer, you may offer a back-end developer with vanilla JS experience a similar question in vanilla JavaScript. You can teach many of the nuances of frameworks on the job if the candidate knows the fundamentals well enough.

Develop a rubric for good/better/best implementations

Whether it’s a junior developer looking for their first engineer role, an experienced back-end developer looking to get into front-end development, or a tech lead, you’ll want to ensure that the question accurately assesses their ability to get the job done.

No matter what role you’re interviewing for, it’s a good idea to make a note of what an “okay, “good,” and “better” implementation may look like. 

Not only will this help you guide the candidate in the interview – can they recognize room for improvement? – but it will help you stay consistent when it comes time to evaluate the candidate’s work.

For example, for the junior engineer “bar chart” question example we listed above, we list this rubric in the description for the interviewers:

Very simple implementation: Candidate just uses the counts as a pixel width
Simple implementation: Candidate calculates the percentage of cell width from count / total words
Better implementation: Candidate calculates the cell width percentages against the highest count

Other things that might be good to look for:

  • Do they use a table? Or what layout?
  • How do they deal with left column width?
    • Fixed width?
    • Make the right column full width?
  • Do they sort the columns so the go from high freq -> low freq?

Bonus points:

  • Add graduations along the count axis
  • Chart legend
  • Making different colors for each column
  • Changing color gradient of bar for higher counts

During the interview

Now that you have your front end question prepared for your candidates, you can now see them in action during the interview.

Walk through the problem and leave room for questions

Don’t automatically assume your question is clear to the candidate just because you created it and it passed a sanity check on your team. 

You don’t have to read the question word for word. Give the candidate a brief overview, give them a few minutes to read the question themselves, and then make sure you clarify any questions they have. 

Notice what questions they’re asking too. Are they asking about your design decisions on a mockup and figuring out what you’re trying to solve? Or are they simply just mimicking the UI from the mockup?

The higher the level of the candidate, the more you should focus on their ability to think critically about the design decisions and full scope of the challenge.

Are they taking accessibility standards into account when translating design requirements into a UI? Do they know when it’s appropriate to use a tooltip vs. a modal vs. a native browser alert? Are they validating user input? If so, how? Is their solution able to scale outside the immediate scope of the challenge?

After you’ve explained the question, don’t forget to give the candidates some time at the beginning of the interview to collect their thoughts – ideally without you or another interviewer watching. 

You can easily do this with Focus Time, a CoderPad feature that allows candidates five minutes to think through the problem and start coding their thoughts before allowing you to see what they’ve written. Studies show that giving candidates this space leads to better performance.

Try pair programming

Candidates invest a lot of time and effort going through multiple interviews with multiple companies. 

Pair programming during the interview is a way to make your company stand out by conversing with the candidates and helping them become comfortable with things they’re unfamiliar with.

Have a junior dev who has never written unit tests before? Take some time to show them how to set them up. Have an intermediate engineer who hasn’t used React Suspense yet? Give them a quick demo, and then have them give it a shot.

Not only are you helping to teach them something, but you’re getting an idea of: 

1) How they take constructive criticism

2) Their desire to learn new things

3) Their ability to quickly pick up and apply a new skill

Even the best developers can struggle during an interview. Pair programming helps reduce the natural stress and anxiety of coding in an interview setting.

Always be asking

Sitting back and watching a candidate code is not enough. To truly understand their coding style, you have to ask them why they chose to do what they did.

Why did they spend 45 minutes on the style sheet and only 15 minutes on the JavaScript?

How does their solution scale beyond the immediate requirements of the challenge?

Why would they opt for many localized data stores instead of hoisting state to a higher level in their application?

If you see something you didn’t expect them to do, ask them about it.

If you see something you think they shouldn’t do, ask them about it.

As mentioned above, use this time to create a dialog with the candidate. Encourage them to ask you questions if they get stuck or have thoughts about a better way to do something. 

After the interview

You’ll have your own criteria for what makes a successful interview, but before leaving the candidate, you should both give the candidate constructive feedback and allow them to provide feedback to you.

Interviewer feedback

You shouldn’t frame the feedback in a “this is what you did wrong” format. Even if the candidate could not display a basic understanding, you should still communicate it along with the positives. Say, “this is what you did well on, and this is what you can improve on.”

If you point out mistakes or errors, tell them what they could do to fix it. Tell them what impressed you about their solution. Don’t lie to them, but don’t be stingy with praise!

The interview process is filled with ghosting recruiters and inattentive hiring managers – so take the time to show even the candidates who didn’t do well that you care about them and their ability to do well in their careers. 

And just like asking questions during the interview, providing feedback also lets you know how they accept feedback. Do they take it gracefully and with gratitude? Do they clarify their reasoning further, or do they get defensive?

Candidate feedback

Just like how the candidate responds to feedback says a lot about them, how you react to feedback as an interviewer says a lot about what it wouldd be like to work on your team.

At CoderPad, we generally look for two types of feedback:

1. General feedback on the challenge:

  • Was the challenge relevant to the position you applied for?
  • Did you have to solve similar problems in previous roles you’ve had?
  • Was it interesting and engaging (or tedious)?
  • What could make the exercise more or less challenging?

2. Feedback on the interview: 

  • What did you think of the pair programming?
  • What would help make you more comfortable during the interview?
  • Did Focus Time help (if they used it)?

You want to gather candidate feedback first and foremost because it allows you to improve your interview process – including the questions you worked so hard on creating in the preparation phase.

Key points to remember

This article covered a lot of ground when it comes to conducting great front-end interviews, but we can distill the information into a few key takeaways:

  1. You should tailor the questions in your technical interviews to the candidate’s role and experience level.
  2. The interview itself should be a dialogue between you and the candidate.
  3. Always give and ask for feedback at the end of the interview.

And don’t forget – the interview doesn’t end when you hang up the phone or select “End Interview.” Remember to:

  • Finish taking any notes while the interview is still fresh in your mind.
  • Ensure all the appropriate parties review the playback for the candidate and provide feedback as soon as possible.
  • Respect the candidate’s time and mental health – let them know as soon as possible if they did or did not make it to the next round (or get the job offer). There’s no better way to trash your company’s reputation than ghosting potential employees.

Finding the best front-end engineer for your company can be challenging – but if you follow the tips we laid out in this guide, you’ll find the process much more manageable. You can also check out our guide for hiring managers on interviewing front-end developers.