In any technical job interview, you can almost always expect a code challenge to demonstrate your skill set to your potential future employer. Now, you might hear the phrase “code challenge” and begin to sweat – job interviews are already stressful, right? Don’t panic, code challenges are an integral part of any technical developer interview and with some careful planning and determination, can help you get that new job you’ve been searching for.

At Emergent Software, we use take-home code challenges in both our Software Developer and SQL Server DBA interviews, to gauge our future teammate’s skill. When interviewing prospective candidates, we often see recurring errors that disqualify someone from moving on in our interview process. We sat down with the reviewers of our development and SQL code challenges, Mike Allen and Kevin Martin, to learn more about the common mistakes they see candidates making. Let’s dive into the five common reasons people fail our SQL and development code challenges and learn about how you can avoid those same mistakes in the future.

Mistake #1: Candidate did not completely read the requirements

The first mistake we often see is that a candidate didn’t read the requirements fully. Before even beginning to write code for a challenge, take a few minutes to read over the entire set of requirements that you’re being tested on. It can be tempting to hop right into writing code and reading the requirements later but taking that step back to fully understand the problem is always the best place to start. Plus, it gives you a moment to collect your thoughts, which we likely all know from experience, might be racing during the interview process.

Mistake #2: Candidate’s code uses hard-to-follow logic

The next mistake we see is that a candidate created code that was hard to follow and doesn’t make sense when trying to understand their logic. Now, this doesn’t mean we’re suggesting that someone can’t go above and beyond in their work but instead needs to create a final solution that isn’t over-complicated and realistic. Mike Allen, our Principal Software Engineer, stated that “Some developers do their challenge as if it's an enterprise-grade project and I don't ding them for it. It's more of a problem when the code is convoluted and hard to follow.”

We create solutions that solve real-world problems for our clients and building a program that is overly complex and hard to use isn’t fair to anyone involved. Try to build solutions that solve the challenge and demonstrate what you know well, without making things more complicated than they need to be.

Mistake #3: Candidate did not solve the problem 

In addition to seeing candidates present solutions that have hard-to-follow logic, we also, unfortunately, see candidates who did not solve the problem completely. This happens for several reasons: the candidate didn’t read the full prompt, understand what was needed to be built, didn’t ask any questions before coding, ran out of time, etc. Regardless of the reason, it’s in your best interest to completely understand what problem needs solving before you begin coding. Going back to Mistake #1, it’s important to your success to completely read the problem that you’re being asked to solve. And if you have a question – ask! It is always better to ask a clarifying question or two than to code without knowing what is being asked of you.

Mistake #4: Candidate submitted sloppy or poorly formatted code

Kevin Martin, our Director of Database Development and Administration, noted that he often sees candidates who don’t format their SQL code properly, remarking “A lack of code formatting shows a low level of craftsmanship for a candidate’s work.” Kevin’s biggest piece of advice to avoid this common mistake is to learn to format your code as you develop it with proper casing and tabs, or use a web formatter after you write it. On the development side, Mike stated that he has seen sloppy code get submitted during a challenge, whether that’s from copy/pasting code or poor use of white space. He said that errors like that can definitely raise a red flag in his mind.

Overall, poorly formatted code greatly impacts readability but also maintainability, change history in source control, and more. Keeping your code properly formatted is something that when done right, can save the next developer or DBA who has to read your code a lot of time.

Mistake #5: Candidate did not follow industry-standard development practices

Kevin also noted that there are standard practices for writing T-SQL code, which he notices that many developers often don’t take the time to learn and understand before starting in the industry. While some of this can be learned on the job, it’s imperative to always be reading/taking coursework to advance your skills, learn about best practices, and follow them. For our development code challenges, Mike recommends that you should show that you know how to follow modern development design patterns and current technologies, saying “Design patterns make it easier to follow the flow of your code and collaborate with other developers. If you choose to use older technologies, you’ll need to be able to defend your decision.”

Hopefully learning from the mistakes others have made helps to put you at ease and makes you feel more prepared for an upcoming interview. We’re always looking for top talent to join our team and have continued to grow throughout the COVID-19 pandemic. Interested in learning more about our open positions? Check out our careers page!