Dealing with stress in coding interviews

Question

I perform very poorly on coding interviews, I believe many people underperform in those interviews, but I feel like I am showing like 20% of what I got. In my last interview, the question was so simple that I thought there must be a mistake, or tricky point. I wound up spending a good 10 minutes for a question I would do in a minute, if it was not an interview.

I never explained this to interviewers and I don't have any alternatives. The typical advice I hear is to contribute to github projects that I use daily, but there aren't any software projects I use daily.

Is tackling with the stress is part of the interview, or should I explain upfront that I am terrible with interviews? How can I prove that I'm a good candidate?

Answer 1

I have a bit of experience with this question. I have sat in two job interviews as a candidate, and tens as an interviewer, so I do know both sides of the story.

As an interviewer, I don't care if you think you're not good at interviews. You just need to give it a red hot crack. To be fair to all candidates, there needs to be a systematic and uniform approach.

It's never about the actual answer, or the actual solution, it's about the thought process that counts in an interview. So, if you're not getting the question, vocalize the thought process. Ask questions. Probe the scenario.

Regarding contributing to projects on github. I think it's a bit of bad advice to contribute to projects you use daily. My advice would be to pick something that interests you. Smaller projects are easier to get started with.

Even if you were excellent at interviews, you should still try to build a portfolio of work that you can show off. You never know on the day how you will do, and who you are up against. And keep in mind, it's not just about the code that you push to projects, it's how you interact in pull requests when you get feedback.

As an interviewee, the first interview I didn't expect to land, so I went in there very casually, more looking for experience than anything. I did very well. I got the job. In the second interview, I was really nervous. I really wanted the role at that company. I completely panicked and really struggled to complete the tasks. I walked out of that interview feeling very dejected. I got the job.

So regardless of how you are going in an interview, it's usually not as bad as you think.

Answer 2

Obviously I can't speak for everyone (and I'm sure there are some interviewers who would disagree), but I never have a problem with interviewees telling me up front that they are nervous.

It won't lower the interviewer's standards for whether or not your answer is "good". However, in my opinion, if someone can acknowledge that they are in a stressful situation and that they need to use strategies to deal with the stress, it can be a good sign. At the very least, it shows a level of self-awareness

Try indicating to the interviewer what your thought process is. Coding questions are generally about more than "can this person solve this problem?", they are about trying to understand a person's whole problem solving process.

So if it takes you twice as long to actually get to the answer, but you are sharing with the interviewer the steps you are going through in your head in order to reach a solution, that can be just as positive as getting the answer in half the time. Plus, I find that actually talking through a problem can help with nerves.

Answer 3

Yes, tackling with the stress is part of the interview. I've found below 3 steps help me not have interview stress:

1. Ask meaningful questions for every problem asked - think aloud - a lot of the discussion would help clear the interviewer's expectations

2. Never jump to writing code directly - even if you know the problem, discuss with the interviewer your approach, this will help reinforce the solution in your mind, and make any corrections if required

3. Don't try to guess the interviewer's intentions from the problem - rather just focus on the problem at hand, and try to solve it - everything else will fall into place on its own

As for

how can I show I that am a good coder

While good StackOverflow, github profiles, personal projects, blogs help swing the perception in your favor, in my experience as an interview panelist, I have not seen even once someone being hired if they had these profiles but didn't do well in interviews. However, the reverse happens quite frequently and is almost the norm. So I would suggest to priortize interview preparation and problem solving over these profiles.

Answer 4

There is a difference between "being a good coder" and "being a programmer". Programmers know how to take a problem and solve it using the logical constructs a programming langauge/environment provides. A coder is someone who can take that solution and actually tell the computer how to do it. Most programmers are coders, not all coders are programmers.

What to do to help improve the impression you make really depends on what type of coding test it is. Some general things that my group looks for on these -

Ask questions - about the spec of the test, the infrastructure involved, etc. If we ask you to do a SQL statement (show the category for all items that cost less than $2 and have a product number that starts with 3), we expect questions about the DB layout, what keys are available to use, etc. If we ask you to write some sample code that runs that query and converts the resulting record set to a JSON string we expect questions about libraries we have available (Gson, etc), any in-house utilities (connect to DB and execute query), etc.

Show your work, or show understanding of the work - if you have to write code, first do it as comments in psuedo code then go back and fill in. Create stub methods with comments as to what they consume and do/return, etc. Show us you've planned out and written the program in your head/on your paper, then do the actual coding for it. Show good coding habits. If you are in an unfamiliar environment (Netbeans and you are used to Eclipse, or vice versa, etc) don't be afraid to ask where tools are located or similar "how to use the environment" questions, unless you've claimed proficiency in that particular set up.

Do not over think and over complicate this. That SQL statement example was the coding test for my most recent job - and I was given an hour to do it, two sharpened pencils and three sheets of printer paper. If you are wondering - the key was I asked about the DB structure, primary/foreign keys, etc. and it seems there are some product numbers that are alpha numeric so string comparison for the win :)

Answer 5

Occasional need to solve a problem under stress is reality in many (if not all) programming jobs. You may want to figure out how you deal with it in non-interview context and apply that to interviews.

Another important step is preparation and training - any occupation where stress is significant portion of the process always involve a lot of training. You not going to be flying F-18 in a diamond formation for Blue Angels after reading "flying in 24 hours" - you need hundreds of hours of flying and several times as many hours discussing every move right or wrong for single show... Treat interviews the same - review/learn basics and actually practice interviews on both sides.

• learn and practice basic data structures. Get your friend to ask one to code on whiteboard - "write expandable list using fixed size arrays", "find item in BST".
• refresh knowledge of O-notation... Claiming that removing element from array is O(1) because it is a single method call (I can't any other explanation for this) not going to help you much.
• learn what type of questions/interview style company you applying for use.
• just go to interviews with sole goal to practice your interview skills.
• review basic of testing. You should be able to instantly spit out basic test cases for most data structures. I.e. anything working on arrays need at lest 3 cases - 0, 1, 10000 elements irrespective of what the question was.

The goal is to make sure basic things you need for interview are not impacted by your stress level.

Side note: one of my interview questions is written on first page of pretty much any "how to prepare to coding interview" guide... which leads me to believe that if you stop after the first page you'll be ahead of a lot of people :)

Answer 6

As an addition to the other answers, there is sometimes an "impossible" question in a coding interview.

In such cases the point isn't to answer it correctly (this is nigh on impossible), but to demonstrate a logical thought process and understanding.

If you take this approach - that you may not actually solve the question, but you can demonstrate a good understanding, probe at the question, and as others have said - think out loud, then you may well reduce your own stress, and sometimes you might even "successfully" answer coding questions that you otherwise would not have!

Try this mindset, it can help a lot :)

Answer 7

"In my last interview, the question was so simple that I thought there must be a mistake, or tricky point. I wound up spending a good 10 minutes for a question I would do in a minute, if it was not an interview."

Put one foot in front of the other.

In other words: take things a step at a time. Solve the problem piece by piece and vocalise your thought process.

Vocalisation is very important here because it gives the interviewer scope to be generous. In your stated example it sounds like you were being overly cautious. This isn't perfect but it isn't problematic either (in some cases it might be very valuable behaviour!). If you are vocalising your concerns then the interviewer can see exactly what you are doing but if you silently stare at a blank page then they are likely to misunderstand and assume that you are having difficulty with the question.

If this doesn't come naturally to you then it would be a good idea to practice.

Answer 8

I experienced this two, in particular wondering if it's a trick question or not. I usually simply stated as much, something like "this looks straightforward, so now I'm wondering if it's a trick question." That usually brings reassurance that it's not.

I also had some success with explaining why I dislike such tests. The way I write code is more methodical and tends to result in more robust, correct code that is free from errors rather than rushing to a solution under pressure. I value the ability to keep working methodically and carefully even when there is time pressure, because ultimately it produces a better result. Generally interviewers seem to react positively, and if they don't you might want to consider what kind of working environment they offer - you don't want to end up constantly fire-fighting and throwing out low quality code.

Unfortunately you have put up with it until you reach senior level, at which point silly tests are usually a good sign you should be looking elsewhere for employment.

Answer 9

I see there's a selected answer already, but here are a few relatively concrete things that helped me with my interviewing in all respects, including my nerves:

• Assume you're qualified until demonstrated otherwise. You probably are.
• Assume your interviewers think you're qualified. They probably do.
• Assume the technical questions are just sanity and/or level-setting checks; they're not make-or-break for you, because you're an experienced coder.
• Admit your knowledge gaps readily. Ask about technologies or practices you haven't heard of. Be interested in learning about what you don't know, because you are. Whether you know ALL THE THINGS is usually irrelevant, because you don't.
• Come prepared with a few questions for your interviewer about the company, the job, and their experience working there. The questions should gather data on things you actually care about. A few of my favorites:
  • If hired, what do you see me doing in the next 3 months?
  • What will my day-to-day look like?
  • How do you define, prioritize, and manage work on this dev team?
  • Can I work from home when I'm not feeling well?
  • What do you like most about your job?
  • What do you like least about your job?
• Ask follow-up questions throughout the interview rather liberally, especially when ...
  • You don't quite understand the question
  • You need more time to think about the answer
  • You want to know what data they're really looking for
  • You're genuinely interested and/or curious about the topic/question. E.g., they ask about TDD, you might say, "Oh, I haven't had much exposure in my career. None of my mentors really do it. But, I'm super interested! Does your team really stress that? Do you find it's as effective as Uncle Bob says it does?"
  • You're given "coding" or "system design" questions, which are usually intended to assess two things: Basic coding ability, and ability to dialog and flesh out requirements.
• Practice. Interview a lot — especially when you do not need a new job.

And finally, the defining mindset-change I made, from which I've "extracted" most of these behaviors is this:

You should be interviewing them as much as they're interviewing you.

An interview is a chance to meet a company and their people to determine whether you'd all like to work together. It's not a test. It's a conversation, and it should be fun.

Answer 10

You have more experience with coding problems than you think. The interviewer wants to know if you would be a good colleague, so treat them like one. Treat an interview problem the same way you would if a colleague was asking for your help. Explain the parts you know, and ask clarifying questions. That helps a lot with relaxation, assuming you don't panic every time someone asks you a question at work.

You also have more experience coding under stress than you think. What do you do at work when you are tired, or have a headache, or are overwhelmed? Do those same things in an interview question. In those situations, I slow down a little and be more methodical. I use notes to keep my place. I talk through my approach with colleagues. I request more frequent feedback.

Answer 11

Interviewers take into account the candidate's stress more than you think. (Most all interviewers have, of course, been interviewees - some of them many times!) And as an interviewer you consider the entire session, not just the answer to one problem. And with that context it is reasonably easy to tell the difference between performance flaws due to stress and not knowing how to approach a problem. And also versus floundering around cluelessly. And also versus simple (and, especially, elaborate) bullshitting.

The best ways to distinguish your stress-related performance flaw (e.g., not coming up with the "correct" data structure on the fly) from floundering around cluelessly is to demonstrate that you are thinking things though: considering edge cases, considering alternatives, and seeking clarifying information.

The best tactic to use when you're lost is to announce that you're first going for a simple correct solution and then you'll consider improvements, e.g., to satisfy performance requirements. Then do exactly that: solve the problem simply and correctly then start discussing improvements.

The best way to go for a simple correct solution is to:

• Go for a simple solution (duh).
• Ensure you know the edge/failure cases before you start coding (write them on the board).
  • Many many times simply coding a correct solution that checks inputs for errors (via asserts) is enough to pass the question even before you refine it for clarity or performance.
    • You'll especially know that if the interviewer goes on to the next question instead of seeking improvements. You actually don't really know how deep he wants to go into one question until you first solve it for him simply.

Answer 12

as davidbak mentioned error checking is important, try/catching exceptions so your code doesn't fall all over the floor whenever something goes wrong. In your error handling, relay some useful information to the user.

The first few of many fallacies:
The network is always there. Input is always type which I am expecting. The client can be trusted etc etc etc.

Anything that can go wrong, will. Handle it. Then throw in a catch-all for the stuff you didn't anticipate. There's absolutely nothing wrong with catch(Exception $e){log something} being the last of your catch blocks. Checking inputs is huge for security as well. Strong error handling separates the men from the boys ;-) It also looks a lot better than throwing stack traces (or worse, nothing) at users.

You want to be descriptive enough to be useful, but not so useful that your error messages can be used against you.