Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

put on hold as too broad by GlenH7, MichaelT, durron597, gnat, Ixrec Apr 21 at 22:10

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. If this question can be reworded to fit the rules in the help center, please edit the question.

7 Answers 7

up vote 2 down vote accepted

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.

share|improve this answer
What kind of coding questions do you ask? –  user1249 Jan 16 '11 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?

share|improve this answer

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.

share|improve this answer

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 :)

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
"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 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).

share|improve this answer
Where do you have this metric from? –  user1249 Jan 16 '11 at 20:57
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 '11 at 21:22
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... –  Steven Schlansker Jan 16 '11 at 22:09
Maybe 60 in a day! Certainly not with answering the phone, going to meetings, coworkers talking to you, getting coffee, answering email, etc... –  kirk.burleson Jan 16 '11 at 22:56
@Slawek - Please provide some documentation for your metric. Can you find anything online to support that? –  Walter Jan 17 '11 at 2:38

protected by GlenH7 Apr 21 at 16:10

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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