Scott Hanselman

I let them bring in code from home. It's always felt like it was the easiest way to kick of the conversation

Live coding... Never had that before. I'm sure that would be very interesting to see.

There's not really a great solution other than practice and the realization that whatever you do to prepare, it's likely still going to happen. I think employers generally understand this as well as often times you can re-apply after 3-6 months.

After looking for a job semi-recently, I bombed out of a bunch of interviews that I shouldn't have, so I wrote up some of my reflections about it on my blog.

Very good point about pressure.

Most probably interviewer is trying to build a team so they might evaluate social/collaboration skills and ability to resolve conflicts (not only in git/tfs).
Knowing how person behaves in certain situation is helpful when you plan who will be doing a release deployment and who not (for example).

Everything might go wrong (even when carefully planned) and better the person will be able to handle in some way these surprises.

Thanks for the good reading

Great article.

As someone who has gone through this and put people through this, practice is the key. If you already know you're a good developer you need to learn the kind of buzz you can get from talking someone else through your code. Spend a few brain cycles, come up with a solution and have the confidence in yourself to think "I really wanna show someone this code".

It works the opposite way for me. I would prefer the use of a white board as it helps me if i can write stuff down and then explain my workings as i go along, keeps the conversation flowing as well. It might not always be code, maybe a data flow diagram to show how a certain part of a system works / flows. I interviewed twice last week and was praying for a white board, embrace the white board!

There's not only one source of pressure. Live coding might not be the kind of pressure a developer usualy have to deal with. It's often more about time contrains. I would ask the developer solve a problem in a very limited time.
And remember, an interview is an evaluation for both sides. The quality of the interviewer/questions gives your some information about the company you might spend your time and energy for ;-)

I do these kind of interview for all programmers applying for a job.

The test is trivial and you can basically almost copy the answer from SO.
I'm always present and looking over their shoulder from a distance as to not creep them.
What I'm actually looking at is:
- their bodylanguage: eagerly coding or with one head holding their chin up and the other typing
- how do they use visual studio
- do they use google/bing/... (that's is a indeed a skill, nobody knows everything)
The actual code is less important (even though it must be working), but the way you got the solution is more important for me.

No test can give you a completely correct vision of someone's skills.
It's just how do they go at it.

Simply terrible advice.


(couldn't resist. LOL)

Stacy - ;)

Good suggestions. In my company, we have dev candidates (anyone from junior fresh-out-of-college on up to seasoned architect level) do a live coding exercise with a few of their would-be peers. We do not judge on exact correctness of syntax, memorization of library functions, or anything else idiomatic. We give the candidate a problem and a blank white board and ask them to start walking through how they would solve it - high level objects at first and then start diving into how do those objects interact with each other: what methods do you need, properties, etc. Once they've got something sketched out we sit them in front of Visual Studio and ask them to start the implementations of a few of the methods.

We are looking at their problem solving methodology -- not at all at their "do you know C#/javascript/insert language here". Do they understand the logic of how a program comes together and how to build a solution to a problem? I've had several candidates fluent in Java freeze initially when we started because we're a C# shop. In those cases I reassure them I don't care about syntax at this stage and I'll gladly help them through syntactic and compiler issues.

Last week I had to do a live coding interview. The experience was a positive one and I think it had something to do with the way the company facilitated the exercise. It was a remote interview and was done on Skype. The exercise was to implement a data structure in Java and we were to pair and test drive the implementation. What worked effectively in reducing my anxiety (I've done other pairing interviews to compare this with) was that the interviewer shared their screen and were the driver. I was the navigator dictating how to go about implementing the necessary behaviours.

For me, this method worked well because it allowed me to really demonstrate my problem solving ability, analytical skills, and genuine nature when tackling a problem. I didn't have to worry about knowing the correct KB shortcuts or flubbing the spelling of basic core Java classes. The interviewer also had some predetermined design decisions which helped focus the exercise.

I'm moving forward to the next interview soon.

I had this experience earlier this year. At the interview I was given a coding test to do in front of the director and technical lead. I was given a Macbook which was hooked up to a 40 inch TV so they could see what I was doing. I couldn't think straight because I couldn't believe I was being put on the spot like that. I also was given the task and told to do it using TDD which I have never done before. My CV reflected that and in my telephone interview with the director I made that clear.

I think it's also vital that the potential employer is upfront about the interview process so you are mentally prepared for it. Also they should make you feel at ease when the time comes rather than try to embarrass you by hooking up the live coding to a giant TV for all to see.

When discussing it with other developer friends they couldn't believe what they had asked me to do and said I had a lucky escape. I think they were right.

Every dev I know dreads that type of technical interview. And I don't think live coding is the best indicator of the quality of a candidate.

I prefer to give the candidate a standard homework problem to complete and submit prior to the interview. The problem is typically mathematical in nature, and so has a "correct" output. Any language allowed. It's not a big problem - something that can be easily accomplished in an evening or less.

I look over the solution before the interview, to evaluate style and thoroughness. During the interview I devote an hour to the homework, and we discuss approach, alternatives, variations of the problem, testing strategy, etc. It's this discussion that reveals their capabilities and attitude toward design, problem solving, organization, quality, etc. If I've found bugs (as I nearly always do) I point out the incorrect result and ask them to debug on my laptop, to see how they fare under pressure.

I find this approach reveals a facet often missed in conventional tech interviews.

Practicing pair programming might be a good exercise even when done remotely.

One thing that seems to work for me in many situations where I have a tendancy to "freeze" is to prepare myself by imagining the situation and recall that bad feeling. But then visualize how I take a few deep breaths and get on with the task ahead like I want to do it. Be pretty specific about how to start. Maybe take a few deep breaths, start by outlining the overall structure etc etc. Then whe you are about to start the real coding recall the plan and the state of mind you want and start repeating the steps.

This does a few things. It prepares me for the bad feeling so I'm not caught by surprise and it let me think through my game plan in advance. The brain is really bad at separating reality and fiction so if you can handle it once, even in a fake setting, that will help you in a real situation.

I am one of those hiring managers that make people code live in front of me.

Maybe I can help by giving my perspective of why I want someone to code in front of me.

I like to watch how people interact with the tools that they use. I like to see how a person thinks when working through the challenge that I give them. I incurage prospective employees to ask me questions and to even use google during the tech interview. But I think the number one thing that i like to see in a tech interview is if you say you have done c# for the last 6 Years if you can figure out how to make a property. You would be horrifically surprise how many people cannot even do that.

I don't look for perfection or if you can figure out how to calculate pi without looking anything up I just want to see what your coding style is like, what your thought process is, and if you can do simple things that you say you have done for years on your resume. I don't expect perfection while I am breathing down your neck. I also find it helps if you have a quick chat with the person interviewing to help feel more comfortable during the interview.

That is my perspective from the hiring side, hope it helps people.

Great comment, Ryan! Thanks for sharing!

This topic is kind of a soft spot for me due to a recent experience.

I interviewed for a position a few months ago where the process was pretty much standard for a Software Engineer position. Two tech screens over the phone, came in and spent a couple hours with the standard C#/.Net/OOP quiz questions, some algorithms out on the board, etc. Then another couple hours walking through some applications I've built and explaining the code. The last point was the live coding, something I've done plenty times before.

I was given a problem and told I couldn't use my laptop (hooked to the projector to show my source) and we went to his office instead. He had remapped shortcuts, a split ergo keyboard and a trackball mouse. He gave me vague instructions on the problem and I solved it with code, though the typing was a bit clumsy.

I wasn't offered the position because of this one test, he told the Director "I was a drag and drop programmer" and "I probably haven't done a lot of hand coding". Something anyone I've worked with in the last 15 years would have laughed at. The feedback I received was 4 yes votes and one no, but it had to be unanimous.

This type of stuff happens every day and it's a great way to weed out good candidates. I'm not saying I'm the greatest developer in the world but I was definitely qualified for that position and got eliminated by an insecure person playing games. I quickly found another position at another company and am thankful I don't have to work with someone like this.

If you're interviewing people, resist the temptation to "torture" or make your candidates nervous. If you start seeing this behavior taking place, remember it's saying a lot about the people you're working with.

I'd very much prefer to do a "live coding" exercise on an actual computer. Doing it on a white-erase board is entirely unnatural and unnerving.

I prefer to storm out of those interviews and flip some tables on the way out ;)

In all seriousness, I like the process in an above comment that it was a pair programming exercise. That allows the interviewer to make the test progressively more or less difficult.

As far as dealing with the anxiety, get up in front of people at local events/user groups and practice. I have done enough presentations (and epic failures) at this point that it is a fun time even when you fail. That makes a good conversation with your (audience) interviewer and helps you get to know each other.

Knowing how someone fails (epically) is equally important to me.

I recently had my first ever live coding interview. I fortunately did well enough to get the job, and after the fact I was told that some of their candidates have refused to write code in a live setting. I think it's very reasonable to expect a programmer to demonstrate how they code. As it has been pointed out already, even if the candidate has difficulty performing under this type of pressure, how they react is probably more important than the code they write. To simply flat-out refuse to write code to me would indicate that the candidate is not able to do the job.

I've written some additional tips about from my job search and interviews on my blog here for anyone that is interested.

I've been the interviewer in a number of situations and I also use live, white board coding. The interview is about learning how well you will work with the team. Most developers I've worked with get away from the keyboard and spend time at a whiteboard sketching out designs, algorithms, and more. A simple coding problem gives me a chance to evaluate the following:

• How you think through a problem.


• How good you are at seeing alternatives.


• How you dig for clarity on the problem at hand (I never give a complete spec. I want to see the candidate evaluate the problem and get clarity. Why? Your clients/co-workers won't give you everything you need up front. They'll do this because they are also pressed for time and won't give detailed designs.)


• How good are you at evaluating your own code? I'm looking for someone who can read a method, evaluate it in their head, and figure out the outputs given various inputs. If you can't do that, you can't code review and help the team.


• Are you a person I want to work with?

I have no interest in asking trivia problems in an interview. I just want to figure out if you'll fit into the team and be a productive member. Given that I usually only have an hour with you, I have to prioritize interacting with you over reviewing your old projects. So, I'll rarely spend more than 7 minutes on your past in a given 60 minutes.

When I was interviewing with a major Seattle tech company about a month ago, I made it through 4 interviews, and I ended up calling off moving forward due to getting a scholarship for my graduate program.

During the interviews, it was clear that there was a great amount of anxiety on my part. It was horrifying to be honest, despite my coding skills in various languages and paradigms.

When I asked the recruiter after the fact what her thoughts were about my tendencies, she told me that my collective nature and talking out step by step my thoughts as I went.

So despite the fact that there were blaring mistakes in my code, the attitude more than made up was the response. Must say, definitely agree with the idea of practice, practice, practice. Trying to get a group up at Portland State to meet up and do mock interviews this term, cause it's SOOO valuable to know where you are lacking.

If you can't tell someone else how to do it, or you forget it under pressure, there's probably a good likelihood that you can improve in that area (just my opinion.)

I get more nervous as the interviewer, than most interviewees.

Final answer: live coding 'exercises' as an interview strategy are absurd, pointless, useless measures of a candidates's abilities as a software developer.

I'd rather see something they wrote themselves, and ask them to talk through it. Hey, even if they didn't write it, I'm more interested in a candidate's ability to understand, explain, and defend design choices, than I am in playing quiz show.

I agree with you James. As an interviewer and interviewee I hate live coding and white board coding examples. I would much rather you demonstrate code that you wore that solved a huge problem. Something you feel was GREAT and noteworthy. If I have a person who wrote some pretty impressive code and it solved a problem I can see the level of what they feel was "impressive" and that can tell you how complex they can code.

I had a situation where I was asked by a MAJOR firm to write a reversed link list. I told them no. I would tell them how I would use one in a coding and design scenario and that I would be wasting time to write mine when there are great libraries already out there that write reverse link lists. I got the job because I thought out of the box. :)

Another one to avoid like the plague is companies that want to have you come in and do a weeks worth of code work before they will cement the deal. That is a joke and you should avoid that like the plague.

I agree with you James. As an interviewer and interviewee I hate live coding and white board coding examples. I would much rather you demonstrate code that you wore that solved a huge problem. Something you feel was GREAT and noteworthy. If I have a person who wrote some pretty impressive code and it solved a problem I can see the level of what they feel was "impressive" and that can tell you how complex they can code.

I had a situation where I was asked by a MAJOR firm to write a reversed link list. I told them no. I would tell them how I would use one in a coding and design scenario and that I would be wasting time to write mine when there are great libraries already out there that write reverse link lists. I got the job because I thought out of the box. :)

Another one to avoid like the plague is companies that want to have you come in and do a weeks worth of code work before they will cement the deal. That is a joke and you should avoid that like the plague.

I totally bombed my last coding interview. Did 4 remote interviews and felt great about them, and then on the last interview it took me almost 45 minutes to go through a somewhat simple recursion problem. Had full confidence on my first try, and talked my way through what I was doing, but after 10-15 minutes in I was totally lost. Back tracked, tried again, and still fell flat. The interviewer was very patient with me, gave me a few pointers, and I was able to give a passable solution on the 3rd try.

Lessons I learned are: 1) I should have practiced solving a recursion problem prior to the interview, 2) Always describe what you are doing so they understand your thinking process, and 3) A patient interviewer that gives hints when you are stuck can be a life saver!

I felt terrible afterwards, but I got the job so I guess it all worked out!

Most technical interviews are unrealistic and filter out lots of talented, passionate, capable people. I don't have many suggestions other than know your tools very well and don't be afraid to ask questions. Treat your interviewers as if they were already your coworkers—if they don't want to collaborate as this stage—you're just the "interviewee"—I'd be wary going forward. Think about it: Do you want to spend most of your waking hours with that person/group?

At my work, we think 1) whiteboarding algorithms are a waste of time for everyone and 2) performance anxiety can cause the best programmers to shut down. It's already intimidating enough to at a foreign office with people you don't know scoping out a new job and worrying about paying the rent. By the time we've asked someone to come in for an in-person interview, we've already done some basic technical assessment over one or two phone interviews. When she arrives, we do our best to convey to the interviewee that she's our peer and to think of us as collaborators. We might ask to whiteboard a domain model problem ("Let's say I want to build a competitor to Amazon...what might that system look like? Let's work on it together."). But we work on it together, ask questions, point out problems—just like you'd do if you were sketching something out with a coworker.

As for programming, we pair and again stress to the person interviewing to treat us (the interviewer) like their coworker. Don't remember that function? Ask. Need to Google and read something? Go for it. Ask our opinions. Talk out loud. It's amazing how many people break down during pairing—they don't ask for help, or when it's given, ignore it. We're conscious of this tendency so we're constantly checking in, asking questions that might lead to a path of inquiry that leads, well, maybe a solution! Maybe not. The pair programming portion is most useful IMO to see if the person has a sharp grasp of their tools, editor, is curious and enjoyable to work with. Often enough if all of those things are true, the language knowledge comes as part of the package.

I am independant consultant in France. I took several technical interviews. I just hate taking this kind of test. Very often the questions are based on something the interviewer knows very well but which is not most of the time a very important or very used in programming.
It is also often memory questions ! It is sometimes simple things that you just haven't used for a while. Then you just give the impression to the interviewer that you are novice. Then at the end, you just feel like bad developper.
Gladly sometimes you have the chance to find good interviewer who knows how to test you on some interesting and relevant questions.

Having been through a couple of live coding interviews myself, mostly on whiteboards, I found them horribly nerve-wracking. Especially since they usually involved around 3 or more people in the room, waiting for a flash of brilliance to appear. It was at this point, more often that not, the brilliance never came and it left me doubting my abilities.

I would much prefer a technical coding test if someone were to try assess my technical capability, then have me talk through the solution and discuss improvements, changing requirements, etc.

For me, interviews are pretty stressful already without the added pressure of trying to solve a problem under pressure while articulating your thoughts to the interviewers as well, on the spur of the moment.

I find coding interviews nerve-wracking. I recently had a coding interview with Google where in an hour I couldn't get a working solution to the problem they asked. I took another try at it a week later when I was relaxed and had something that worked perfectly in 10 minutes. I can work under pressure, but that's different than someone looking over your shoulder judging every keystroke.

Understanding requirements to complex specifications under huge time pressures and coding whilst your manager looks over your shoulder isn't really a good representation of a developer’s day to day working environment...or maybe it is :-(

Recently bombed at a technical test… and I mean really bombed, I couldn't believe how terrible I was. Managed to rescue it by pointing the interviewer to my open source projects on GitHub. He seemed really impressed and I got offered the job. I would say this was a much better representation of what he could expect me to produce if I had joined the company.

Going to user groups, like Software Craftsmanship, may help with this. And you could ask them to even do a segment like that, during the meet. (I need to take my own advice!)

I was asked to live code a factorial function. With a pen, on paper.

That was easily the most idiotic thing anyone has ever asked me to do. I need to be able to insert lines, rewrite names etc. when writing code.

If you are someone who asks for a live coding example, please let them use a computer, preferably an IDE.

Just don't forget that the interview goes both ways. In every interview I've done, I have to remind myself that it is my responsibility to interview the company/interviewer/boss as much as they are interviewing me. It doesn't necessarily lessen the anxiety, but it does give me a good frame of mind to manage the interview. While I may be worried about impressing the interviewer...I can't forget to let them impress me. If they make me uncomfortable or feel intimidated, pretty good chance it will be that way as an employee. This perspective also forces me to ask detailed questions about the company, environment, co-workers. I've been told that my ability to ask those probing questions were how I got the job.

Having failed (because I was too nervous) my first live coding interview last week, I feel comforted by the comments here.

I still believe that it's a good way to interview , but I need to practice.

I can relate to this anxiety from a certification perspective. Earlier this year I completed requirements for the MCSA: SQL Server 2012 certification. When I started I thought, no worries, SQL Server and I have been friends for a long time. Then I got in the booth, timer ticking away. I froze and bombed the exam. For me, getting over the anxiety was practice. I practiced, practiced, and then practiced some more. Like learning to output XML from a select statement, I had to learn how to take the exam.

I imagine this is how it is with live code interview. Learn how to interview and practice. After lots of practice my anxiety lessened, and my knowledge and experience was liberated.

I have been on both sides of the table during interviews and have noticed one thing from personal experience and observations.

From what I have observed, candidates who have had one or two jobs in their career tend to be more anxious during the interview compared to those who have been around the block more than a few times. This holds true whether they were coding on the whiteboard or just talking through a solution. I have seen everything from verbal cues such as stuttering or frequently pausing to more extreme physical ones such as shaking or ticks.

Personally, I've been in almost a dozen environments in my career (a 50/50 split as a FTE or contractor) which means I have had my fair share of interviews where some form of live coding was present. Just like getting on a stage or performing in front of an audience, the anxiety wore off the more I was exposed to it.

I found that practice interviews didn't serve much purpose other than going over material to make sure I know what I'm talking about. I got my exposure through interviewing with places I was unsure about and wouldn't be bothered if an offer wasn't extended. I went through these interviews with an attitude that I didn't care whether or not I would get the job while still asking all the right questions, answering questions to the best of my knowledge/experience, and admitting to when I was unsure of the answer. Long story short, this helped me have a more casual attitude during interviews that I really did care about and was able to give my potential employers a better picture of who I was and how I fit in with their culture.

Then again there are people who are just naturally anxious in situations like these and the best they can do is just let the interviewer know they are nervous, take it slow, and keep the interviewer talking more than the candidate.

I think it depends upon the position but personally I don't agree with "code tests" during the interview process for anyone with any experience. For new devs or students it makes sense.

As an interviewer I can glean whether you know what you're talking about without you having to write up code. Honestly, every developer is used to a modern IDE where you don't have to remember every little detail of some piece of code. That is what makes us productive. So whether you can quote the name and parameters of some arbitrary method vs Intellisensing doesn't tell me anything about your abilities.

I sat in an interview one time where they had me do some string manipulation.
Me: "No problem, there's several prebuilt methods in .NET that do that"
Them: "Assume they aren't available"
Me: "Why?"
Them: "We just want to see how you solve the problem"
Me: "So you want me to solve a problem that's already been solved? Your evaluation of my coding ability is based upon either that I don't know enough about the framework to know such a method exists or that I have the Not Written Here mentality?"
Me: "Bye"

In another interview I was given code and asked to describe what would happen.
Them: "What will this code output?"
Me: "This code is not technically valid, the compiler will generate a warning about improperly defined behavior because of this line."
Them: "But it compiles so what would be the output?"
Me: "As the compiler will warn you, the behavior is undefined/an implementation detail. In this release it might do one thing and the next another."
Them: "Assume the current compiler version"
Me: "So you want me to tell you how the current compiler will implement a feature that is considered undefined rather than, maybe, showing you how to fix the issue so it is defined?"
Them: "Yes"
Me: "Bye"

I don't consider this an issue at all. If in an interview you are asked to do things that make you uncomfortable to the point of distress then either the work environment you are auditioning for is being simulated and it is stressful or the people you are auditioning to work for are clueless, at best, as to what makes for a successful developer in their work environment (at worst, they are terribly insecure).

In other words, be yourself. If you can't be comfortable in the interview then what makes you want to work there anyway?

I have been the interviewer and the interviewee on a number of occasions. When I'm interviewing, I am sensitive to people being nervous but I've not really seen people crack under pressure, but I have seen people that are woefully underskilled. Nailing all the questions with straight answers is not really important, but the ability to discuss, assimilate and reapply is, which I don't think people are as anxious about.

An example of some of the javascript interview questions I use is here. They are specifically for testing the candidate's knowledge of a language, without worrying about design and larger constructs.

The problem I have with live coding is that I get nervous when people watch me using a computer even if it is another colleague. I dunno why, I just do.

Another thing I hate is overly long coding tests, I had one where they wanted me to create a MVC site, with Google maps, Search and A-Z etc and using Entity Framework or Linq to SQL as the data layer, which isn't too difficult but bare in mind, I had to:

• I had to also install the whole tool chain, VS2010 and then SQL SERVER (I rarely do .NET dev in my spare time, usual Python or PHP).
  
• Learn to setup the entity framework (not so easy on .NET 4 now as most of the newer templates don't support it).
  
• Import the data into SQL (it wasn't cleaned so I had to muck about getting the CSV ready)
  
• Re-learn the entity framework (We didn't use it at work, and it was a year since I had looked at it)
  
• Learn Google maps
  
• Learn razor (we did't use it at my last job)
  

I had to do this all in my spare time as well (took me an evening to install VS2010 and SQL SERVER). In the end, I did it and got offered the job (and turned it down as I had a better offer) ... but that is a fair bit of work (especially if you want to do it nicely) when you aren't guaranteed anything.

I think a bit of the blame falls on the interviewers here. The job of the interviewer is to get the absolute best out of a candidate in the short time available. This includes recognizing and combating excessive nervousness in the candidate.

If I see this happening I ask the candidate to stop white boarding and just chat for a few minutes. I make clear that I'm not looking for perfect code or perfect answers. Instead I'm much more interested in their thought process and how they approach problems. Once they've settled down a bit we move back to white boarding.

When I am in this situation I generally ask a lot of questions, take notes where they can see them and talk through the solution I'm writing. It makes it less stressful for me and I can get a read on how they feel that I'm doing. I will usually start out with a list of assumptions about what they are asking me to write and have them verify that my assumptions are valid. Then I will write out a list of test cases that I should fulfill. Then code the solution explaining what I'm doing.

For practicing doing how-to sessions to colea good way.

I've done my fair share of technical interviews from both sides.

The first ever interview I did when graduating was for a firm who made me write a function on a whiteboard. I was totally flummoxed and gave a bad account of myself, I didn't get the gig.

Since then I've had various interviews which required live coding, sometimes the code didn't even compile, but I was lucky enough that they went through the code and were interested in what I was doing, not that it wasn't finished.

These days I tend to get pairing exercises and TDD exercises along with questions which are designed to be problem solving rather than directly related to code.

The interviewer is usually looking for the fact you are bright, learn quickly, can write code of some description, enjoy writing code, and most importantly can act autonomously developing yourself.. skills like googling with bing are important.

@Mike Henderson,

You bring up a good strategy that I have never thought to intentionally try. Practicing at home has not brought me very good results in the past either, but like you I have found that the more interviews I go on, the more comfortable I become with the process. In the past few years I have been in about a dozen interviews and have received offers from almost half of them. I don't think I would have done as well if I hadn't built up confidence from prior interviews.

I like your idea of going on interviews for jobs that you won't be distressed about being turned down for. I also want to advocate for the interviewer though; it is not polite to waste their time. When I interview for a job, I consider it a real possibility. If I am offered the position, I will either gladly accept it, or I will politely turn it down, thank the interviewer for their time, and provide them with a valid reason why the offer is not right for me. Personally, I need to feel good about the experience, whether or not it turns into a job.

My process is very simple: it's just a job. It's not life. There are way more important things than any job. That doesn't mean I don't care about my work. The pride I take in is mine and very easy to pick by anyone who talks to me abou it.

I'm the hiring manager at my company and yes we do live coding for about 2 hours. We bring 3 - 4 senior members of our team to evaluate the candidate while they code.

What we are trying to look for is not only coding skills and how comfortable the person is behind the keyboard, but how they react under pressure as Scott mentioned. I can't count how many times people crack under pressure. Now I'm sure most people can code fine in the norm, but some times when a client comes calling that things are not working and we have tight SLAs to meet, pressure can happen often. And in those situations we need calm, we need action, we need solutions. We need to be able to think well under pressure.

Another trait we have found over the years is how many people say they have a ton of .net experience yet can't code some basic simple tasks like "Create a Class"!

After the years building up our team, I feel we have built up a strong core team that works well under pressure.

Not only are we looking for those traits, we are also looking for humility. We don't expect everyone to get the live coding to work, but that they can explain their thought process. Some people outright reject the test out of pride. There is no room for pride in our team.

Those intangibles are hard to pull out of an interview, and we have found that live coding really expresses that well.

We don't look for perfection, and we try to talk to the candidate doing a back and forth conversation to make the person feel comfortable. We express that we aren't looking for working code. It doesn't have to compile. But we can tell if the person knows what he/she is talking about just by a few minutes of coding.

We only want the best and brightest and we try hard to maintain that. As Steve Jobs once said, "A players hire A players", "B players hires C players".

Personally, I think Bruno hit the nail on the head. To add to it, be confident in what you know and be honest on what you don't. The worst thing that will happen is you won't get the job. They won't cut off your fingers so you can't "re-produce"...code. When you "fake" what you think people want to see/hear, you might get the job. However, you might also fail at the career path for the given company. You won't be happy and either will they. So, take a deep breath and let the magic flow.

Got to say, I once had an interview where I walked into the interviewer's office and he shouted, "Here, take this file, sort it, and remove the dupes!" I smiled, said ok, and did just that. I got the job and quickly realized that he was wasn't trying to abuse or rattle me--he was in the middle of a production support issue, dealing with a misbehaved piece of software that caused our shop much pain. Anyway, live coding interviews can be good or bad, just calm down, do your best, keep your humor, and don't sweat it.

I learned to just refuse these tests after about 20 years in the business. My success rate was OK, maybe 50%, but a half day of unpaid time was just too much to ask my family to gamble on a 50% chance of landing a job. It's just too much to go through for a job when there are plenty out there that don't place this demand on job-seekers.

It's not about pride, it's about cost: a days' productivity has a cash value of around $500. If job-seekers did five live-coding exercises per job hunt, they'd be giving away $2500 in value for no reward. That's a lot to expect out of someone who may be unemployed.

I have given a lot of live coding interviews. I have taken a lot of live coding interviews.
I think it really depends on your interviewer, how they take your anxiety. As you said, making clear and making so that "One has nothing to hide" can be helpful, but only when its done right and the interviewer understands the interviewee.
In my opinion - practice is only the best solution to this. Sometimes it is also because of a running clock. In order to solve this, here is what I did and what I suggest anyone should do.

Have some public code available.
Have a blog.
Code project? jsFiddle? open source project?
answer some questions on stack overflow
Exercise Top Coder specially if you have timing issues.

These things shall help anyone gain more confidence in their code when shown/shared.

Practice whiteboard coding on a no-pants Friday. This should address any anxiety issues.

I think they are a totally artificial way of identifying a person's ability to be a good software engineer. Use these type of tests as a way of filtering out unsuitable places of employment, I would excuse myself from an interview if I had not been told in advance that this was part of the interview process and if I had been informed I would remove myself from consideration.

Finding a position is a two way street it has to be right for yourself as well as the company and generally, like the company that is interviewing you, your most direct source of information is the interview process that the company puts you through. I personally think that if being put into a pressure box where you are sat in an unfamiliar environment, generally with alien equipment (in my experience usually a laptop without the tools that I am use to using and different keyboard bindings on the tools that I am familiar with) is such a critical requirement of what a candidate needs to thrive in their company then it is not really a productive environment for me to work in.

I once had an interview at Intel. I was asked to write an algorithm for optimizing tree traversal in a sparsely populated tree. It was a two hour interview with two engineers. I could write my algorithm on a white board but not use a compiler. Meanwhile one of the interviewers typed what I was writing on the whiteboard. When I got stuck I was exhorted to "Hurry up! Tell me what to type!" periodically or would just declare "That won't compile.". I got the job, but needless to say, I didn't do well on that particular question. Perhaps this was more of a behavior challenge rather than a technical question?

I recently had an interview with a major Redmond employer, for their cloud services team as a Frontend Engineer on their lets say 'account portal' team. I'd worked for this major Redmond employer full-time before for an awesome 11 year stint and was highly interested in this FE opportunity to come back to a great place to work. It was a major disappointment to get into the interview and have the first interviewer ask a data sorting and filtering problem, then proceed to check his phone constantly for email, and even respond a few times. The next interviewer asked me to create a linked list. When I responded with "I have no idea how to do that" and proceeded to review the FE job req along with my resume I was greeted with an awesome question. "So tell me what high level coding languages you have used in the past?" I knew I was toast at this point and of course I was. The next two interviews included one b-tree question, one palindrome question and one make three columns output vertically question. The latter being the only remotely front end like question in the entire process.

My point: Sure I was greatly disappointed I did not get the job. The interviewers could have been better prepared to ask relevant questions, not checked email during the screen and not wasted a whole days worth of my pay to visit. But also, and this is important, I should have known to be better prepared and studied ahead of time. I did not put my best foot forward and it showed. Well except the linked list question - that was way off sides in my opinion.

But hey, if you want a really good cross browser, mobile first, performance oriented front end developer that can also mash out sorting/data filters AND b-trees AND linked lists and and and, let me know when you find one and take a picture so I can post that right next to my ogopogo, bigfoot and unicorn selfies. ;o)

I gave a couple live coding exercise interview recently. The "Question" are "write some code that fetches data from database in any way you are familiar with". The answer can be as easy as "var data = db.SomeTable.Tolist()" if candidate is familiar with EF or as involves as creating connection, query, dataReader object.

I thought this is a simple request but after seeing all the candidates bombing, I begin to doublt. So is this question unfair or are the candidates just bad?