Iyfjky

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?

Not a full answer here, but if you'd use an online reference to do the question in the real world, I'd usually say its reasonable to ask the interviewer if you can google it (or look it up elsewhere). At the end of the day, if you have the skills to complete the task, that's quite possibly what they're looking for. — Apr 8 '14 at 22:08
have a look at the book Cracking the Coding Interview (associated with the CareerCup website). The book has example questions and answers and also more general advice on how to tackle interviewing. As some of its reviews of amazon suggest, it's a very good resource for people already in a job: if you can understand all the material in the book, you should be in a position to do a good job as well as get the job. — Apr 9 '14 at 0:49
possible duplicate of How do you overcome interview anxiety when writing code? — May 7 '14 at 16:16
This question appears to be off-topic because it is an industry-specific question that belongs on a Programmers.SE. — Jul 30 '14 at 14:48
I don't mean to be insulting, but in my honest opinion if you can't reverse a linked list off the top of your head then you're exactly the kind of developer that they're trying to filter out. Anyone should be able to write that code in their sleep. — May 29 '15 at 20:54

score 15 · Accepted Answer · 2018-02-23 18:12:13Z

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.

Good answer. One more thing. I cam across this website that is designed to give small tasks to students/new graduates to help them gain experience and have something to showcase and take credit for at the end. riipen.com What do you think? youtube.com/watch?v=YuOG1bPRuwg is it worth it? — Apr 17 '14 at 20:14
Thanks. Never heard of it, sorry. You'll have to check it out for yourself. It could be great, a giant waste of time, or worse. — Apr 17 '14 at 20:38
In a job, you will be asked to do things that haven't been done before, at least not in exactly the same way. So they are asking you a question that hopefully you haven't answered before, to see how you handle it, to make sure you are not totally stuck if your job requires you to create an algorithm yourself. — Jul 30 '14 at 15:05

Vietnhi Phuvan 68.9k7118254 · Answer 2 · 2014-04-09 02:30:25Z

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.

expect the unexpected - great point, what usually happens... — Apr 12 '14 at 13:17

JB King 15.1k22957 · Answer 3 · 2014-04-08 22:03:06Z

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..."

Telastyn 33.9k977120 · Answer 4 · 2014-04-09 00:17:06Z

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.

Para 1: agreed. Para 2: (i) "Don't give me crap about interview pressure" this seems unnecessarily harsh, bordering on offensive. How do you know that the OP doesn't suffer from unnecessary anxiety (plenty of people do)? (ii) Some software jobs are incredibly low pressure: how can you be sure which the OP is applying for. Para 3-- agreed, if the OP can't do the job they shouldn't get the job. But re studying for interviews, I'd expect candidates to prepare for them just like they would for client meetings. Para 4, I get your point but learning to pass these interviews helps on the job too. — Apr 9 '14 at 0:44
@TooTone - Sure, but the original question misses the point... If you're having problems with interview problems, you shouldn't study interview problems, you should study problem solving. — Apr 9 '14 at 1:09
No offense taken, but to make your answer more useful why not discuss how to "study problem solving" — Apr 9 '14 at 3:26
@TooTone I would venture to say most software jobs are incredibly high pressure jobs. Most often, some guys in suits hired some "computerish guys" to go "do some computerish stuff". And they will hound on you until you produce exactly what they want, regardless of if they told you what it was. — Apr 11 '14 at 16:29
I agree, @TooTone, I often see the argument that interview pressure is a proxy for job pressure, but this is a False Equivalence fallacy. They are two very different types of pressure that the brain processes very differently. Direct observation/judgment pressure can divert mental focus more significantly than an impending deadline. Just ask someone who can't urinate when someone is watching. I bet they don't have a problem when they are just in a hurry, but still have privacy. — Sep 21 '16 at 9:52

RetiredAssistant 38715 · Answer 5 · 2014-07-30 14:45:10Z

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..."

score 15 · Accepted Answer · 2018-02-23 18:12:13Z

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.

Good answer. One more thing. I cam across this website that is designed to give small tasks to students/new graduates to help them gain experience and have something to showcase and take credit for at the end. riipen.com What do you think? youtube.com/watch?v=YuOG1bPRuwg is it worth it? — Apr 17 '14 at 20:14
Thanks. Never heard of it, sorry. You'll have to check it out for yourself. It could be great, a giant waste of time, or worse. — Apr 17 '14 at 20:38
In a job, you will be asked to do things that haven't been done before, at least not in exactly the same way. So they are asking you a question that hopefully you haven't answered before, to see how you handle it, to make sure you are not totally stuck if your job requires you to create an algorithm yourself. — Jul 30 '14 at 15:05

Vietnhi Phuvan 68.9k7118254 · Answer 7 · 2014-04-09 02:30:25Z

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.

expect the unexpected - great point, what usually happens... — Apr 12 '14 at 13:17

JB King 15.1k22957 · Answer 8 · 2014-04-08 22:03:06Z

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..."

Telastyn 33.9k977120 · Answer 9 · 2014-04-09 00:17:06Z

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.

Para 1: agreed. Para 2: (i) "Don't give me crap about interview pressure" this seems unnecessarily harsh, bordering on offensive. How do you know that the OP doesn't suffer from unnecessary anxiety (plenty of people do)? (ii) Some software jobs are incredibly low pressure: how can you be sure which the OP is applying for. Para 3-- agreed, if the OP can't do the job they shouldn't get the job. But re studying for interviews, I'd expect candidates to prepare for them just like they would for client meetings. Para 4, I get your point but learning to pass these interviews helps on the job too. — Apr 9 '14 at 0:44
@TooTone - Sure, but the original question misses the point... If you're having problems with interview problems, you shouldn't study interview problems, you should study problem solving. — Apr 9 '14 at 1:09
No offense taken, but to make your answer more useful why not discuss how to "study problem solving" — Apr 9 '14 at 3:26
@TooTone I would venture to say most software jobs are incredibly high pressure jobs. Most often, some guys in suits hired some "computerish guys" to go "do some computerish stuff". And they will hound on you until you produce exactly what they want, regardless of if they told you what it was. — Apr 11 '14 at 16:29
I agree, @TooTone, I often see the argument that interview pressure is a proxy for job pressure, but this is a False Equivalence fallacy. They are two very different types of pressure that the brain processes very differently. Direct observation/judgment pressure can divert mental focus more significantly than an impending deadline. Just ask someone who can't urinate when someone is watching. I bet they don't have a problem when they are just in a hurry, but still have privacy. — Sep 21 '16 at 9:52

RetiredAssistant 38715 · Answer 10 · 2014-07-30 14:45:10Z

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..."

Search This Blog

Iyfjky

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

5 Answers
5

Your Answer

Post as a guest

5 Answers
5

5 Answers
5

Post as a guest

Comments

Post a Comment

Popular posts from this blog

White Anglo-Saxon Protestant

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

One-line joke

Category

Random preview

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

5 Answers 5

Your Answer

Sign up or log in

Post as a guest

Post as a guest

5 Answers 5

5 Answers 5

Sign up or log in

Post as a guest

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Sign up or log in

Post as a guest

Comments

Post a Comment

Popular posts from this blog

White Anglo-Saxon Protestant

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

One-line joke

5 Answers
5

5 Answers
5

5 Answers
5