Coding interview question: how to be comfortable enough doing a certain task that naturally wouldn't happen very often?

Question

I get anxiety when doing coding for interviews and questions I normally would be able to complete I get stuck on in interview scenarios. I have read over this question which is about overcoming interview anxiety. One of the main answers it gives is to practice. I just had a technical interview that didn't specify what to practice, so how can one prepare?

Here is a particular example: reverse a linked list. I know what a linked list is, I've used them before, implemented them before and studied their time complexities. At some point in time I may have implemented a reversal algorithm, but certainly could not remember how to do it under the pressure of an interview.

My thoughts were:

1) Many languages have a linked list library with a reverse operation (at least Java does and that was the language being used)

2) Even if you did need to implement a linked list and a reverse method, you would only have to do it once per project. So how can one be very familiar with such a method?

I'm not arguing if it's a good or bad question, I'm asking how does one know to study things like that prior to a technical interview? Even if I had read up on data structures I still probably wouldn't have memorized such functions. The fact that the interviewer kept talking to me and telling me to explain things prevented me from figuring things out in the moment. At one point he asked "why do you need that variable?" and I replied "I may not I'm just thinking", was that a bad answer?

Are there another ways to combat interview anxiety than being very familiar and having practiced the same questions?

Answer 1

There's absolutely no way you should expect to be able to practice all possible questions.

It's not about memorizing anything, it's about having enough exposure to data structures and algorithms that you're able to figure it out, and quickly. And you get this exposure with practice.

• Take some online data structure and algorithms courses (e.g. from Coursera - they're free) - I learnt so much from some of these courses, which were supposed to be undergrad, even though I already had my degree - the difference between different universities are so large that you absolutely need to take some of these courses to make sure you're up to scratch.

• Spend some time on competitive programming sites (e.g. HackerRank, CodeChef, Topcoder).

• There are plenty of blogs and such (e.g. CareerCup and GeeksforGeeks.com) about coding interview questions - don't read the solutions right away, write the actual working code on paper and time how long it takes you - your goal is say under an hour from when you start reading the question, as that's around how long interviews usually are.

• Stack Overflow can certainly help, specifically the algorithm and data structures tags - you don't even have to answer anything (at first), you can just read the questions, try to figure it out yourself (try writing the code), and then read the answers. While many of the questions may not be interview questions, things like finding bugs in others' code will also do quite a bit to make you a better programmer.

  Reading and writing understandable answers also helps a lot with making yourself better at explaining yourself well, which is very useful in an interview (don't post code-only answers).

---

In terms of generic interview tips - talk.

I realize some people may think better in silence, but the problem with not saying anything is that the interviewer has no idea what you're thinking. Walk through what you're planning to do. If you have some ideas, even if you think they're bad or won't work, just share them (you can even say you think they're bad - believe it or not, but bad ideas often help your chances, a lot).

If you don't say anything, and you're not writing anything, the interviewer will most likely ask you questions to determine whether you might need a tip or what exactly is going through your mind.

You should expect to respond to a question at any time though - they may ask for your motivation for making particular choices, or try to lead you in the right direction with some leading questions.

Keep in mind that a 'bad', really obvious, solution is better than no solution - for your example, even if you just write code to step through the linked-list, and insert the elements into the front of another linked-list, that would end up with a reversed list, that's way better than not giving a solution. If you're ever stuck, take two steps back and try to think of some really inefficient way to solve the problem - with interview questions, there often is one.

Also, don't make any assumptions - asking for clarification is good. Actively try to not start writing code straight away - try to find at least something in the question that is unclear that you can ask about. Right of the bat - what type of linked-list is it? Double or single? You can ask about time and space complexity, but I wouldn't be too concerned with that to start, as these can serve as major distractions to a somewhat worse solution that may still be considered acceptable and end up getting you the job.

---

In terms of practising actual interviews - get yourself a programmer friend to do a few actual practice interviews with you.

Get yourself a whiteboard (or a notepad might work too), have him/her ask you something like "reverse a linked-list" and write the actual code on the whiteboard. Have him/her:

• Check that you're asking for clarification
• Check that you're not quiet and doing nothing for too long (I'm not sure how long is too long, 30 seconds?)
• Randomly pop in with a question asking why you made a particular choice or ask you to explain your code

They could get their questions from a blog about coding interview questions, so you have no idea what's coming (it could be an intentionally underspecified question, so you need to ask for clarification (good), or make a ton of assumptions (bad)).

I'd mix in some non-coding (i.e. HR) interview questions too, as you're likely to get these in actual interviews, and answering these might require different mindsets, and you're trying to make it as close to real as possible.

---

In closing - practice writing fully working code without an IDE, without testing it before it's completely done (and then extensively testing it to make sure it works). If you're not used to going without all the help an IDE gives you, you could have a hard time with that aspect alone.

Answer 2

Decades ago, I had a chemical engineering prof who was a really smart, ultra tough cookie. He would tell exactly what he would do to us on his exams, tell us exactly what questions he was going to ask. And then, he would wipe us out no matter how hard we studied. It was discomfiting to us as it was humiliating - You usually don't get into engineering school because you are a dummy.

We students eventually wised up and found the key:

(1) a good night's sleep. Seriously. If you are going to be under extreme stress, you'll react better and more effectively when fully rested. Or as fully rested you can be when you go to engineering school :)

(2) Expect the unexpected, but stop worrying about it. The problem/limitation with over studying and under thinking is there is no way that you practice for every eventuality. The universe of potential questions is just too large. What you can do is recognize elements of questions that you have studied before and work your way from there.

(3) Be utterly self-confident. If you screwed it, you screwed it. But if you think of yourself as smart and tough and ready for anything, that's what you become: smart, tough and ready for anything. That's how you become successful. Because the Goddess of Success is fickle with shallow loyalties and she loves those who are smart, tough and ready for anything.

(4) Work on your fundamentals. Keep working on your fundamentals until you you can do them in your sleep. It's not about memorization and cramming, it's about having understanding and control over what you are doing.

At the end of the day, winning is a matter of confidence: confidence in your abilities, confidence in your training, confidence in your knowledge of your strengths and weaknesses, confidence in your capability for uncompromising but fair self-examination, confidence that you'll win no matter what else can go wrong. And you know what, employers like self-confident people. Because they know or should know that they are putting their fate in the hands of their employees.

Answer 3

The whiteboard coding questions are about communication not memorization. While you may know what is technically the right answer in terms of code at the end, do you realize that what is really being evaluated here is how well do you communicate how you think, do you ask clarifying questions, what side considerations do you bring up and overall how well do you present your answer?

My suggestion is to take at least a handful of fairly simple programming tasks like reversing a linked list, reversing a string, building a priority queue, solving Fizzbuzz and consider running through the steps of how do you set up your solution. What questions do you ask upfront? Where do you seek clarification on if time or space is a priority for the solution? What languages do you use and are there others that may interesting to see what the solution would look like in those languages that perhaps you don't know so well.

I can remember getting a bit of a crash course from a recruiter when I lived in Seattle, Washington about these and it was quite useful to have the framework piece of knowing where I'd write the code, where would I put test cases, where would I state complexities, etc. so that I had a starting point of being organized and motor my way through the problem as these are supposed to be simple enough that if you had to figure it out, you likely could in the interview as it isn't about the trick in finding the algorithm but rather how well can you show that you have a good solution in the end.

If you want something for comparison purposes consider Math word problems in school. In grade 2 it is enough to get the number right at the end while in grade 7 it is more important to note what was the approach you use to justify your answer. While in grade 2 the teacher knows the answer and can acknowledge the kid that found it, in higher grades it is more important to be able to know why something is correct so that someone doesn't give a justification of, "Well, I just guess well so I thought this would work..."

Answer 4

Your job as a software engineer isn't to write code, it's to solve problems. Unless you're recently out of college, I would expect you (read: anyone competent applying for a programming job requiring previous experience) to work out how to reverse a linked list given a bit of time. Why? Because you're going to have to do very similar things in your job, but not things that already exist in some standard library.

Don't give me crap about interview pressure - your day to day job is very likely going to involve your clients or your boss pressuring you constantly.

This may be harsh, but interviews aren't meant for you to study for them. They're there to make sure you can do your job. If you can't do your job (solving random problems, potentially under pressure), then you shouldn't get the job.

Studying up to get past the interview just to get to a job where you can't study for every new problem is just setting yourself up for failure.

Answer 5

You shouldn't have to practice all questions and they likely specifically want to see you work on something you haven't specifically practiced. Exercises like that are useful because presumably you have some idea of what the problem is so it avoids the time wasting of them having to lay out all of the details, but since it's something you don't often do, they get to see an example of how you'd work in a real job scenario where you are programming out code of something you haven't done or don't normally do.

Saying "I may not I'm just thinking" was an okay answer as long as you said it in a polite tone. Half of the reason of having you do a problem like that is to see the actual implementation you did (did you use way too many variables? did you have an O(n^4) solution where an O(n) solution was present?). In that case, do the best you can do and if you do see a problem in your solution, you can let them know (i.e. "For now I have a placeholder function here, I can make the more efficient with a little more time."). However, the other half is just to see how you work. In this way, your answer let them know that. They may have asked you because they wanted to see how you approach problems and what things you think through. If you get an interviewer that is really focused on the details and is asking questions like that, it might help to just think out loud: "Okay, so the given linked list is set up like this. It looks like I want to end up swapping these pointers with those. I could do it recursively. That would lead to ... If I did it iteratively then that would lead to... Hmm... On the surface it looks like this approach is good. So, first I'll need a variable to hold..."

Answer 6

When applying for "Senior Software Engineer" positions it is still highly likely that I will get asked one of three questions at some point during the interview process (either during the phone screen or on-site), those being:

• Implement a doubly linked list.
• Implement a hash-table.
• Implement a binary search.

My suggestion would be that as part of your interview prep (before every interview) you implement all three of those with the appropriate insert, search & remove methods.

It will be tedious to start with, but after a while you will have the basic structure of each memorized and you will be able to simply type them in (or write on a board) from memory.

It might seem like a waste of time, but simply, put being able to knock those three out from memory might mean that your offer is 5-10K higher that it otherwise would be, so I would consider that well worth the time investment.