The Dreaded Coding Assessment

It’s time to make a move. You’ve grown in your current position as much as you can reasonably expect, so you start looking around for your next opportunity. And there it is! The perfect next spot to land. You reach out, do the dance, and land an interview.

There you are, minding your own business, preparing for the interview when you get an email from HR. WIth trepidation you open it and read the dreaded words: “We want you to do a little coding exercise.” In the body of the email is a lone, ominous link.

Immediately your breathing gets more shallow. Your heart rate increases. Your palms get sweaty. Your eyes dilate. Your amygdala takes over, inciting you to fight or flight. Since you can do neither, you simply curl up in the fetal position under your desk and suck your thumb.

Perhaps this sounds a bit melodramatic, but I suspect that for some people, I’m actually understating the case. There are few things that generate as much anxiety for a programmer, especially a less experienced programmer, as taking the DREADED CODING ASSESSMENT.?

I mean, isn’t the interview process itself stressful enough? Humiliating, even? But no, we have to dial up the pressure and make candidates actually write code.?

Why should this be such a traumatic experience? For a number of reasons, actually.

1. We’re afraid the exercise will be too hard. Most people will get problems like “write a program to add two numbers together”, but mine will be “write a C++ compiler in Perl in at most 1 line of code.” The interviewer will take great pleasure in telling me how everyone else completed this assignment with no problem. I will then be exposed for the imposter that I truly am.
2. We’re afraid we won’t finish. What if it really is simple and I still can’t complete it? I will then be exposed for the imposter that I truly am.
3. We’re afraid our code will not meet some mythical, unknown standard of ‘good code’ . So even if I do complete the exercise, the code will be suspect. I will then be exposed for the imposter that I truly am.
4. Timed exercises induce panic, nausea, brain lock, syncopy, amnesia, irrational thinking, and a sudden desire to join the Peace Corps. If I can’t handle a simple timed programming assignment, how in the world will I handle real-world deadlines? I will then be exposed for the imposter that I truly am.

I’m sure there are more reasons, but I believe they all boil down to one thing: fear. Fear of being found out. Fear of rejection. Fear of not getting the job.

Fear of being exposed for the imposter that I truly am.

I’m tempted to end this post right here by saying–get over it. We all feel like imposters at times. Some of us are better imposters than others, but we are all imposters nonetheless.

But that wouldn’t be helpful. You’re still staring at that blasted link trying to decide whether to click on it or pursue a less stressful line of work, like bomb disposal or joining a SWAT team.

Don’t give up. And don’t click on the link just yet. Let’s talk.

In my position at Ingage Partners, I’ve conducted dozens of interviews and have reviewed even more coding assessments. In my experience, I’ve learned two very important things about these exercises.?

1. They are very stressful.?
2. They don’t need to be.

The key is preparation. Abraham Lincoln famously said, “If I'm given 8 hours to chop down a tree, I’ll spend the first 7 hours sharpening my ax.”

I think what ole’ Abe was getting at is that preparing for your work will increase your odds of success and make the work itself easier. It will also improve your chances of meeting the deadline.

So how does one prepare? There are several things you can do to significantly reduce the stress in this situation.

Realize why you’re being required to write some code

We don’t subject you to this indignity to see how you handle pressure. We know that at no time during your career will your boss ever hand you a piece of paper and say, “Here are two meaningless programming exercises. You have one hour. Go!” We also know that how you perform during such a contrived situation says nothing of how you will handle real-world deadline pressures.

What we’re really after is how you think. What is your thought process? How did you approach the problem? What debugging techniques did you employ? Did you write tests or come up with reasonable test scenarios? Whether you actually complete the exercise or not is incidental.

Warm up with a couple of simple coding problems

Athletes warm up. Musicians warm up. Developers do not.

I find it mystifying that, with a potential new job on the line, we will not prepare for a coding assessment by writing some code.

We will prepare for the interview. When the interviewer says ‘Tell me a little bit about yourself’, we have an answer prepared. When asked ‘What is the achievement you're most proud of’, we are so ready.

When it comes to the coding assessment, we normally walk in cold. Why in the name of William Shatner would we do that?

Search online for ‘coding exercises’ or something similar and you’ll discover literally a boatload of sites with problems that you can work on. I have no idea how many exercises will fit on a boat, but you get the idea. It’s a lot.

Pick a couple of simple ones and work them from start to finish. Even if they are exercises you’ve already done, you will be more prepared to complete the assessment. Your mind will be in problem solving mode, you will be reminded of language nuance and syntax, and you’ll go into the assessment with some momentum.

Get familiar with the assessment tool

Before you click the start button, see if there is any information on the tool’s website regarding how to effectively use it. Does it provide an IDE? Are there multiple tabs with information on them, such as the problem description, test cases, etc? Does it provide a method or function for you to implement or are you starting from scratch with a class and a main method?

If this information isn’t available prior to starting the clock, then take a couple of minutes after pressing the button to look around and figure out the tool.

Don’t overlook this step. I’ve seen a lot of time wasted by candidates who, instead of just implementing the supplied method, deleted all the code and started from scratch.

If you have a choice, choose a language you are familiar with

This seems obvious, but many times candidates are tempted to use a language that they think will impress their future employer rather than using the language they know and love.

Fight that urge. The employer isn’t assessing your knowledge of Java. They already know from your resume whether you have more Java or Javascript experience.

“What if I’m required to use another language?”, you may ask. And well you might.

In that case you’re stuck. Stack Overflow is your friend.

But if you have a choice, for the sake of your nerves and to avoid PTSD, go with the language you know.

Take the time to understand the problem

Take a few minutes to think the problem through and devise a solution. The tendency is to either start coding immediately or start scouring the web for ideas. It’s fine to look for ideas online, but only if you need to, and if you give the problem some thought, you most likely will not need to. (And if you do look online, don’t copy the code. It’s obvious when you do. Don’t ask me how I know that.)

One thing you can do to help understand what you need to do is to use a high-resolution display device (paper) and sketch out the algorithm by hand. It doesn’t have to be pretty or even complete. Just enough so you know how to proceed and what the structure of the solution will look like.

Read your error messages

Odds are that you’ll have to deal with compiler errors, run-time errors, and mystifying output. Many times the error will tell you exactly what you did wrong. But reading the error message takes time and the clock is ticking, so we quickly scan the code, think we see what the problem is, make a change and run the program again–only to see the same error.

The danger is that we will get into this vicious loop where we’re just making changes and hoping they will work. Of course, they don’t, but that doesn’t deter us. We make another quick change and rerun the program. And on it goes.

As the t-shirt says, Keep Calm and Read the Error Message.

In between interviews, do lots of exercises

I mentioned earlier that musicians and athletes would never begin a performance or a contest without warming up. Neither would they ply their trade without practicing between performances.

As is the case with warming up, developers rarely practice.?

Oh we watch videos, take online courses, even walk through canned tutorials. These things are good and necessary, but I don’t consider that practice. That’s learning.

For a coder, there’s only one way to practice writing code: writing code.

We even have a word for it: kata. This is a term we’ve borrowed from the martial arts where it means to practice specific forms repeatedly so that the correct form is burned into muscle memory. Consequently, in a competition those forms are called upon without consciously thinking “now how do I do that again?”

In our case we’re not just solving the same problem over and over again, but we’re constantly working small problems so that the process is indelibly etched into our memory. As mentioned above, if you search for? ‘coding exercises’, ‘coding challenge’, or ‘code kata’, you’ll discover dozens of websites with challenges for you. What a time to be alive!

Then when we are faced with a coding assessment, we do not waste cognitive energy on how to begin or how to use the tool. This in turn will reduce your stress and improve your performance. You’ll begin to see the coding assessment as just another exercise, one among the hundreds you’ve already completed.

The nice thing is that you don't need to? spend hours and hours each week. You can complete one or two exercises a week and that will be sufficient.

And if you really want to train yourself, set a timer. Give yourself an hour to do two exercises. No big deal if you bust your time–the idea is to get practice under time pressure.

The Dreaded Coding Assessment need not be dreaded. The Dread Pirate Roberts, now he should be feared. But not the Dreaded Coding Assessment.?

So take a deep breath (or several) and try some of these suggestions. You’ll find that taking a coding assessment becomes almost routine.

You may even have some fun!