Inside the Coding Challenge: A Hiring Manager’s Perspective

This post was originally published on this site.

At Hired, we often have opportunities to share assessment insights with employers who review them to evaluate potential hires. It’s less common that we have the chance to share those with candidates. That’s why we dedicated a full webinar session to offer engineering talent some coding challenge tips from hiring managers.

What is a coding challenge?

Coding challenges assess your technical skills as part of the interview process. They are an excellent way to flex your coding muscles and solve a problem similar to one the company may be facing.

Results overview: what hiring managers look for in coding challenges

In this blog, you’ll hear from:

Prakash Patel, Engineering Manager at Hired
Sumit Pal, former Sr Engineering Manager at Hired

Let’s walk through hiring manager expectations for assessments and the interview process.

Sample Result 1

This is an example of a solution a candidate proposed that looks straightforward. They’re running the eval function doing a quick return. While this solution works and passes all the test cases, unfortunately, they didn’t read the directions completely.

There is a note in the yellow box explaining you are not allowed to use any built-in function that evaluates strings as mathematical expressions, such as eval. The candidate didn’t read the instructions completely and for that reason, we had to pass on them.

Sample Result 2

What you see here is a little behind-the-scenes. As candidates are going through the interview process, they often run into these kinds of challenges. You might be presented with several test cases but you have to be aware of more test cases behind the scenes. You’ll be presented with a few test cases your code needs to pass through to be accepted but we might be checking for additional items:

Are we checking for empty strings?
Are we evaluating for certain edge cases where we might have incredibly long strings?

In this case, we’re building out a basic calculator. The solution here is obviously very thorough. It passed all the test cases here.

However, we don’t only look at the percentage or a particular grade or if all the test cases passed. We take a look at the code too. We were able to identify that this code is unfortunately not written by the engineer. This was taken from an online search and brought to our platform. It hits all the benchmarks, but it’s not genuine.

Sample Result 3

This is an example of someone implementing comments. This code is similar to the previous example. The candidate took an online submission and claimed it as their own.

For that reason, we disqualified them. In this type of solution, engineering managers and hiring managers consider:

Have candidates used appropriate variable names?
Is there an appropriate structure to the code?
Are there functions called appropriately?
What does the runtime look like for the code?

Obviously, it’s an idealistic solution they copied over, but we will notice aspects like good comments.

In this case, you’ll notice that while there are comments, they don’t add value. BC II and BC III, aren’t helping a hiring manager understand your thought process or the code you’ve written.

Sample Result 4

Here we have several different functions. While it’s not perfect, you’ll notice there are some comments missing. There are some generally good structures with several functions being defined. Many of the edge cases are handled here and overall it is a good solution, despite missing comments.

Sample Result 5

This is really well-structured code going in-depth with the comments. There is a healthy balance of too many comments and not enough. This leans a little bit on the higher side but these comments are more helpful.

They guide the hiring manager in understanding the thought process. They also help the candidate keep track of how they handled this scenario. Overall, it has a cleaner and more useful presentation for the hiring manager.

SQL-Based Questions

Sample Result 6

This question intends to assess your confidence and comfort with SQL-based questions and data problems. This example presents an easy SQL question.

The candidate tried to solve this problem using the “group by” statement and “order by” clause. It worked sufficiently for this problem statement but it would immediately fail once we start getting three or more records for each gender. We encourage candidates to read the problem statement first which is really important in a very simple SQL problem.

Also, we encourage candidates to not start writing solutions immediately. Think through the problem and all possible age cases. Consider how your solution might handle null values once you start getting the records.

Sample Result 7

This SQL problem can be solved with different approaches. In this example, the candidate tried to use the max aggregate function and a subquery.

To further improve answering SQL questions, I recommend candidates consider adding human-readable aliases. Additionally, putting your queries in a readable format before you submit them is really important.

Data engineering interview process

Data engineering interview processes are robust. We take a similar approach in sending out an assessment. Once the candidates complete it, we take it back to the team and review it. Then, we provide feedback to the candidates on where they could improve.

We evaluate submissions to determine the level. Sometimes we’ll receive candidates who may be on borderline level two or mid-level or borderline senior. We can use those submissions to help gauge what the next steps should be.

From there, we’ll have the hiring manager screen to understand what a candidate is looking to do in their next role. What are the interesting things they do on the side? Why do they want to work at this company? What are they looking to achieve in their career?

Following that step, we continue with the assessment – that original take-home assessment, similar to the coding challenges completed here. We have the candidate build on an additional feature in the original assessment. We walk through the process live with an engineer (or engineers) on the team.

Next, we have a systems design portion. Candidates design a system and walk through different edge cases. Candidates will offer insights into why they made design decisions and made certain tradeoffs.

Later, we have a cross-functional interview to ensure the candidates have some comfort working with the product or design team.

Following that, we regroup should we need to have additional discussions. We follow up on those on a case-by-case basis and come to a consensus.

I do want to highlight that the interview process may vary from company to company. At Hired, we have a 3-4 round process.

Candidates have the take-home assessment, hiring manager screen, and virtual on-site consisting of the cross-functional interview and the systems design portion. The process isn’t necessarily the same at larger organizations. You may do one take-home assessment and have another waiting for you on the other side. You may do a live coding challenge where you get on the phone and speak with the technical recruiter.

In those instances, I think you would approach things the same way. Make sure you think of edge cases and are thorough in your approach. It’s easy to get nervous but you have to remember to break things down and take it from there.

Traditionally, after that first step (whether it’s an assessment or live coding challenge) is some form of an on-site. It could be a virtual or in-person on-site. Some large organizations even bring people on for an entire day.

As you’re speaking to the technical recruiters, ask about those processes. Usually, companies are open about informing you.