I have read that at a lot of companies you have to write code at an interview. On the one hand I see that it makes sense to ask for a work sample. On the other hand: What kind of code do you expect to be written in 5 minutes? And what if they tell me "Write an algorithm that does this and that" but I cannot think of a smart solution or even write code that doesn't semantically work?

I am particularly interested in that question because I do not have that much commercial programming experience, 2 years part-time, one year full-time. (But I am interested in programming languages since nearly 15 years though usually I was more concentrated in playing with the language rather than writing large applications...) And actually I consider my debugging and problem solving skills much better than my coding skills. I sometimes see myself not writing the most beautiful code when looking back, but on the other hand I often come up with solutions for hard problems. And I think I am very good at optimizing, fixing, restructuring existing code, but I have problems with writing new applications from scratch. The software design sucks... ;-)

Therefore I don't feel comfortable when thinking about this code writing situation at an interview...

So what do the interviewers expect? What kind of information about my code writing are they interested in?

7 Answers 7


When I ask candidates to write code during an interview, I'm interested in two things:

  1. How they write code. (How it's structured. Is it readable? Does it make sense?)
  2. How they solve the problem given.

For the first one, I'm interested in how maintainable their code is. If I'm working next to them, is it going to tick me off that they don't create meaningful variable names?

For the second one, I'm interested in how simple or how complex they make the solution. Simpler is always better in my mind. The simplest code is the code you don't have to write. Sometimes I give them a problem that's easily solved by an off the shelf solution; other times I give them a problem that has multiple ways of solving it, but only one simple way. The more complex they make the solution, or the less questions they ask, the less likely I am to hire them.

For writing code, candidates have a sliding amount of time to finish the issues.

For something like Fizzbuzz, they get five minutes. To implement a solution to a specification I give out, it depends on how much time it takes. I normally take the time it takes me to do it and multiply it by 1.5 to determine how long to give them.

  • 2
    What kind of coding questions do you ask?
    – user1249
    Jan 16, 2011 at 20:40

For the coding test we use at my employer we allow up to 1 hour for the person to complete the task. We are looking for an understanding of how to break the problem down into is basic elements. Can you digest requirements. Can you demonstrate the ability to design a solution. Can you show your work in your selected language. We do not limit the person to a particular language. The solution is reviewed privately and then with the candidate. The review will give the candidate the opportunity the time to explain the proposed solution.

A working solution is nice but not required to get an offer.

The goal here is to gain insight into how the candidate solves a problem. The post test review is to account for test taking jitters that some have. Specifically if the candidate made a mistake in their solution can they explain why its wrong?


Don't try to be too smart. Keep it simple and understandable.

The reviewer of the code needs to be able to look at your answer and see how you are trying to solve the problem.


It could be a simple recursion, mergesort etc. There are a lot of 20-lines-max examples out there. If you start remember to:

  • Ask if interviewer cares about syntax - one cares other doesn't. Maybe they are just fine with pseudocode.
  • Say a bit what are you doing and why - step by step

Everbody got his own style.

Good luck :)


Usually they are going to ask about a problem that you can optimize so don't jump into the perfect version immediately. Do a brute force solution first (they are usually simpler to code anyway).

Once you have managed to get that correct they will ask you about the complexity of your solution. And how it can be optimized (to improve complexity (simple peephole optimizations are not going to impress them much)).

Simple Examples:

  • Reversing Lists/strings
  • Sorting algorithms
  • Anything to do with recursion
  • Depth first tree algorithms
  • If they are nasty breadth first traversal of a tree.

Generally the questions will be couched in terms of the companies domain space.


I had a job interview a couple years ago, where I was expected to write some code.

That would have been well and good, except:

  • The interviewers were over an hour late.
  • They hadn't prepared any accounts on a host for testing.
  • They hadn't figured out what machine to use.
  • They hadn't figured out what the code was to be.
  • The computer they eventually settled on using for me was so disgustingly dirty that I didn't want to touch the keyboard. It. Was. FILTHY.

Needless to say, it was a joke, and I didn't get the job because they didn't have me on a level playing field. Subsequent interviewees had the scenario already worked out on me. And, I knew I didn't want to work there if they were that messed up.

  • 3
    "I knew I didn't want to work there if they were that messed up" - yup, interviewing is a two way process
    – Mawg
    Apr 21, 2015 at 9:28

Typical speed is 60 lines of tested code / h (that's code that is actually doing something, not empty lines and brackets)...

The interview will obviously take more than 5 minutes if they want you to write code from scratch. Probably they'll just ask for samples before it, and you'll be talking about more general concepts (eg. algorithms).

  • 2
    Where do you have this metric from?
    – user1249
    Jan 16, 2011 at 20:57
  • 1
    From 'software engineering' lectures @ my University and practise shows that the number is more or less correct. Do you have some other one, if yes is it more or less and what is the source?
    – Slawek
    Jan 16, 2011 at 21:22
  • 1
    Writing code in your "normal" environment is totally different from writing it in an interview. I would never expect someone to be as productive in a stressful interview than they ought to be working at their desk on a project they're familiar with... Jan 16, 2011 at 22:09
  • 1
    Maybe 60 in a day! Certainly not with answering the phone, going to meetings, coworkers talking to you, getting coffee, answering email, etc... Jan 16, 2011 at 22:56
  • @Slawek - Please provide some documentation for your metric. Can you find anything online to support that?
    – Walter
    Jan 17, 2011 at 2:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.