How to Do a Coding Exercise at an Interview

Some companies include a coding exercise as part of their interview process. The candidate is given a couple of hours to solve a coding problem on-site, in the language of their choice, followed by a discussion with the technical teams. I've been on both sides of the process.

In this post I'm specifically addressing the short, on-site, solo coding scenario. Most suggestions apply equally well to an untimed, at-home code exercise. I can't speak to on-site pairing, as I don't have enough experience with that style.

The company's goal

Coding demos let interviewers see a candidate's skills in practice. How well does the candidate know a language? How do they approach solving a problem? It's hard to get a good sense of hands-on skills and style from questions alone.

This is good news for you! As programmers we've spent weeks and years writing code at a keyboard. We don't train to narrate solutions on a whiteboard or answer riddles.

Furthermore, code is a fairer indicator of ability and fit. You have latitude to choose an approach, and room to show off what you're good at.

It's unnerving, but can be a great opportunity.

Your goals

There's a story about a duke riding through a forest. Time after time, he sees an arrow sticking out of a tree, each in the center of a bullseye. When he catches up to the archer, the duke asks how she managed such an incredible feat. "Easy," she says; "first I fire the arrow. Then I paint the target around it."

Play to your strengths. Show what you know. Paint the target around the arrow.

It's all about the demo

We talk about a coding exercise as if it were about solving an example problem. The truth is, it's a demo.

Stop right now and watch Chiu-Ki Chan's How to Win Hackathons. Chan's five minute talk begins at the 1:30 mark. Everything she says applies here.

AN INTERVIEW CODE EXERCISE IS A DEMO.

The priorities are different from how you solve a problem on your own. Think about the demo first and work backwards. Fit your solution to the time allowed. Use a little showmanship. Your focus is on making an impression at the end.

Strategy: suss out the real question

When you're given the problem statement, read it all the way through. It's basic, but worth repeating. We rush when we're under stress, and may latch on to the wrong idea. Read the exercise all the way through.

Are there sample inputs? Test data? Do these point to interesting complications?

Are the requirements fuzzy? Clarify them with the interviewer.

What makes this a good test question for candidates. Does it relate to the company's product or field? There's often a piece that check for basic understanding, like pointers, array manipulation, or collections.

How might you incorporate your strengths in the solution? Perhaps you're a Bootstrap wizard, or can add a little typeahead search.

Make it work, then make it complete

Your first pass should be a simple, incomplete version that runs end-to-end. Iterate from there to fill in features.

A feature-incomplete version that runs is a hundred times more impressive than a partly implemented solution that's going to do X, Y, and Z once you hook it up.

Your gut reaction may be, "It's not finished! It's not ready! " We like completion. That doesn't serve you here. Jot down a to-do list and come back to it later. You need to make it work end-to-end.

Use your judgement about test coverage. If it helps you be productive, or if it's a strongly TDD shop, then go for it. Don't submit a great test suite and no functionality.

Listen

Someone will check in with you from time to time. Ask questions if you've discovered a gap in requirements or a plot twist.

Listen to feedback if any is offered. You can implement it or not, but have a rationale for your decision.

Plan for discussion

Make notes in the code or on paper as you work. You'll talk about your approach during the demo, and it's easier to capture thoughts as you go.

Some topics for discussion:
+ decisions, questions, and assumptions
+ edge cases
+ error conditions that you aren't checking for
+ efficiency tradeoffs

You'll leave a copy of your code with the interviewer. Comments can speak for you after you've left.

Discussion points

Time's up! Now for the big reveal and discussion. Swallow any impulse to apologize for not getting farther.

Begin by summarizing the problem.

Show that your solution works end-to-end. ( Congratulations - you have already surpassed other candidates.)

Narrate how you solved the problem. This can begin with noting some of the elements that make it a tricky problem, or by walking through the code. Look at your discussion notes so you can highlight your thought process. Software discussions usually center around tradeoffs, design choices, tricky cases, and scalability. The discussion will unfold as you go.

It's ok to direct the conversation if you're sensitive about not dominating it. If you're getting the silent treatment, assume that your interviewer is ill-at-ease. Most developers don't get formal training in how to interview effectively. They may have learned they were interviewing you minutes before you arrived. You can't know what's going on in their head. Assume the best, be gracious, and help them make it a productive conversation. "I thought this requirement was interesting..." "What else can I tell you?"

Practical Preparations

Some preparation will make your interview easier.

Most companies allow or expect you to use your own laptop. Do it! You've got things set up the way you like them.

NO UPGRADES ALLOWED! Even for trusted tools and IDEs. Even for products you're sure couldn't possibly break anything. Any software updates can wait until after the interview.

Bookmark or download the documentation for your tech stack. Sure, you can search, but save yourself that little extra step. Mac users, take a look at Dash.

Download a fresh copy of Bootstrap, JQuery, or other libraries you expect to use.

Practice writing an application from scratch and deploying it to your local environment. We normally do these steps once at the beginning of a project and never again. You don't want to Google for it while someone is watching. Make sure your local web server and test framework work.

Brush up on any topics you feel particularly rusty on, but limit review to an hour or two. This is more for your confidence than to actually review. If the topic comes up, you're ready. Now you can stop worrying about it.

Finally, remember that someone will be looking at your desktop and handling your keyboard. Wipe off the keys, shake out the crumbs, tidy up the icons, and get ready for company.

Recap

• Focus on the demo.
• Breadth before depth: make it work end-to-end first, then iterate on features.
• Play to your strengths.

You've spent weeks and years coding. You've got this.

Good luck!