As the primary hiring manager for Software Engineers at DealerOn, I often get push-back from recruiters and questions from candidates about why we ask our candidates to complete a coding test prior to coming in for an interview. To put it simply, we believe that the benefits outweigh the drawbacks. But what are they? Let me explain…

Over the course of my career, I have seen several different hiring processes from companies. All of them start with a resume. Many ask for a cover letter. You or the recruiter representing you submits these to the hiring manager or HR recruiters at the hiring company and you wait. If you are one of the lucky few, you will be scheduled for a face-to-face interview with any number of technical and non-technical people that you would (presumably) work with should you get the job. This was the way it was done early in my career. Later, I noticed that companies were adding technical screening calls before the face-to-face, to eliminate any candidates who didn’t have the technical skills required.

During several interviews throughout my career I have been asked to code things on whiteboards or even with a pencil and paper. This always seemed odd to me, as we don’t write software that way. We have compilers and feature-rich IDEs with Intelli-sense to keep us from making silly mistakes and Google and Stack Overflow to look up things that we might know about but have forgotten exactly how to do. These methods also tend to make candidates very nervous, as it puts them on the spot in a way that will never happen in the actual work environment.

The kind of code test that DealerOn asks for is not done during the face-to-face interview. We provide the problem days in advance and give you ample time to solve the problem in any way you wish. The only requirements we place are that you use C# or Java, that it compiles, that it doesn’t use 3rd-party libraries, and that you write it yourself. You can use whatever online or in-person resources you desire, and the result can be a web application, a windows application, or a console application. However, keep in mind that as part of our interview process we ask candidates about their design choices in their code test, so you need to understand the choices you made. Candidates have complete freedom to use whatever design patterns they feel best suit the problem and can write as simple or complex code as they wish. Our preference is for C#, since that is the language that we primarily use here at DealerOn. However, Java is syntactically and structurally very similar, so a test written in Java can showcase your design abilities as well.

Why don’t all companies use a code test?

Not all companies use a code test. Most don’t, in fact. The reasons are pretty obvious.

It reduces candidate count

Some candidates, especially those that are highly-sought after, don’t feel they have time to do a code test. After all, they have some companies that don’t require a code test calling them back to do a face-to-face interview. I’m sure that some of those were great candidates who could have excelled here, technically, but the code test is part of our culture, so if you aren’t willing to take the time to do the test, you likely wouldn’t have fit in anyway.

It lengthens the hiring process

When the market is hot, as it is now, time is often not on our side. Candidates can get swooped up by other companies. Having a longer, more complex hiring process can cause us to lose out on candidates.

Our decision to use a code test as part of our hiring process has been the result of weighing the benefits against the drawbacks. At this point, even with the tight labor market, we still feel that benefit of getting the right candidates is worth potentially losing out on others from time to time.

Why does DealerOn use a code test?

We like the code test because we feel that the benefits outweigh the drawbacks. The main benefits we see are:

It allows us to consider candidates independent of their resume.

As part of our process, the engineers reviewing code tests do not have any fore-knowledge about the candidate. They don’t look at their resume or sneak a peek at the code before the evaluation begins. DealerOn doesn’t limit junior developers to menial tasks, and we don’t pigeonhole you based on the number of years that you’ve worked in the industry. If you can write high-quality software, we can provide a place for you to grow.

Candidates that do it really want to work here.

Think about this: If every company asked you to complete a code test, how many would you apply to? By asking for a code test, we know that those who submit one back to us really are motivated to work for us. Furthermore, I have heard from many candidates that they really enjoyed doing the code test. These are the kind of people we want here: People that enjoy writing software and are eager to show us their abilities.

It shows that your knowledge isn’t strictly theoretical.

Yes, the code test isn’t super complex. As a result, we cannot tell for sure, based upon your submission, that you can design highly-scalable web sites and services that can serve up our customers’ data in a reasonable time. But it does show us how much you care about the code you write, and that you might be able to succeed here. Coding style, maintainability, testability, code cleanliness, design pattern usage/knowledge all can be fully captured with our code test.

It gives candidates another way to set themselves apart.

How do we distinguish ourselves to prospective employers? The experience on our resume is part of it, as is the formatting and design of that resume, although often recruiters re-write them without our permission and format them with their style and company letterhead. Presenting yourself well at the face-to-face interview is essential of course, but what if you never get invited to one? Our code test allows candidates to set themselves apart from the pack by showcasing their coding skills. We’ve seen many creative and elegant solutions to our test’s fairly basic problems. We’ve also seen code tests riddled with mistakes that didn’t follow the instructions and solve the problem as stated. The more information we have in the hiring process, the more likely we are to make the correct decision about who to hire, and that’s a good thing.

Advice to Potential Candidates

Whether you intend to apply at DealerOn, or another company that has a code test as part of their hiring process, I have a few pieces of advice:

Take it seriously

This seems obvious, but I can’t tell you how many times I’ve seen submissions that looked like the candidate just “threw it together” in an hour. This is part of the hiring process. The more effort you put in here, the more likely you are to get the job. You wouldn’t show up to a face-to-face interview in your pajamas, would you? Submitting a code test without putting forth your best effort gives the same impression. Spelling errors, inconsistent variable and method naming, or non-object-oriented code show that you didn’t put much thought or care into your work and are red flags.

Follow the instructions

You’d be surprised how often this comes up, but it’s key. If you can’t follow the simple instructions we provide, how do we know that you’ll follow instructions if we hire you? Code that ignores constraints or gives invalid output are huge red flags.

Show off a little

Your resume tells us that you are a C# expert, or that you know all about the Factory design pattern. Show us! Use dependency injection, make unit tests - stand out! We really enjoy looking at well-crafted solutions. It shows us that you really enjoy what you do and would likely be a good fit here.

Conclusion

A code test can be seen as a burdensome extra step in the hiring process, but for a growing number of companies, including DealerOn, it is a way to get a better sense of who you are, how you think, and how skillful of a developer you are. A well-written and thoughtfully designed code test submission can move your resume to the top of the stack, regardless of your experience. Taking the time to do a good job tells us that you are likely a great fit for us.