Whiteboard anxiety
March 3, 2015 11:17 AM Subscribe
In a few weeks I will begin interviewing for programming jobs. I'm having a lot of anxiety over the technical interview.
I'm making a career switch after having programmed as hobby for a long while.
I feel particularly anxious about whiteboarding. I would like to know what I can do concretely to both improve at whiteboarding and to feel less anxious about it. That is, I know that practice makes perfect but what else can I do? Any other general technical interview tips are appreciated.
I'm making a career switch after having programmed as hobby for a long while.
I feel particularly anxious about whiteboarding. I would like to know what I can do concretely to both improve at whiteboarding and to feel less anxious about it. That is, I know that practice makes perfect but what else can I do? Any other general technical interview tips are appreciated.
this might sound obvious, part of your practice should include actually solving the problems on a whiteboard.
this book is regarded to have a good set of problems to practice
http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X
as for other concrete steps, please check out my first article. i've started collecting concrete steps
http://www.csfluency.com/favorite-interview-question/
it's probably worth figuring out which parts of the interview causes you anxiety. there might be a mistmatch between what you think the interviewer expects and what you think you need to do.
for example, do you need to write code on the board that will compile? do you need to write error handling? are you allowed to ask questions? is there a right and wrong solution?
based on your assumptions we can probably help a bit more.
posted by maulik at 11:28 AM on March 3, 2015 [4 favorites]
this book is regarded to have a good set of problems to practice
http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X
as for other concrete steps, please check out my first article. i've started collecting concrete steps
http://www.csfluency.com/favorite-interview-question/
it's probably worth figuring out which parts of the interview causes you anxiety. there might be a mistmatch between what you think the interviewer expects and what you think you need to do.
for example, do you need to write code on the board that will compile? do you need to write error handling? are you allowed to ask questions? is there a right and wrong solution?
based on your assumptions we can probably help a bit more.
posted by maulik at 11:28 AM on March 3, 2015 [4 favorites]
Response by poster: A large portion of my anxiety is that I've been programming for a while in Clojure and it's the language that I feel most comfortable in. I've programmed in Python before, but not for over a year. So now I feel like I have to cram on Python as most places won't let you interview in Clojure.
I also feel weak in terms of my algorithms knowledge and have visions of me freezing up.
@maulik, I don't have answers to those questions. I imagine it's going to be different for each company.
posted by prunes at 11:33 AM on March 3, 2015
I also feel weak in terms of my algorithms knowledge and have visions of me freezing up.
@maulik, I don't have answers to those questions. I imagine it's going to be different for each company.
posted by prunes at 11:33 AM on March 3, 2015
Ask the recruiter those questions.
posted by magnetsphere at 11:40 AM on March 3, 2015
posted by magnetsphere at 11:40 AM on March 3, 2015
I think most places will be able to follow along with you in pretty much any language.
That being said:
Talk it out loud so they can see what you're thinking.
start with a bit of pseudo code and then fill it out.
If you have a question or need clarification, by all means ask it.
You need to get it far enough to show you answer the question, not compile it. Do fill out a for loop structure or say explicitly you are using an iterator of X. In the end, you might say you'd do something differently on second thought, or just use a library for such and such.
Perhaps go to the local library or other place with a whiteboard, and practice, the penmanship can be a little unusual to start with, and not smear writing with your palm.
posted by nickggully at 11:44 AM on March 3, 2015 [3 favorites]
That being said:
Talk it out loud so they can see what you're thinking.
start with a bit of pseudo code and then fill it out.
If you have a question or need clarification, by all means ask it.
You need to get it far enough to show you answer the question, not compile it. Do fill out a for loop structure or say explicitly you are using an iterator of X. In the end, you might say you'd do something differently on second thought, or just use a library for such and such.
Perhaps go to the local library or other place with a whiteboard, and practice, the penmanship can be a little unusual to start with, and not smear writing with your palm.
posted by nickggully at 11:44 AM on March 3, 2015 [3 favorites]
" most places won't let you interview in Clojure."
Really? Your interviewers might be somewhat confused (it would be a good idea to tell the recruiter upfront that it's the language you prefer so that they can pair you with an interviewer who also knows Clojure) but I feel like it's pretty unusual for a company to dictate what language you can use in your interviews.
posted by phoenixy at 11:48 AM on March 3, 2015 [1 favorite]
Really? Your interviewers might be somewhat confused (it would be a good idea to tell the recruiter upfront that it's the language you prefer so that they can pair you with an interviewer who also knows Clojure) but I feel like it's pretty unusual for a company to dictate what language you can use in your interviews.
posted by phoenixy at 11:48 AM on March 3, 2015 [1 favorite]
Reading about Steve Yegge's idea of an interview anti-loop made me less anxious. As much as we like to pretend that our interviews are super objective (and they are compared to many other industries), there's still an element of luck:
My experience has been mostly interviewing at startups and medium-sized companies. If you're interviewing at one of the big ones (Google, Microsoft, Amazon, Facebook, Twitter, Apple, etc.), I would trawl for past problems from the company and study up on them. They also tend to ask more computer science-y things and care more about formal credentials, but these are generalizations and can vary a lot from company to company or team to team.
posted by yaymukund at 11:49 AM on March 3, 2015 [2 favorites]
The bottom line is, if you go to an interview at any software company, you should plan for the contingency that you might get genuinely unlucky, and wind up with one or more people from your Interview Anti-Loop on your interview loop. If this happens, you will struggle, then be told that you were not a fit at this time, and then you will feel bad. Just as long as you don't feel meta-bad, everything is OK. You should feel good that you feel bad after this happens, because hey, it means you're human.In terms of preparation, just do a bunch of problems on your own. Time yourself. Be able to tell if an algorithm is
O(n), O(1) ("constant"), or O(n^2). My experience has been mostly interviewing at startups and medium-sized companies. If you're interviewing at one of the big ones (Google, Microsoft, Amazon, Facebook, Twitter, Apple, etc.), I would trawl for past problems from the company and study up on them. They also tend to ask more computer science-y things and care more about formal credentials, but these are generalizations and can vary a lot from company to company or team to team.
posted by yaymukund at 11:49 AM on March 3, 2015 [2 favorites]
For background, I've conducted dozens of tech interviews for startups.
The one absolute killer is silence. I need to know how you're thinking about the problem. It's likely you may not get all the way through the problem, but if I know how you're thinking about it, it gives me a good indication of your ability to solve it.
Don't get hung up on language-specific details. If you don't remember the exact API for something, just say you don't remember it exactly and make up a reasonable equivalent and move on to solving the meat of the problem. Also, don't hesitate to ask the interviewer if *they* know the answer.
Every few minutes, take a step back and see if you're actually solving the problem at hand or if you've become tangled in a yak shaving expedition. Personally, it's a strong positive signal when I see a candidate head off into the weeds, catch themselves, and then come back.
posted by AaRdVarK at 12:10 PM on March 3, 2015 [8 favorites]
The one absolute killer is silence. I need to know how you're thinking about the problem. It's likely you may not get all the way through the problem, but if I know how you're thinking about it, it gives me a good indication of your ability to solve it.
Don't get hung up on language-specific details. If you don't remember the exact API for something, just say you don't remember it exactly and make up a reasonable equivalent and move on to solving the meat of the problem. Also, don't hesitate to ask the interviewer if *they* know the answer.
Every few minutes, take a step back and see if you're actually solving the problem at hand or if you've become tangled in a yak shaving expedition. Personally, it's a strong positive signal when I see a candidate head off into the weeds, catch themselves, and then come back.
posted by AaRdVarK at 12:10 PM on March 3, 2015 [8 favorites]
Interview Cake is a fantastic resource. Walks you through the problems and the solutions, in detail, with tips on how to whiteboard them.
posted by danceswithlight at 12:34 PM on March 3, 2015
posted by danceswithlight at 12:34 PM on March 3, 2015
I've done a few of these myself, after having not had to formally interview anywhere in over 10 years. It's stressful. I think the best way to prepare is just to try and practice sample questions as much as possible. The Cracking the Code book mentioned above has been a good resource just to help me organize and actually work on problems rather than just stress and not do anything. The corresponding website also lists interview questions folks have had recently at various companies. And you want to be speaking as much as possible, articulating your thought process. I've also punted on compiler ready code and (from what I can tell) that's been fine, I just point out where I know it's not the exact syntax. Keep working until they seem satisfied. As you are writing out your solution, articulate the decisions you are making in your head. I've said things like 'I'm not sure a loop/switch/etc. is the best thing here, but I'm going to go with it for now and I'll review in a little bit, etc. etc.' When you think you are done review it for obvious flaws, possible optimizations, etc. Talk about how you would test it, etc. Good luck!
posted by snowymorninblues at 12:47 PM on March 3, 2015 [1 favorite]
posted by snowymorninblues at 12:47 PM on March 3, 2015 [1 favorite]
The details will vary between companies and between interviewers. You should be capable of whiteboarding compiler ready code in your language of choice, but hopefully you are allowed to be not quite as strict. If they want x86 Assembly, then you are simply out of luck. This would be good to know beforehand, and the recruiter should be able to help here.
I would assume that interviewers would tolerate hybrid psueodocode/realcode for whiteboarding. The key thing is to demonstrate your thought process, asking good questions, use of algorithms, and thinking through your code for the various paths/scenarios it could be used.
My general process as an interviewee:
Listen to problem
Ask clarifying questions (Including if there are any performance optimizations requested)
Whiteboard definitions around the problem (APIs, inputs, etc)
Verbally state the general approach I would take
Start whiteboarding with broad strokes of the solution
Go back and refine with details
Thinking outloud the whole time, to explain what I am doing and why. Express which concerns I have about I am doing and how I will circle back to validate the concern, or how I would revise things.
Once I have a working solution up, start walking through and explaining the code as though it was a code review.
Explain your solution's complexity O(n), and what other routes you could take if you wanted to optimize for IO instead, etc.
Practice beforehand by reviewing and implementing various datatypes and algorithms. Queues, Lists, Trees, Sort, Search, etc
posted by Diddly at 12:49 PM on March 3, 2015 [1 favorite]
I would assume that interviewers would tolerate hybrid psueodocode/realcode for whiteboarding. The key thing is to demonstrate your thought process, asking good questions, use of algorithms, and thinking through your code for the various paths/scenarios it could be used.
My general process as an interviewee:
Listen to problem
Ask clarifying questions (Including if there are any performance optimizations requested)
Whiteboard definitions around the problem (APIs, inputs, etc)
Verbally state the general approach I would take
Start whiteboarding with broad strokes of the solution
Go back and refine with details
Thinking outloud the whole time, to explain what I am doing and why. Express which concerns I have about I am doing and how I will circle back to validate the concern, or how I would revise things.
Once I have a working solution up, start walking through and explaining the code as though it was a code review.
Explain your solution's complexity O(n), and what other routes you could take if you wanted to optimize for IO instead, etc.
Practice beforehand by reviewing and implementing various datatypes and algorithms. Queues, Lists, Trees, Sort, Search, etc
posted by Diddly at 12:49 PM on March 3, 2015 [1 favorite]
FWIW, having interviewed a fair amount (and having talked to friends), actual whiteboard coding has become far less prevalent. Most places will have you do a coding challenge of some sort, either as a prerequisite for even getting an onsite interview or on your own laptop during the interview itself. More and more people are coming to realize that the traditional hiring process for developers is fundamentally broken.
Cracking the Coding Interview is a good book, and you should definitely read it. If algorithms are a weak spot for you, The Algorithm Design Manual is also a good resource. Most of the questions I've gotten revolve around using hash tables in some way, so it'd be good to bone up on those specifically.
Oh yeah, and for some reason interviewers love prime number generators. Read up on the Sieve of Eratosthenes (and remember that when you're checking for factors of a potential prime you only need to go up to the potential prime's square root).
posted by asterix at 12:54 PM on March 3, 2015 [1 favorite]
Cracking the Coding Interview is a good book, and you should definitely read it. If algorithms are a weak spot for you, The Algorithm Design Manual is also a good resource. Most of the questions I've gotten revolve around using hash tables in some way, so it'd be good to bone up on those specifically.
Oh yeah, and for some reason interviewers love prime number generators. Read up on the Sieve of Eratosthenes (and remember that when you're checking for factors of a potential prime you only need to go up to the potential prime's square root).
posted by asterix at 12:54 PM on March 3, 2015 [1 favorite]
You should probably also bookmark the Big O cheatsheet and make sure you know the complexities for the various sorts and data structures.
And remember that, like I said, the hiring process is fundamentally broken. You should do what you can to maximize your chances, but ultimately there's a whole lot that's out of your control, and if you don't get a given job it's not necessarily a reflection on how well you did in the interview.
posted by asterix at 12:57 PM on March 3, 2015 [2 favorites]
And remember that, like I said, the hiring process is fundamentally broken. You should do what you can to maximize your chances, but ultimately there's a whole lot that's out of your control, and if you don't get a given job it's not necessarily a reflection on how well you did in the interview.
posted by asterix at 12:57 PM on March 3, 2015 [2 favorites]
As far as the language problem I think this is going to vary widely from place to place depending on the type of programming that they do. I'll tell on myself - I've been programming in businesses for 18 years and have interviewed tons of people and I had to Google Clojure just now ... so ... yeah.
As far as whiteboard anxiety, nthing what some others said about the importance of talking aloud, sharing your process with the interviewers, and not getting hung up on exact code syntax (unless they are demanding that). I have very frequently asked this seemingly softball question: "Talk to me about a system you designed or worked on and how it was laid out. Feel free to use the whiteboard ..." only to have at least 30% of applicants completely fail to get up and go to the whiteboard at all! I really just want to know how people think about software and why, and if they have an idea of the big picture and aren't just code monkeys.
Like others said, practice explaining stuff to yourself on a whiteboard at home (you do have one, right?). Start general, then get into the coding bits. Know when you are talking big picture and when you are talking details and don't mix the two. Be honest, and highlight places where you know there are multiple ways to do things and talk about why you picked what you picked. You could also (god help them) try explain stuff to non-technical people for variety. I talk to my wife and 8 + 10 year olds about my work stuff all the time, and I am able to get them to see what's going on even though they have zero tech skills. My wife, much to her disliking, could probably now tell you why HTTP/2 is an improvement even though she didn't really know what HTTP was :-)
Good luck! Explaining stuff on whiteboards is really fun IMO if you are describing something cool. Oh ... also if you get stumped, admit it and counter with an explanation of something you *do* know a lot about. Nobody gets all the questions right!
posted by freecellwizard at 1:00 PM on March 3, 2015 [1 favorite]
As far as whiteboard anxiety, nthing what some others said about the importance of talking aloud, sharing your process with the interviewers, and not getting hung up on exact code syntax (unless they are demanding that). I have very frequently asked this seemingly softball question: "Talk to me about a system you designed or worked on and how it was laid out. Feel free to use the whiteboard ..." only to have at least 30% of applicants completely fail to get up and go to the whiteboard at all! I really just want to know how people think about software and why, and if they have an idea of the big picture and aren't just code monkeys.
Like others said, practice explaining stuff to yourself on a whiteboard at home (you do have one, right?). Start general, then get into the coding bits. Know when you are talking big picture and when you are talking details and don't mix the two. Be honest, and highlight places where you know there are multiple ways to do things and talk about why you picked what you picked. You could also (god help them) try explain stuff to non-technical people for variety. I talk to my wife and 8 + 10 year olds about my work stuff all the time, and I am able to get them to see what's going on even though they have zero tech skills. My wife, much to her disliking, could probably now tell you why HTTP/2 is an improvement even though she didn't really know what HTTP was :-)
Good luck! Explaining stuff on whiteboards is really fun IMO if you are describing something cool. Oh ... also if you get stumped, admit it and counter with an explanation of something you *do* know a lot about. Nobody gets all the questions right!
posted by freecellwizard at 1:00 PM on March 3, 2015 [1 favorite]
In my experience the recruiter won't know details of error handling and syntax expectations - they differ even between two interviewers at the same company. You should ask at the beginning of an interview, or as it comes up while you code.
I feel like it's pretty unusual for a company to dictate what language you can use in your interviews.
If the interviewers don't know the language, then you probably won't benefit much from using it on them even if they allow you - too much room for them to misunderstand what you are writing, expect you to do things in a way the language doesn't suit, want you to do error-handling the language renders unnecessary, etc. It might be worth doing if you know the language backwards and can explain it in terms of something they do know, but that doesn't sound like the case here.
posted by the agents of KAOS at 1:01 PM on March 3, 2015
I feel like it's pretty unusual for a company to dictate what language you can use in your interviews.
If the interviewers don't know the language, then you probably won't benefit much from using it on them even if they allow you - too much room for them to misunderstand what you are writing, expect you to do things in a way the language doesn't suit, want you to do error-handling the language renders unnecessary, etc. It might be worth doing if you know the language backwards and can explain it in terms of something they do know, but that doesn't sound like the case here.
posted by the agents of KAOS at 1:01 PM on March 3, 2015
I've interviewed a lot of programmers for famous US companies.
The book Programming Interviews Exposed is pretty good. Leafing through it is effective revison for basic CS stuff like manipulating linked lists which some people like to ask questions about, and which most people are rusty on, since linked lists don't get used that much in practise any more (most people use NSMutableArray or std::vector or whatever instead).
Don't be afraid to keep asking the interviewer for clarification as you start solving if the problem is vague. It's good to keep talking and sharing your ideas as you work to a solution and you can subtly use the interviewer's feedback to help you along. Interviewers know that real coding is done in private, on a screen, and doing it in public on a whiteboard is hard.
Do you know they are going to want Python solutions? I know I tended to ask everybody questions in straight C, as it's the lingua franca of the tech world.
(by spending time answering this question I'm procrastinating when I should be preparing for my own job interview tomorrow)
posted by w0mbat at 1:08 PM on March 3, 2015
The book Programming Interviews Exposed is pretty good. Leafing through it is effective revison for basic CS stuff like manipulating linked lists which some people like to ask questions about, and which most people are rusty on, since linked lists don't get used that much in practise any more (most people use NSMutableArray or std::vector or whatever instead).
Don't be afraid to keep asking the interviewer for clarification as you start solving if the problem is vague. It's good to keep talking and sharing your ideas as you work to a solution and you can subtly use the interviewer's feedback to help you along. Interviewers know that real coding is done in private, on a screen, and doing it in public on a whiteboard is hard.
Do you know they are going to want Python solutions? I know I tended to ask everybody questions in straight C, as it's the lingua franca of the tech world.
(by spending time answering this question I'm procrastinating when I should be preparing for my own job interview tomorrow)
posted by w0mbat at 1:08 PM on March 3, 2015
I have bypassed the whiteboard by bringing my own laptop into the interview, with my IDE open and ready with a fresh project and junit all maven'd in. When the interviewer asked me a coding question, I just whipped out the laptop and did it with tests and everything just like I'd do it for real.
Don't know how many places you could get away with this -- some may insist on whiteboarding -- but it's my SOP for interviews from now on.
posted by Sauce Trough at 1:48 PM on March 3, 2015
Don't know how many places you could get away with this -- some may insist on whiteboarding -- but it's my SOP for interviews from now on.
posted by Sauce Trough at 1:48 PM on March 3, 2015
I used to be a web developer, but am behind the times now since I've never even heard of Clojure.
But when dinosaurs roamed the earth, I don't believe it was ever a big deal to not remember the exact syntax for something. Pseudocode seems to have been fine in a lot of cases, maybe fleshing some of it out in a specific language. I'm nthing the idea that they want to see your thought process. If you are logical and articulate, that's most of it right there. In a real life situation you're always going to be able to look something up, but muddy thinking is a lot harder to fix.
All the preparation suggestions in this thread having to do with technical interviews is great, but I'd also like to suggest that you mentally and emotionally prepare yourself. I've always found that the right attitude to have is like you absolutely don't care whether you get the job or not. I've always gotten jobs and contracts where I had a relaxed attitude, ***even if I didn't feel I did well on the technical interview*** and I have failed to get a couple where I did well but may have felt uncomfortable for some reason.
So, whatever you can do to achieve that attitude on interview day would be great--whether that's meditation, happy chemicals from exercising vigorously, or going over in your mind why you don't really need this particular job and it's no big deal at all if you don't get it. Your attitude should be that you're just going to go talk to some people about coding for a while, no biggie.
posted by mysterious_stranger at 2:45 PM on March 3, 2015
But when dinosaurs roamed the earth, I don't believe it was ever a big deal to not remember the exact syntax for something. Pseudocode seems to have been fine in a lot of cases, maybe fleshing some of it out in a specific language. I'm nthing the idea that they want to see your thought process. If you are logical and articulate, that's most of it right there. In a real life situation you're always going to be able to look something up, but muddy thinking is a lot harder to fix.
All the preparation suggestions in this thread having to do with technical interviews is great, but I'd also like to suggest that you mentally and emotionally prepare yourself. I've always found that the right attitude to have is like you absolutely don't care whether you get the job or not. I've always gotten jobs and contracts where I had a relaxed attitude, ***even if I didn't feel I did well on the technical interview*** and I have failed to get a couple where I did well but may have felt uncomfortable for some reason.
So, whatever you can do to achieve that attitude on interview day would be great--whether that's meditation, happy chemicals from exercising vigorously, or going over in your mind why you don't really need this particular job and it's no big deal at all if you don't get it. Your attitude should be that you're just going to go talk to some people about coding for a while, no biggie.
posted by mysterious_stranger at 2:45 PM on March 3, 2015
I do a lot of white-board engineering interviews (from the other side of the table).
Absolutely, practice practice practice. On whiteboards, if at all possible!
I don't think choice of language per se will be a big issue (it wouldn't for me, as long as you can explain what you're doing) -- I'll write the code down and look up the language afterwards to ensure your code made sense. But if you are saying that you're an expert on a language, I'll want to see evidence of that! That doesn't mean you'll need the API reference in your head, but it means that your code should be idiomatic. I've seen people come in who claim to be Python experts and then struggle for 15 minutes to write a list comprehension. That's no good. Similarly, if you're coding in Clojure -- and it's your choice -- I'd want to see you default to immutable data structures and tail recursion rather than programming in an imperative style.
Interview questions are fairly limited in practice since they are trying to demonstrate "nontrivial" CS knowledge in a limited amount of time. This means that the vast majority of them involve some combination of recursion, dynamic programming, hash tables, binary trees, graph search, and string manipulation. Sometimes it's worth reverse-engineering the problem: "what techniques might this problem be trying to exercise?" But don't overthink it: problems can often start simple (or just be simple) so that you get some code on the board.
Last, this may have sounded intimidating, but interviewers are (or at least this interviewer is) really looking for good candidates. They are trying to see you at your best! So if you stumble a little bit, don't despair; they will give you plenty of opportunities to shine.
posted by goingonit at 3:14 PM on March 3, 2015
Absolutely, practice practice practice. On whiteboards, if at all possible!
I don't think choice of language per se will be a big issue (it wouldn't for me, as long as you can explain what you're doing) -- I'll write the code down and look up the language afterwards to ensure your code made sense. But if you are saying that you're an expert on a language, I'll want to see evidence of that! That doesn't mean you'll need the API reference in your head, but it means that your code should be idiomatic. I've seen people come in who claim to be Python experts and then struggle for 15 minutes to write a list comprehension. That's no good. Similarly, if you're coding in Clojure -- and it's your choice -- I'd want to see you default to immutable data structures and tail recursion rather than programming in an imperative style.
Interview questions are fairly limited in practice since they are trying to demonstrate "nontrivial" CS knowledge in a limited amount of time. This means that the vast majority of them involve some combination of recursion, dynamic programming, hash tables, binary trees, graph search, and string manipulation. Sometimes it's worth reverse-engineering the problem: "what techniques might this problem be trying to exercise?" But don't overthink it: problems can often start simple (or just be simple) so that you get some code on the board.
Last, this may have sounded intimidating, but interviewers are (or at least this interviewer is) really looking for good candidates. They are trying to see you at your best! So if you stumble a little bit, don't despair; they will give you plenty of opportunities to shine.
posted by goingonit at 3:14 PM on March 3, 2015
On the language front, I have a friend who successfully interviewed using Julia. He likes it because it gives him a chance to demonstrate deep language understanding by explaining some Julia-specific syntax &c. to the interviewers. So that can be a useful tactic. On the other hand, Clojure is probably hard for people since it is a Lisp and can look really strange, whereas using anything C-derived (at least syntactically) is probably a lot more familiar.
posted by dame at 3:25 PM on March 3, 2015
posted by dame at 3:25 PM on March 3, 2015
One of my few contributions to the Blue was a jokey thread about a whiteboard interview gone terribly wrong...and a jokey essay that sought to explain it. Instead of just being a collection of fluff, a really interesting conversation about how to conduct a whiteboard interview came about. It's on the other side from where you're standing now, but it gives you some insight into what interviewers are looking for and the motivations they have for the questions they ask. A lot of that is replicated here but thought you might enjoy CS301 Intro to V-- for a number of reasons if you missed it.
posted by Fezboy! at 4:16 PM on March 3, 2015
posted by Fezboy! at 4:16 PM on March 3, 2015
One of the important things to realize is that a good interviewer (especially for a junior position) is not actually interested in asking you coding and white-boarding questions to see what you know. Anyone with enough time and a good memory can memorize the common algorithms and frequently asked interview questions.
A good interviewer will intentionally push you just beyond what you know, and seeing how you respond. As a working programmer, Google and Stack Overflow (not to mention libraries and higher level languages) mean that the marginal utility to memorizing how to write a quicksort off the top of your head is pretty close to zero. Where the rubber hits the road is when you try to do something that's not in any text book.
So you should study algorithms and common questions, but even more important than memorizing answers is learning how to look at a question and come up with a good approach. Most interviewers would much prefer a candidate who provided careful reasoning to an incorrect answer to a candidate who wrote a perfect solution but couldn't articulate why they took that particular approach.
posted by firechicago at 6:14 PM on March 3, 2015
A good interviewer will intentionally push you just beyond what you know, and seeing how you respond. As a working programmer, Google and Stack Overflow (not to mention libraries and higher level languages) mean that the marginal utility to memorizing how to write a quicksort off the top of your head is pretty close to zero. Where the rubber hits the road is when you try to do something that's not in any text book.
So you should study algorithms and common questions, but even more important than memorizing answers is learning how to look at a question and come up with a good approach. Most interviewers would much prefer a candidate who provided careful reasoning to an incorrect answer to a candidate who wrote a perfect solution but couldn't articulate why they took that particular approach.
posted by firechicago at 6:14 PM on March 3, 2015
General Remark: bring your own dry-erase markers, and use them if you're asked to whiteboard something. You'd be surprised how often the markers they have handy also happen to suck; this is a low-difficulty way to reduce friction & anxiety.
posted by aramaic at 6:57 PM on March 3, 2015 [3 favorites]
posted by aramaic at 6:57 PM on March 3, 2015 [3 favorites]
(Full disclosure, I don't have experience in whiteboarding for coding interviews, but I do have some experience giving a technical chalk talk to an audience that was evaluating my performance, as well as some experience helping other people prepare for that situation.)
One potentially unhelpful thing I sometimes see people do in chalkboard interview situations is to read too much into what the interviewer is asking or telling them. Like thinking "oh shit, they asked me why I did XYZ, so XYZ must be wrong," when really it could be just that there are other equally fine options, or even that XYZ really is the best way but they are curious about how I knew how to use it. Or "I didn't understand that question so this means I must not know this area well enough," when it could be just that I literally just didn't understand the way they phrased the question, or even that the interviewer doesn't actually know the answer either and just wants to hear your thought process and how you'd reason through a tough problem. Also, don't feel afraid to iterate with your interviewer a few times so you can be sure you understand what they're actually asking you to do or explain. If you feel a little unsure about something, restating what they've asked back to them can be a good way to make sure you're actually on the same page.
(Also, it is completely normal to be nervous in this situation, and to feel like you're bombing even if you're doing fine. Knowing that can help you deal with that feeling if it comes up in practice or in the real deal.)
posted by en forme de poire at 7:28 PM on March 3, 2015
One potentially unhelpful thing I sometimes see people do in chalkboard interview situations is to read too much into what the interviewer is asking or telling them. Like thinking "oh shit, they asked me why I did XYZ, so XYZ must be wrong," when really it could be just that there are other equally fine options, or even that XYZ really is the best way but they are curious about how I knew how to use it. Or "I didn't understand that question so this means I must not know this area well enough," when it could be just that I literally just didn't understand the way they phrased the question, or even that the interviewer doesn't actually know the answer either and just wants to hear your thought process and how you'd reason through a tough problem. Also, don't feel afraid to iterate with your interviewer a few times so you can be sure you understand what they're actually asking you to do or explain. If you feel a little unsure about something, restating what they've asked back to them can be a good way to make sure you're actually on the same page.
(Also, it is completely normal to be nervous in this situation, and to feel like you're bombing even if you're doing fine. Knowing that can help you deal with that feeling if it comes up in practice or in the real deal.)
posted by en forme de poire at 7:28 PM on March 3, 2015
When I do interviews I usually am looking for the following:
- Is this person capable of modeling a problem? Not in code, necessarily, just conceptually. People who are smart usually tackle big problems by coming up with some organizing principles to break the problem down into small problems. If necessary, I kind of nudge someone toward one idea of how to model the problem, but I'd like to do as little nudging as possible. Coming up with a better model than I thought of is an automatic A++.
- Is this person easily flustered when presented with a new complication? Obversely, does this person try to act like their model for the problem is totally fine even though I just threw in an edge case that renders it broken? The second type of person here is really dangerous, IMO. Shitty code is written by people who arrogantly assume their original design was perfect and refuse to change it, giving all kinds of bullshit explanations for why this pattern is "a best practice," whatever the hell that means. (This is a pet-peeve of mine. The first type of person can be bad, too, but it's hard to discern interview jitters from true jitterinness.)
- What is this person's skill level with the particular language/technology that they're be using in their position? I usually do this by asking increasingly difficult/"advanced" questions about how to do something in the language, and then taper it off when it becomes clear where their skill level lies.
- What is their problem solving style? In a white-boarding interview, this might entail stating out loud things like, "Well, we know that the size of this list is going to be less than N" or whatever. I find that if someone can't explain out loud what they are thinking, they probably aren't thinking very well. Another thing I look for is this: smart people ask questions about the problem, they don't just stand there frozen at the whiteboard puzzling over it silently. I prefer to work with people who can clearly explain their ideas so this is a good litmus test.
posted by deathpanels at 7:55 PM on March 3, 2015
- Is this person capable of modeling a problem? Not in code, necessarily, just conceptually. People who are smart usually tackle big problems by coming up with some organizing principles to break the problem down into small problems. If necessary, I kind of nudge someone toward one idea of how to model the problem, but I'd like to do as little nudging as possible. Coming up with a better model than I thought of is an automatic A++.
- Is this person easily flustered when presented with a new complication? Obversely, does this person try to act like their model for the problem is totally fine even though I just threw in an edge case that renders it broken? The second type of person here is really dangerous, IMO. Shitty code is written by people who arrogantly assume their original design was perfect and refuse to change it, giving all kinds of bullshit explanations for why this pattern is "a best practice," whatever the hell that means. (This is a pet-peeve of mine. The first type of person can be bad, too, but it's hard to discern interview jitters from true jitterinness.)
- What is this person's skill level with the particular language/technology that they're be using in their position? I usually do this by asking increasingly difficult/"advanced" questions about how to do something in the language, and then taper it off when it becomes clear where their skill level lies.
- What is their problem solving style? In a white-boarding interview, this might entail stating out loud things like, "Well, we know that the size of this list is going to be less than N" or whatever. I find that if someone can't explain out loud what they are thinking, they probably aren't thinking very well. Another thing I look for is this: smart people ask questions about the problem, they don't just stand there frozen at the whiteboard puzzling over it silently. I prefer to work with people who can clearly explain their ideas so this is a good litmus test.
posted by deathpanels at 7:55 PM on March 3, 2015
maulik above mentioned the book "Cracking the Coding Interview" and it's a great resource for practice problems as well as general interviewing tips. I used it to prep for a big interview and wound up getting the job.
Here's what I did for that interview:
I practiced solving the questions from the book (and also from sites like HackerRank), working out solutions on pen and paper rather than on a computer.
I got together with a trusted programmer friend, found somewhere with a whiteboard, and had her ask me questions from the book for me to solve. This was really helpful because I had to not only come up with a solution, but also explain what I was thinking while I was doing it, like in an interview situation.
I refreshed my memory on big-O complexity and implementation for the standard undergrad algorithms (graph search, merge sort, tree traversal, etc).
In the interview itself, I made sure to ask a lot of questions and restate the problem before digging into the code. I also talked a lot about what I was thinking while I was writing, noting when I was unsure about something, saying "I wonder if it would help if...?" and so on. Often you'll get points for recognizing the particular quirk or constraint that makes the problem difficult, or noting the related problems.
Even though the experience was extremely stressful, I tried to channel the feeling of having fun solving an interesting problem. If something was tricky, I'd say "wow, this is a great/interesting question" or "I can see why you ask this in interviews, it's easy to get tripped up on [x]", things to suggest I was mentally engaged beyond omg gotta get the right answer. I tried to show enthusiasm and look excited when I made a breakthrough. The feelings were genuine, but I was perhaps a bit more demonstrative of them than I otherwise would be solving a programming problem.
When I'd finished writing my solution, I assumed there were mistakes in it and entered the "test/debug" phase of the interview, which usually meant tracing through it step by step and keeping track of variables on the whiteboard. Usually I had made mistakes here and there and this caught a few of them. I'd also try to figure out if it handled edge cases correctly.
My experience was that the interviewers gave me hints, were eager to help talk through the problem with me, and helped point out small errors. I think most interviewers probably want to see a candidate do well -- it's not fun watching someone get flustered and struggle for an hour and usually they'll at least try to nudge you in the right direction. They'll challenge you, but you probably don't need to worry that they're actively trying to trick you or slip you up. If they try to give you a hint, make sure you're listening!
If you're doing an all-day interview where you talk to 5-6 people, take advantage when they offer you bathroom breaks and water. Wear comfortable shoes.
posted by beatrice rex at 10:35 PM on March 3, 2015
Here's what I did for that interview:
I practiced solving the questions from the book (and also from sites like HackerRank), working out solutions on pen and paper rather than on a computer.
I got together with a trusted programmer friend, found somewhere with a whiteboard, and had her ask me questions from the book for me to solve. This was really helpful because I had to not only come up with a solution, but also explain what I was thinking while I was doing it, like in an interview situation.
I refreshed my memory on big-O complexity and implementation for the standard undergrad algorithms (graph search, merge sort, tree traversal, etc).
In the interview itself, I made sure to ask a lot of questions and restate the problem before digging into the code. I also talked a lot about what I was thinking while I was writing, noting when I was unsure about something, saying "I wonder if it would help if...?" and so on. Often you'll get points for recognizing the particular quirk or constraint that makes the problem difficult, or noting the related problems.
Even though the experience was extremely stressful, I tried to channel the feeling of having fun solving an interesting problem. If something was tricky, I'd say "wow, this is a great/interesting question" or "I can see why you ask this in interviews, it's easy to get tripped up on [x]", things to suggest I was mentally engaged beyond omg gotta get the right answer. I tried to show enthusiasm and look excited when I made a breakthrough. The feelings were genuine, but I was perhaps a bit more demonstrative of them than I otherwise would be solving a programming problem.
When I'd finished writing my solution, I assumed there were mistakes in it and entered the "test/debug" phase of the interview, which usually meant tracing through it step by step and keeping track of variables on the whiteboard. Usually I had made mistakes here and there and this caught a few of them. I'd also try to figure out if it handled edge cases correctly.
My experience was that the interviewers gave me hints, were eager to help talk through the problem with me, and helped point out small errors. I think most interviewers probably want to see a candidate do well -- it's not fun watching someone get flustered and struggle for an hour and usually they'll at least try to nudge you in the right direction. They'll challenge you, but you probably don't need to worry that they're actively trying to trick you or slip you up. If they try to give you a hint, make sure you're listening!
If you're doing an all-day interview where you talk to 5-6 people, take advantage when they offer you bathroom breaks and water. Wear comfortable shoes.
posted by beatrice rex at 10:35 PM on March 3, 2015
I've probably interviewed nearly a hundred people in front a whiteboard. If your interviewer is good, they'll say something like "use any language you want, use pseudocode, whatever, we just want to see how you go about the problem."
If they don't, head them off at that pass.
"The majority of my experience is clojure, so I'll just use pseudocode that looks something like that..."
Then don't bother with any niceties at all, and just go about solving the problems with emphasis on the big picture, robustness, error handling, boundaries, etc.
posted by colin_l at 10:46 PM on March 3, 2015
If they don't, head them off at that pass.
"The majority of my experience is clojure, so I'll just use pseudocode that looks something like that..."
Then don't bother with any niceties at all, and just go about solving the problems with emphasis on the big picture, robustness, error handling, boundaries, etc.
posted by colin_l at 10:46 PM on March 3, 2015
I too have given a lot of interviews of this sort. Pretty much all of the above is great advice. My own rambling thoughts follow:
Different people tend to have somewhat varying interviewing styles, so listen to what the interviewer is saying, and if you're not sure what kind of answer they're looking for, it almost never hurts to ask.
Ditto what someone said earlier: as an interviewer, I want to see people do well, and even when they don't, I want them to have a positive experience. Maybe not every interview will live up to that ideal, and it's OK to be nervous -- but if you can approach it as a conversation instead of a gauntlet you have to run, it'll probably be a lot easier and less stressful.
From my side of the desk, the most frustrating interviews are the ones where the candidate gets stuck somewhere and doesn't communicate effectively about what they're having problems with. My goal is to gain as much information as possible in the course of an hour (or whatever) and if you just stop talking, the only information I get is negative; it's by far preferable if I can give you a hint that lets you start making progress again. But it's largely your responsibility to keep those lines of communication open, and say where your thought process is going.
Opinions will vary on this, but personally, I ask people not to write pseudocode, at least not as their "final product." It's OK for brainstorming, but I find that it encourages people to get sloppy and not think too hard about details. I do tell them they can use absolutely any programming they want, though. (Personally, I would love to see someone start writing Clojure on the board.) If there's something about their chosen language that I don't understand, or that somehow trivializes the problem, I can always ask; after all, it's a conversation. I don't generally get too picky about syntactic details, but someone who shows that they really know the ins and outs of their language/tools always leaves a positive impression.
When you're actually writing code, try to plan ahead at least a little bit before you actually pick up a marker, so that you don't have to be constantly going back and erasing things. But on the other hand, if you do change your mind about something, it's usually faster and cleaner to just erase it and re-write it, rather than trying to hack around it and turning the entire board into a mess of scrawls and arrows.
Handwriting doesn't count for much, but it counts for something. If I literally can't read your writing, we're going to have a problem. Likewise, I'm not going to be too judgmental about things like variable names, but it can be hard for me to follow a function that's full of nothing but "foo"s and "tmp2"s and "dummyVar"s.
posted by teraflop at 11:55 PM on March 3, 2015
Different people tend to have somewhat varying interviewing styles, so listen to what the interviewer is saying, and if you're not sure what kind of answer they're looking for, it almost never hurts to ask.
Ditto what someone said earlier: as an interviewer, I want to see people do well, and even when they don't, I want them to have a positive experience. Maybe not every interview will live up to that ideal, and it's OK to be nervous -- but if you can approach it as a conversation instead of a gauntlet you have to run, it'll probably be a lot easier and less stressful.
From my side of the desk, the most frustrating interviews are the ones where the candidate gets stuck somewhere and doesn't communicate effectively about what they're having problems with. My goal is to gain as much information as possible in the course of an hour (or whatever) and if you just stop talking, the only information I get is negative; it's by far preferable if I can give you a hint that lets you start making progress again. But it's largely your responsibility to keep those lines of communication open, and say where your thought process is going.
Opinions will vary on this, but personally, I ask people not to write pseudocode, at least not as their "final product." It's OK for brainstorming, but I find that it encourages people to get sloppy and not think too hard about details. I do tell them they can use absolutely any programming they want, though. (Personally, I would love to see someone start writing Clojure on the board.) If there's something about their chosen language that I don't understand, or that somehow trivializes the problem, I can always ask; after all, it's a conversation. I don't generally get too picky about syntactic details, but someone who shows that they really know the ins and outs of their language/tools always leaves a positive impression.
When you're actually writing code, try to plan ahead at least a little bit before you actually pick up a marker, so that you don't have to be constantly going back and erasing things. But on the other hand, if you do change your mind about something, it's usually faster and cleaner to just erase it and re-write it, rather than trying to hack around it and turning the entire board into a mess of scrawls and arrows.
Handwriting doesn't count for much, but it counts for something. If I literally can't read your writing, we're going to have a problem. Likewise, I'm not going to be too judgmental about things like variable names, but it can be hard for me to follow a function that's full of nothing but "foo"s and "tmp2"s and "dummyVar"s.
posted by teraflop at 11:55 PM on March 3, 2015
teraflop: totally agree on the pseudocode. It's too easy for candidates to handwave past the details if they're writing pseudocode, and attention to details is one of the most important things to be looking for. Too often the "point" of the problem gets lost when you try to look only at the big picture.
posted by goingonit at 7:26 AM on March 4, 2015
posted by goingonit at 7:26 AM on March 4, 2015
I was going to hijack this post with my own related question. Then I started typing, and it got kind of long, so I made an FPP out of it. Feedback there would be greatly appreciated!
http://ask.metafilter.com/276921/help-me-describe-the-IT-worker-that-I-need-then-evaluate-the-candidates
posted by intermod at 11:14 AM on March 7, 2015
http://ask.metafilter.com/276921/help-me-describe-the-IT-worker-that-I-need-then-evaluate-the-candidates
posted by intermod at 11:14 AM on March 7, 2015
« Older After leaving the mechanic, my car revs violently... | Last chance vacation in the West: California or... Newer »
This thread is closed to new comments.
My best technical interview tip is to say you don't know something if you don't know it.
posted by cmm at 11:24 AM on March 3, 2015 [7 favorites]