When was the last time your boss actually asked you to detect a cycle in a linked list?
October 21, 2010 10:49 AM Subscribe
Help! I'm really really bad at computer programming interviews. Unfortunately ... I'm a computer programmer.
You know the kind of interviews I'm talking about. The ones where they make you try to solve some kind of algorithm problem on a whiteboard. Or the ones where they sit you down at a computer and tell you to solve some kind problem. Often, these problems involve things that maybe you haven't even touched since your CS undergrad years (how many people implement linked lists in their everyday jobs?)
I'm TERRIBLE, TERRIBLE at these interviews, despite the fact that I'm actually a really skilled programmer with 7+ years of professional experience. I freeze up, get nervous, forget everything I know, and in general come off as an incompetent buffoon. I get turned down for jobs that I feel like I shouldn't be turned down for.
These types of interviews are antithetical to my entire working style. I'm not somebody who does well under extreme pressure. I can't even type when somebody is watching me. I do best when I can take a moment to think about a problem, walk away from my computer for a while, get a snack, and maybe sit in the corner with a pad and pen for a while. Sometimes I get my best inspiration when walking home from work. My college experience was reflective of this : any class where the grade was largely derived from projects, I'd regularly get A's -- even the really hard "weed-out" classes. But I'd typically get C's (or low B's) in classes where the grades were mostly derived from tests.
I wouldn't complain if I was being turned down for jobs that required lots of split-second decision-making under pressure (this is why I never got into sysadmin work), but the jobs I apply for are all pretty much standard dev jobs.
As I mentioned, I have plenty of experience, and have produced solid results for all my employers. And I'm not just talking about simple tasks -- I've created some rather complex pieces of software, and seen them through from conceptualization to deployment. I have excellent references, and all my previous bosses love me. Unfortunately, I feel like employers see these kinds of qualifications as "get your foot in the door" type of things. Once you're in the interview room, they want you to be able to jump through hoops and do their little programming tests.
Anyway, I could complain forever about how unfair and ridiculous this situation is -- where exactly is the research which proves that good engineers are all skilled at completing whiteboard problems in job interviews? -- my industry seems slavishly devoted to this interviewing style, and I have to learn how to deal with it.
How can I get better at these types of interviews? Any ideas, tips, or resources you can suggest are welcome.
You know the kind of interviews I'm talking about. The ones where they make you try to solve some kind of algorithm problem on a whiteboard. Or the ones where they sit you down at a computer and tell you to solve some kind problem. Often, these problems involve things that maybe you haven't even touched since your CS undergrad years (how many people implement linked lists in their everyday jobs?)
I'm TERRIBLE, TERRIBLE at these interviews, despite the fact that I'm actually a really skilled programmer with 7+ years of professional experience. I freeze up, get nervous, forget everything I know, and in general come off as an incompetent buffoon. I get turned down for jobs that I feel like I shouldn't be turned down for.
These types of interviews are antithetical to my entire working style. I'm not somebody who does well under extreme pressure. I can't even type when somebody is watching me. I do best when I can take a moment to think about a problem, walk away from my computer for a while, get a snack, and maybe sit in the corner with a pad and pen for a while. Sometimes I get my best inspiration when walking home from work. My college experience was reflective of this : any class where the grade was largely derived from projects, I'd regularly get A's -- even the really hard "weed-out" classes. But I'd typically get C's (or low B's) in classes where the grades were mostly derived from tests.
I wouldn't complain if I was being turned down for jobs that required lots of split-second decision-making under pressure (this is why I never got into sysadmin work), but the jobs I apply for are all pretty much standard dev jobs.
As I mentioned, I have plenty of experience, and have produced solid results for all my employers. And I'm not just talking about simple tasks -- I've created some rather complex pieces of software, and seen them through from conceptualization to deployment. I have excellent references, and all my previous bosses love me. Unfortunately, I feel like employers see these kinds of qualifications as "get your foot in the door" type of things. Once you're in the interview room, they want you to be able to jump through hoops and do their little programming tests.
Anyway, I could complain forever about how unfair and ridiculous this situation is -- where exactly is the research which proves that good engineers are all skilled at completing whiteboard problems in job interviews? -- my industry seems slavishly devoted to this interviewing style, and I have to learn how to deal with it.
How can I get better at these types of interviews? Any ideas, tips, or resources you can suggest are welcome.
Build up your confidence through practice. There are books of interview questions and answers, and websites devoted to the topic. You'll get to be able to recognize the common questions and tricks.
posted by qxntpqbbbqxl at 10:58 AM on October 21, 2010
posted by qxntpqbbbqxl at 10:58 AM on October 21, 2010
Best answer: Oddly enough, though I'm not a programmer, I may have some insight for you. My husband is one of the lead developers for a small software company, and he worked as a consultant (both giving and taking a lot of interviews) for years before this more stable situation came along.
First and foremost, don't be afraid to ask for or use resources. If they're wanting you to demonstrate your capabilities at problem solving as well as your fluency with the language, bust out the man pages! Whip out your phone and look up the right way to do something you haven't practiced. And, hell, ask questions, and don't hesitate to tell the interviewers that "yeah, in the projects I've been working on, I haven't used this in a while." This is one of the things I've heard from Mr.Mirror time and time again - "well, he seemed to have a basic grasp of the language, at least, but his problem solving skills were terrible and there was no communication going on at all."
I know that what my guy (and other geeks like him, who get a LOT of say in the hiring process) are looking for is not only fluency in the language and familiarity with a lot of its basics, but also your style and a sense for how you approach things. Admitting ignorance is not a fault - it's a skill. And the way you admit ignorance (do you noodle around the problem for a long time before giving up? Do you research it intensely? How quick are you to find the answer? Do you ask other people for a little input or a nudge in the right direction? do you ingeniously whip up a solution to the problem using some other technique you're more familiar with?) demonstrates to your potential future coworkers what it's going to be like having you on the development team.
Anywho, I hope that helps some. My biggest advice is to just try to relax and enjoy it, as counterintuitive as that seems. Look at it as a brain teaser or a puzzle rather than a test. You know that you know this stuff, and you know that you know ways to find out the things you don't know, so just go with it.
posted by lriG rorriM at 11:05 AM on October 21, 2010 [5 favorites]
First and foremost, don't be afraid to ask for or use resources. If they're wanting you to demonstrate your capabilities at problem solving as well as your fluency with the language, bust out the man pages! Whip out your phone and look up the right way to do something you haven't practiced. And, hell, ask questions, and don't hesitate to tell the interviewers that "yeah, in the projects I've been working on, I haven't used this in a while." This is one of the things I've heard from Mr.Mirror time and time again - "well, he seemed to have a basic grasp of the language, at least, but his problem solving skills were terrible and there was no communication going on at all."
I know that what my guy (and other geeks like him, who get a LOT of say in the hiring process) are looking for is not only fluency in the language and familiarity with a lot of its basics, but also your style and a sense for how you approach things. Admitting ignorance is not a fault - it's a skill. And the way you admit ignorance (do you noodle around the problem for a long time before giving up? Do you research it intensely? How quick are you to find the answer? Do you ask other people for a little input or a nudge in the right direction? do you ingeniously whip up a solution to the problem using some other technique you're more familiar with?) demonstrates to your potential future coworkers what it's going to be like having you on the development team.
Anywho, I hope that helps some. My biggest advice is to just try to relax and enjoy it, as counterintuitive as that seems. Look at it as a brain teaser or a puzzle rather than a test. You know that you know this stuff, and you know that you know ways to find out the things you don't know, so just go with it.
posted by lriG rorriM at 11:05 AM on October 21, 2010 [5 favorites]
I don't know if this helps you, but when I give an interview and give my whiteboard question, I make a big distinction between someone who knows that they are not performing up to their usual level and feels flustered about it (okay) and someone who blithely writes down nonsense and doesn't realize that they're screwing up (not okay).
Anyway, I could complain forever about how unfair and ridiculous this situation is -- where exactly is the research which proves that good engineers are all skilled at completing whiteboard problems in job interviews?
All I can say is that in my personal experience, my ability to weed out false positives (people who seemed good on paper and talked a good game but turned out to be disappointing on the job) has skyrocketed since I started giving a whiteboard question. Of course I may be getting more false negatives these days. (That data set is over 20 people hired and many more than that interviewed.)
posted by dfan at 11:09 AM on October 21, 2010 [1 favorite]
Anyway, I could complain forever about how unfair and ridiculous this situation is -- where exactly is the research which proves that good engineers are all skilled at completing whiteboard problems in job interviews?
All I can say is that in my personal experience, my ability to weed out false positives (people who seemed good on paper and talked a good game but turned out to be disappointing on the job) has skyrocketed since I started giving a whiteboard question. Of course I may be getting more false negatives these days. (That data set is over 20 people hired and many more than that interviewed.)
posted by dfan at 11:09 AM on October 21, 2010 [1 favorite]
I feel for you so much. "Gotchas" and "trivia quizzes" are moronic and prove nothing about the candidate except maybe his coincidental recall of some of the things the interviewer knows. "Brain teasers" are a whole other depth of stupidity. My all time favorite (has this ever actually happened? I hope not) is the one where they ask you the color of the wall behind you and if you turn and look, you fail. What a great way to hire people who a) memorize meaningless details and b) don't test or verify their work, even when it would be incredibly easy to do so.
Here's what has helped me a bit with these types of interviews:
1) Study. I print the pages from Wikipedia on the main skills required, and study them. These are languages i already know, of course, but I'm looking for buzzwords I can throw out and "gotchas" they will try to catch me on. If it's a phone interview, I spread out the papers on the floor in front of me. Mostly I treat interviews as an opportunity to throw out as many terms as possible that make it sound like I know what I'm talking about.
2) Deflect. If you really don't know it, admit you don't know it, then ask them, "so what is that?" Once they tell you, relate it to something you do know and you still end up sounding fairly knowledgeable.
3) Find out what the questions will be in advance. This is the best way. If you are being sent in by a recruiter, they probably have sent other candidates already. Recently, a recruiter gave me an exact breakdown of what would be asked, and I studied up. Sure enough, at the interview, I looked like a genius and totally nailed it. Still didn't get the job, since they didn't have actually have funding to pay someone, but I did nail the interview.
posted by drjimmy11 at 11:09 AM on October 21, 2010
Here's what has helped me a bit with these types of interviews:
1) Study. I print the pages from Wikipedia on the main skills required, and study them. These are languages i already know, of course, but I'm looking for buzzwords I can throw out and "gotchas" they will try to catch me on. If it's a phone interview, I spread out the papers on the floor in front of me. Mostly I treat interviews as an opportunity to throw out as many terms as possible that make it sound like I know what I'm talking about.
2) Deflect. If you really don't know it, admit you don't know it, then ask them, "so what is that?" Once they tell you, relate it to something you do know and you still end up sounding fairly knowledgeable.
3) Find out what the questions will be in advance. This is the best way. If you are being sent in by a recruiter, they probably have sent other candidates already. Recently, a recruiter gave me an exact breakdown of what would be asked, and I studied up. Sure enough, at the interview, I looked like a genius and totally nailed it. Still didn't get the job, since they didn't have actually have funding to pay someone, but I did nail the interview.
posted by drjimmy11 at 11:09 AM on October 21, 2010
I think a sort of practiced nonchalance helps a great deal. Treat these problems as abstractions, free of implementation details, just ideas you can whiteboard out and talk about, aloud, as if you were chatting with some friends about how you might build a clubhouse.
I found myself interviewing with someone who worked for Microsoft at one point. Their evangelism runs deep, so he asks me to solve this video game puzzle, one which involves something called a "knight's tour" on a truncated chess board. Only I do not know how the horsey-piece (the horse is actually a knight, go figure) moves. I tell him this and he asks, "You don't play chess?" with that kind of "You're smart. All smart people play chess" tone of which I am weary, so I say, "Tell me what moves are allowed for this piece."
With this information, I decompose the allowed moves versus the board onto a sheet of paper to a very simple path, with numbered nodes related to each square on the board. I trace my finger down the path, writing down each number, then return everything in whatever that chess notation was, and say "This problem is a lot easier if I turn this into Candyland."
I got the job, partly because I solved the problem but also because I was not afraid to show what I did not know and to reason my way through the process with the interviewer.
Relaxation is a lot easier if you already have a job and can treat the interview as an experience which may or may not result in a new job, rather than something critical.
posted by adipocere at 11:10 AM on October 21, 2010 [1 favorite]
I found myself interviewing with someone who worked for Microsoft at one point. Their evangelism runs deep, so he asks me to solve this video game puzzle, one which involves something called a "knight's tour" on a truncated chess board. Only I do not know how the horsey-piece (the horse is actually a knight, go figure) moves. I tell him this and he asks, "You don't play chess?" with that kind of "You're smart. All smart people play chess" tone of which I am weary, so I say, "Tell me what moves are allowed for this piece."
With this information, I decompose the allowed moves versus the board onto a sheet of paper to a very simple path, with numbered nodes related to each square on the board. I trace my finger down the path, writing down each number, then return everything in whatever that chess notation was, and say "This problem is a lot easier if I turn this into Candyland."
I got the job, partly because I solved the problem but also because I was not afraid to show what I did not know and to reason my way through the process with the interviewer.
Relaxation is a lot easier if you already have a job and can treat the interview as an experience which may or may not result in a new job, rather than something critical.
posted by adipocere at 11:10 AM on October 21, 2010 [1 favorite]
Best answer: Here is some advice I recently gave to someone with whom I did a mock interview (acting as the interviewer):
Be clear and precise. Interviewers are looking for people who are experts in their areas. Everything we do has very precise technical definitions, and we have quite a collection of technical jargon that goes with it. When explaining what you've worked on or how you plan to solve a problem take a second to formulate your answer so that is it clear. Don't assume the interviewer knows what you're thinking.
Be confident. You know what you're talking about. Sure, you may not know the answer to the question until you've thought about it and worked it out, but don't let the questions or the questioner intimidate you. Practice speaking loudly and clearly, and pretending that not only are you the one for the job, but that you're so overqualified that the questions are merely an amusement to you.
Ask questions. Before you begin to explain your answer, or how you would implement this or that, ask the interviewer clarifying questions. Ask about the scenarios they imagine the code being used in. Ask about what they would like to optimize for when given different trade-offs. Ask pointed questions about what it is they're really asking for.
Think through alternatives. When you think you're ready to being coding, or proposing a form of implementation or solution to a problem, take a step back and think through other possible solutions. For example, in the number reference counting problem, min-heap lead to a solution that worked, but there were at least two other simpler-to-code solutions that work equally well... depending on what we're optimizing for.
Break the problem into chunks. Make sure you understand the inputs and outputs and if the problem has more than one step to get to a solution, think each step through on its own. Remember, getting a working solution that may be non-optimal in terms of speed or memory is always better than a solution that doesn't work at all.
Stay excited. Interviewers are looking for people who are passionate about technology, so show your passion. Bring snacks to munch between interviews to keep your blood sugar levels up. Eat breakfast.
Don't be afraid to admit you don't know something, but don't let that prevent you from answering a question. Question the interviewer for background, and show that you want to learn how to solve the problem. Let them guide you.
posted by jeffamaphone at 12:06 PM on October 21, 2010 [3 favorites]
posted by jeffamaphone at 12:06 PM on October 21, 2010 [3 favorites]
Often, these problems involve things that maybe you haven't even touched since your CS undergrad years (how many people implement linked lists in their everyday jobs?)
...
I wouldn't complain if I was being turned down for jobs that required lots of split-second decision-making under pressure (this is why I never got into sysadmin work), but
...
Once you're in the interview room, they want you to be able to jump through hoops and do their little programming tests.
...
Anyway, I could complain forever about how unfair and ridiculous this situation is -- where exactly is the research which proves that good engineers are all skilled at completing whiteboard problems in job interviews? -- my industry seems slavishly devoted to this interviewing style
You sure they're not picking up on your hostility and contempt?
I'm dead serious here. I once completely flubbed a question during a discussion in an interview. I started to get flustered, stopped, apologized and said I had gotten flustered because this was an area I hadn't been working on for a while. We went on with the discussion in a different direction and it went well enough that the ended up offering me a job (which I declined for unrelated reasons). The flub, like most failures, is less important than how you handle it.
The reality is that this is a career path that still has its share of oddballs and a lot more leeway is given to differing work styles than in other career paths. If you're not able to navigate this issue you should give serious consideration to the idea that you're having as much problem with your attitude about this as you are your challenges. Perhaps it's just a matter that you dislike this and you're not effectively communicating the way it challenges you well, leaving them feeling like you're resistant to helping them make sure you know what you say you do AND are unable to do it.
Some places simply aren't going to accommodate you. You can (counter-productively) think less of them for it, but perhaps there's something in their culture that considers this valuable. Quite frankly I've had a lot of very productive time in my career in front of a whiteboard with other coworkers brainstorming a problem. If your style precludes that it might be a deal-breaker for some places.
I'd honestly suggest you view this as your top professional development priority. The ability to work in this sort of style is valuable; what you're describing isn't THAT dissimilar to being asked to help a colleague who's stumped or solve a high-priority bug. If you're not as good as the average person at that then you're at a professional disadvantage. Practice some drill-type work with a friend till you are at least less anxious and self-defeating about it.
posted by phearlez at 12:08 PM on October 21, 2010 [3 favorites]
...
I wouldn't complain if I was being turned down for jobs that required lots of split-second decision-making under pressure (this is why I never got into sysadmin work), but
...
Once you're in the interview room, they want you to be able to jump through hoops and do their little programming tests.
...
Anyway, I could complain forever about how unfair and ridiculous this situation is -- where exactly is the research which proves that good engineers are all skilled at completing whiteboard problems in job interviews? -- my industry seems slavishly devoted to this interviewing style
You sure they're not picking up on your hostility and contempt?
I'm dead serious here. I once completely flubbed a question during a discussion in an interview. I started to get flustered, stopped, apologized and said I had gotten flustered because this was an area I hadn't been working on for a while. We went on with the discussion in a different direction and it went well enough that the ended up offering me a job (which I declined for unrelated reasons). The flub, like most failures, is less important than how you handle it.
The reality is that this is a career path that still has its share of oddballs and a lot more leeway is given to differing work styles than in other career paths. If you're not able to navigate this issue you should give serious consideration to the idea that you're having as much problem with your attitude about this as you are your challenges. Perhaps it's just a matter that you dislike this and you're not effectively communicating the way it challenges you well, leaving them feeling like you're resistant to helping them make sure you know what you say you do AND are unable to do it.
Some places simply aren't going to accommodate you. You can (counter-productively) think less of them for it, but perhaps there's something in their culture that considers this valuable. Quite frankly I've had a lot of very productive time in my career in front of a whiteboard with other coworkers brainstorming a problem. If your style precludes that it might be a deal-breaker for some places.
I'd honestly suggest you view this as your top professional development priority. The ability to work in this sort of style is valuable; what you're describing isn't THAT dissimilar to being asked to help a colleague who's stumped or solve a high-priority bug. If you're not as good as the average person at that then you're at a professional disadvantage. Practice some drill-type work with a friend till you are at least less anxious and self-defeating about it.
posted by phearlez at 12:08 PM on October 21, 2010 [3 favorites]
What you are reacting against is a particular style of interview that is unfortunately common. The interviewer asks you to perform tasks that aren't really germane to the work at hand. I'm a competent programmer but I don't come off very strong when interviewed like that either.
What I'm going to suggest isn't easy, but you need to take some ownership of the interview process a little. You are interviewing them too. Ask questions about what they do and ask them to describe a recent development/design issue they have been grappling with. When they start to discuss it, join in the discussion. Don't presume to have a silver bullet, but ask questions and make intelligent suggestions.
Do this well and they won't care if you didn't remember how to code the towers of Hanoi or write a depth-first search routine from scratch. If they still don't "get it" then take solace that it probably wasn't a good fit anyhow.
posted by dgran at 12:42 PM on October 21, 2010
What I'm going to suggest isn't easy, but you need to take some ownership of the interview process a little. You are interviewing them too. Ask questions about what they do and ask them to describe a recent development/design issue they have been grappling with. When they start to discuss it, join in the discussion. Don't presume to have a silver bullet, but ask questions and make intelligent suggestions.
Do this well and they won't care if you didn't remember how to code the towers of Hanoi or write a depth-first search routine from scratch. If they still don't "get it" then take solace that it probably wasn't a good fit anyhow.
posted by dgran at 12:42 PM on October 21, 2010
coelacanth!: "These types of interviews are antithetical to my entire working style. I'm not somebody who does well under extreme pressure."
It sounds like the major problem you have is performance anxiety, and perhaps a bit of contempt for hard problems. There are programmers who have to deal with cycles in linked lists; they write high performance garbage collectors. But this sort of systems work is rare. I think the tough questions come in from people who wish they had that kind of job, from organizations that want to persuade high caliber programmers they have interesting problems, and from a general theory that such people are more productive. But understanding mark-and-sweep collectors is especially important if you're not working in a garbage collected language, so there's some validity to asking people to present algorithms.
For the anxiety thing, you might try a few things. Mock interviews, so that you're comfortable with the format and situation. It may take a lot of them to acclimate. Also study a few of those "questions interviewers ask" books, and problem sets from college textbooks (you kept them, right?). But even if you're well-rehearsed, the consequences and raised stakes of a real interview will push through.
One thing I do to reduce anxiety is to spend a moment reminding myself my basic needs are met. In high school, I took a lot of college level classes, and they dumped a lot of homework on me. It got a little stressful trying to remember everything I needed to complete (especially as I rarely did so), so I adopted a philosophy that as long as I don't forget the wallet or the the lunch card it contains, I'll be fine. I might not have finished reading chapters 10-18 of Wuthering Heights, but at least I won't starve. Similarly, in college I hid a 2 dollar bill in my wallet, that was for emergencies. In my mind, I'd always have money for a gallon of gas, or a bite to eat or a phone call. I've added a zero onto that, now that I can afford such peace of mind. So try to build a safety net into interview process. Having a job already is a great way, but if that's not the case, make sure you apply for multiple places, and find a viable worst case alternative employer.
Two other ideas come to mind. Try locating a community college class in typing skills if you really have a problem typing while other people watch. Also try entering some tournaments. Poker, MtG, guitar hero, soccer, ping pong, whatever you might do as a hobby. They might be a good way to learn how to build a zen-like focus on the problem at hand, rather than a chain of consequences, in a fairly consequence free environment.
posted by pwnguin at 1:12 PM on October 21, 2010 [1 favorite]
It sounds like the major problem you have is performance anxiety, and perhaps a bit of contempt for hard problems. There are programmers who have to deal with cycles in linked lists; they write high performance garbage collectors. But this sort of systems work is rare. I think the tough questions come in from people who wish they had that kind of job, from organizations that want to persuade high caliber programmers they have interesting problems, and from a general theory that such people are more productive. But understanding mark-and-sweep collectors is especially important if you're not working in a garbage collected language, so there's some validity to asking people to present algorithms.
For the anxiety thing, you might try a few things. Mock interviews, so that you're comfortable with the format and situation. It may take a lot of them to acclimate. Also study a few of those "questions interviewers ask" books, and problem sets from college textbooks (you kept them, right?). But even if you're well-rehearsed, the consequences and raised stakes of a real interview will push through.
One thing I do to reduce anxiety is to spend a moment reminding myself my basic needs are met. In high school, I took a lot of college level classes, and they dumped a lot of homework on me. It got a little stressful trying to remember everything I needed to complete (especially as I rarely did so), so I adopted a philosophy that as long as I don't forget the wallet or the the lunch card it contains, I'll be fine. I might not have finished reading chapters 10-18 of Wuthering Heights, but at least I won't starve. Similarly, in college I hid a 2 dollar bill in my wallet, that was for emergencies. In my mind, I'd always have money for a gallon of gas, or a bite to eat or a phone call. I've added a zero onto that, now that I can afford such peace of mind. So try to build a safety net into interview process. Having a job already is a great way, but if that's not the case, make sure you apply for multiple places, and find a viable worst case alternative employer.
Two other ideas come to mind. Try locating a community college class in typing skills if you really have a problem typing while other people watch. Also try entering some tournaments. Poker, MtG, guitar hero, soccer, ping pong, whatever you might do as a hobby. They might be a good way to learn how to build a zen-like focus on the problem at hand, rather than a chain of consequences, in a fairly consequence free environment.
posted by pwnguin at 1:12 PM on October 21, 2010 [1 favorite]
I could complain forever about how unfair and ridiculous this situation is -- where exactly is the research
Some people walk into interviews for programming positions and they can't do anything. They can't solve any programming problem. The can't talk intelligently about any algorithm. They can't write any code in the languages they say they know. If you hire one of these people they are an albatross and a morale-killer. I've worked with several before my company got smart and started asking extremely basic and simple concrete questions like the ones you're complaining about.
These questions aren't gotchas. They are trying to make sure that you're not that person. If you are not that person (as you say you're not) and you have some mental block that makes you appear that you are that person, then you need to fix that by practicing, studying, therapy, or whatever. You can't fix it by whining or complaining.
It's neither unfair nor ridiculous for an interviewer to ask you to demonstrate that you're competent. References and transcripts and resumes lie. Ask anybody who hires programmers.
posted by fritley at 1:18 PM on October 21, 2010 [4 favorites]
Some people walk into interviews for programming positions and they can't do anything. They can't solve any programming problem. The can't talk intelligently about any algorithm. They can't write any code in the languages they say they know. If you hire one of these people they are an albatross and a morale-killer. I've worked with several before my company got smart and started asking extremely basic and simple concrete questions like the ones you're complaining about.
These questions aren't gotchas. They are trying to make sure that you're not that person. If you are not that person (as you say you're not) and you have some mental block that makes you appear that you are that person, then you need to fix that by practicing, studying, therapy, or whatever. You can't fix it by whining or complaining.
It's neither unfair nor ridiculous for an interviewer to ask you to demonstrate that you're competent. References and transcripts and resumes lie. Ask anybody who hires programmers.
posted by fritley at 1:18 PM on October 21, 2010 [4 favorites]
Well, there are two sorts of these kind of questions and I think they're quite different. The sort of "gotchas" or "brain teasers" that drjimmy11 refers to are indeed fairly worthless, and many companies that used to use them have phased them out (these used to be famously associated with Microsoft, but by the time I left there in 2008 we were advised not to use them, although I'm sure some still do).
But the kind you're actually describing -- algorithms, pseudo-code solutions to problems, etc -- well, while I don't know of research, I can say that the places I've worked at where we use these questions (Microsoft and Google) end up with pretty good employees. Now, I'm quite convinced that we do let good candidates go by due to this, but we also hire very, very few bad programmers (especially at Google, IMO). So it's partially an 'err on the side of not hiring' sort of thing (which is why we never have enough engineers! But as the Mythical Man Month and just experience can tell you, a bad programmer can be worse than no programmer).
OK, so how to get better at them? Well, if you know you're going to be doing some interviews, pick up a good book on data structures and study it. This will help with the vast majority of the problems that are of the type you might not otherwise do day to day (detect a loop in a linked list, sort this tree, etc). These come up all the time. The one I use is from my college days: "Data Structures Using C" by Tenenbaum et al.
Practice writing simple programs without a computer. Most places are OK with pseudo-code, but it might also be good to pick a common language (maybe Java or C++) and get comfortable writing it on paper without an editor, without auto-completion or any other tools that are helpful but not available during an interview. This should also make it easier to do so on an unfamiliar editor if they give you a computer (writing code without Emacs is always more of a challenge for me b/c I waste time unlearning things).
[And I've had to implement linked lists twice as a professional programmer, when working in areas without good libraries. In the early days Java had no linked lists! (just arraylist).
posted by wildcrdj at 1:29 PM on October 21, 2010
But the kind you're actually describing -- algorithms, pseudo-code solutions to problems, etc -- well, while I don't know of research, I can say that the places I've worked at where we use these questions (Microsoft and Google) end up with pretty good employees. Now, I'm quite convinced that we do let good candidates go by due to this, but we also hire very, very few bad programmers (especially at Google, IMO). So it's partially an 'err on the side of not hiring' sort of thing (which is why we never have enough engineers! But as the Mythical Man Month and just experience can tell you, a bad programmer can be worse than no programmer).
OK, so how to get better at them? Well, if you know you're going to be doing some interviews, pick up a good book on data structures and study it. This will help with the vast majority of the problems that are of the type you might not otherwise do day to day (detect a loop in a linked list, sort this tree, etc). These come up all the time. The one I use is from my college days: "Data Structures Using C" by Tenenbaum et al.
Practice writing simple programs without a computer. Most places are OK with pseudo-code, but it might also be good to pick a common language (maybe Java or C++) and get comfortable writing it on paper without an editor, without auto-completion or any other tools that are helpful but not available during an interview. This should also make it easier to do so on an unfamiliar editor if they give you a computer (writing code without Emacs is always more of a challenge for me b/c I waste time unlearning things).
[And I've had to implement linked lists twice as a professional programmer, when working in areas without good libraries. In the early days Java had no linked lists! (just arraylist).
posted by wildcrdj at 1:29 PM on October 21, 2010
Response by poster: RE contempt : y'all can quit it with the armchair psychology. Any contempt comes after the fact, from being turned down for jobs that I know I'd be good at. Pretty sure that in the interview itself, I'm basically just a nervous wreck.
I don't shy away from hard problems or dispute the importance of thoughtful whiteboard sessions. I just have a problem with job interviews. What happens in a job interview can affect everything in your life that comes after that. It's just not an ideal environment for deep thought, if you're me.
Surely you can understand that?
posted by coelacanth! at 1:35 PM on October 21, 2010
I don't shy away from hard problems or dispute the importance of thoughtful whiteboard sessions. I just have a problem with job interviews. What happens in a job interview can affect everything in your life that comes after that. It's just not an ideal environment for deep thought, if you're me.
Surely you can understand that?
posted by coelacanth! at 1:35 PM on October 21, 2010
coelacanth!: "What happens in a job interview can affect everything in your life that comes after that"
That right there is the problem. Your life is not at stake during an interview substantially more than any other moment. Performance reviews are based on on-the-job history, and can also affect future income, promotions and work assignments, yet I presume you're not a nervous wreck every day at work.
posted by pwnguin at 1:48 PM on October 21, 2010
That right there is the problem. Your life is not at stake during an interview substantially more than any other moment. Performance reviews are based on on-the-job history, and can also affect future income, promotions and work assignments, yet I presume you're not a nervous wreck every day at work.
posted by pwnguin at 1:48 PM on October 21, 2010
I found Programming Interviews Exposed surprisingly good on the subject. And googling "interview questions" along with "sql", "ruby", "web security", etc. is ofter fruitful.
As an interviewee, I usually do well with the whiteboard exercises in interviews. A couple of other times, I've bombed and my interviewers probably thought I was an idiot. It's not a perfect system, but as an interviewer, I wouldn't want to live without it.
posted by Zed at 2:04 PM on October 21, 2010
As an interviewee, I usually do well with the whiteboard exercises in interviews. A couple of other times, I've bombed and my interviewers probably thought I was an idiot. It's not a perfect system, but as an interviewer, I wouldn't want to live without it.
posted by Zed at 2:04 PM on October 21, 2010
Best answer: I don't have much advice about your situation, but I wanted to pop in and say I completely understand what you mean. I'm surprised so many people are trying giving you that armchair psychology treatment, because it is actually a very legitimate and unfortunate situation. Some people just do not work well thinking on the fly and under pressure, and need more time for reflection. It's a different thinking (and learning) style, and I wish people, including employers and teachers, would recognize this. I'm sure the method is still being used because it's an easy way to weed out a lot of bad programmers, and there are probably more than enough good ones that DO pass this test to merit a changing of the system.
Have you ever tried practicing with someone? I think that's the only way you'll improve. Either have someone give you these impromptu questions, or practice explaining your approach out loud (I think maybe a major reason why this flusters you is because you never had to work while someone is watching). Otherwise, (and this may be a long shot), can you explain your situation to potential employers prior to the interview, and for larger, more complex problems to solve at home? I've had some interviews that did that. Many interviewers probably will not want to go through this trouble, but I think if you present it the right way, it might be understandable. It shows that you are a seasoned programmer who knows your own working style (which is also compatible with the actual job description).
posted by lacedcoffee at 2:08 PM on October 21, 2010 [2 favorites]
Have you ever tried practicing with someone? I think that's the only way you'll improve. Either have someone give you these impromptu questions, or practice explaining your approach out loud (I think maybe a major reason why this flusters you is because you never had to work while someone is watching). Otherwise, (and this may be a long shot), can you explain your situation to potential employers prior to the interview, and for larger, more complex problems to solve at home? I've had some interviews that did that. Many interviewers probably will not want to go through this trouble, but I think if you present it the right way, it might be understandable. It shows that you are a seasoned programmer who knows your own working style (which is also compatible with the actual job description).
posted by lacedcoffee at 2:08 PM on October 21, 2010 [2 favorites]
Slightly different psychology-related thing: if you have extreme anxiety in these situations, consider seeing a therapist who does CBT (cognitive behavioral therapy). It's really really useful for anxiety issues and is specifically about countering particular fears/worries/etc. [I've struggled with anxiety issues myself]. Can't tell how much of it is that so feel free to dismiss, but if it's more that than the questions themselves it could be helpful.
posted by wildcrdj at 2:54 PM on October 21, 2010
posted by wildcrdj at 2:54 PM on October 21, 2010
I'm a systems guy, I've been doing this for 20+ years. I still have to solve undergraduate-level linked-list-type problems in my job. Are you sure you don't consider it beneath you to solve those kinds of problems?
Consider that the company has to decide whether or not to hire you based a small number of hour-long interviews. There is no alternative. People above have already pointed out that hiring the wrong person drags the whole team down, so of course they're going to be cautious. If you have a problem with high-pressure situations, you have to work on that. There are several excellent suggestions in the comments above.
And of course you can always start by telling them that you don't work well under pressure. Maybe they can give you a problem to work on at home, and then you can go in and discuss your solutions with the interviewers?
posted by phliar at 3:06 PM on October 21, 2010
Consider that the company has to decide whether or not to hire you based a small number of hour-long interviews. There is no alternative. People above have already pointed out that hiring the wrong person drags the whole team down, so of course they're going to be cautious. If you have a problem with high-pressure situations, you have to work on that. There are several excellent suggestions in the comments above.
And of course you can always start by telling them that you don't work well under pressure. Maybe they can give you a problem to work on at home, and then you can go in and discuss your solutions with the interviewers?
posted by phliar at 3:06 PM on October 21, 2010
An Anecdote: A buddy of mine was in an interview and they asked him the two glass balls brainteaser. He was able to give a correct answer immediately - because he'd seen the brainteaser before and already knew the answer.
If you think brainteaser questions are likely, read some brainteaser books and websites, and with a bit of luck they'll ask you a question you already know the answer to.
When was the last time your boss actually asked you to detect a cycle in a linked list? [...] where exactly is the research which proves that good engineers are all skilled at completing whiteboard problems in job interviews?
Well, that specific question would actually check a few different things:
1. Are you familiar with the concept that objects can contain references to other objects?
2. Are you familiar with the concept of a linked list?
3. Are you familiar with the concept of recursion (or of stacks)?
Now, maybe you're thinking "Well of course I know what recursion is, I'm no n00b" - that's what the interviewer is trying to be sure of. I've seen people who didn't know the basics well graduate from top schools because their grandfather was a professor there - so holding academic qualifications doesn't always mean you have this basic knowledge (though in most cases it does).
It's unlikely in the job you'll be called upon to actually detect a cycle in a linked list, but there are plenty of programming positions where you'll need the knowledge that the question gives you a chance to prove you have.
If you have trouble proving you have this knowledge 'on the fly', you could do the same thing as my friend with the brainteaser - try to know solutions to common basic problems well enough that you can work them out from memory. And if the worst comes to the worst, ask the interviewers if you can have some time alone to gather your thoughts as you don't work well under pressure.
That or carry a data structures textbook in your briefcase and if they stump you with a question just take it out and look the answer up :-)
posted by Mike1024 at 3:09 PM on October 21, 2010
If you think brainteaser questions are likely, read some brainteaser books and websites, and with a bit of luck they'll ask you a question you already know the answer to.
When was the last time your boss actually asked you to detect a cycle in a linked list? [...] where exactly is the research which proves that good engineers are all skilled at completing whiteboard problems in job interviews?
Well, that specific question would actually check a few different things:
1. Are you familiar with the concept that objects can contain references to other objects?
2. Are you familiar with the concept of a linked list?
3. Are you familiar with the concept of recursion (or of stacks)?
Now, maybe you're thinking "Well of course I know what recursion is, I'm no n00b" - that's what the interviewer is trying to be sure of. I've seen people who didn't know the basics well graduate from top schools because their grandfather was a professor there - so holding academic qualifications doesn't always mean you have this basic knowledge (though in most cases it does).
It's unlikely in the job you'll be called upon to actually detect a cycle in a linked list, but there are plenty of programming positions where you'll need the knowledge that the question gives you a chance to prove you have.
If you have trouble proving you have this knowledge 'on the fly', you could do the same thing as my friend with the brainteaser - try to know solutions to common basic problems well enough that you can work them out from memory. And if the worst comes to the worst, ask the interviewers if you can have some time alone to gather your thoughts as you don't work well under pressure.
That or carry a data structures textbook in your briefcase and if they stump you with a question just take it out and look the answer up :-)
posted by Mike1024 at 3:09 PM on October 21, 2010
I've never had a boss asked me to detect a cycle in a linked list.
I have, however, been on site during a customer's launch of a product responsible for hundreds of millions of dollars of revenue for them. That launch was delayed because an undetected cycle in recursively linked user entered data kept a certain process from ever returning, which kept the site from every coming up. People almost lost their jobs over that one. In that case, someone's boss definitely should have asked them to detect that cycle.
OP - and I say this as someone that also is kinda bad at these types of interviews and agrees with you that they're not necessarily the best way of finding good developers - you need to own this stuff cold. Much of the industry works experimentally - iterating and bumbling along until finding something that works. Unfortunately, that approach takes time, and time is money. If you can't convince your interviewer that you are a stone cold algorithmic assassin, that you don't need to debug or experiment until much later in the process, the hard truth is you simply aren't worth the risk to them. It is, simply, the barrier to entry.
The answer is practice. Most developers are terrible interviewers. That's something you just need to deal with. Meet them on their terms, exceed the expectation, then do what you really want to do. There's only so many ways people can dress up the canonical interviewing problems - it's on you to own those problems backwards and forwards.
Note that there are technology companies that forgo traditional technical interviews for projects during the interview process. These companies are rare, and you should be careful what you wish for - if you had to do a big, multi-hour (sometimes week long) project for every company at which you were interviewing, you could easily ask this question again, longing for the time-efficiency of the traditional tech interview.
I feel for you, and wish you the best of luck - but you've got some work ahead of you.
posted by NoRelationToLea at 3:45 PM on October 21, 2010
I have, however, been on site during a customer's launch of a product responsible for hundreds of millions of dollars of revenue for them. That launch was delayed because an undetected cycle in recursively linked user entered data kept a certain process from ever returning, which kept the site from every coming up. People almost lost their jobs over that one. In that case, someone's boss definitely should have asked them to detect that cycle.
OP - and I say this as someone that also is kinda bad at these types of interviews and agrees with you that they're not necessarily the best way of finding good developers - you need to own this stuff cold. Much of the industry works experimentally - iterating and bumbling along until finding something that works. Unfortunately, that approach takes time, and time is money. If you can't convince your interviewer that you are a stone cold algorithmic assassin, that you don't need to debug or experiment until much later in the process, the hard truth is you simply aren't worth the risk to them. It is, simply, the barrier to entry.
The answer is practice. Most developers are terrible interviewers. That's something you just need to deal with. Meet them on their terms, exceed the expectation, then do what you really want to do. There's only so many ways people can dress up the canonical interviewing problems - it's on you to own those problems backwards and forwards.
Note that there are technology companies that forgo traditional technical interviews for projects during the interview process. These companies are rare, and you should be careful what you wish for - if you had to do a big, multi-hour (sometimes week long) project for every company at which you were interviewing, you could easily ask this question again, longing for the time-efficiency of the traditional tech interview.
I feel for you, and wish you the best of luck - but you've got some work ahead of you.
posted by NoRelationToLea at 3:45 PM on October 21, 2010
Response by poster: You know, every time I post a question to AskMe, I'm reminded of how important it is to word my question precisely, without any unnecessary detail. I feel like we spent a lot of time here talking about how worthwhile programming tests are, and what it says about my character that I'm not good at them. This wasn't necessary or even helpful. I've already resigned myself to the fact that these tests are a fact of life. Fortunately, a lot of people in this thread have given me useful, actionable advice on how to get better at them, and I thank you for these answers, and encourage you to keep them coming.
posted by coelacanth! at 4:36 PM on October 21, 2010
posted by coelacanth! at 4:36 PM on October 21, 2010
I interview candidates roughly three days per week and ask a variety of questions ranging from high-level problem organization, big-O, synchronization primitives and data structures, down to OS topics like how page faults are handled and what happens during a network interrupt through to delivery of data to a user process. I'm not looking for exact answers to all of my questions, but a certain level of familiarity is appreciated.
However, the assumption that you never need to implement a linked list because there are lists in the standard library isn't accurate in my experience. The built in lists are great if you have simple requirements, but what if you want lockless concurrency? What if you want items to appear on multiple lists? What if you want to be able to traverse the hash table entries in the order in which they were added? The STL and Java collections do not anticipate every possible application, and as such are only the building blocks for many impromptu "linked lists" of pointers or references to objects.
So a candidate who isn't comfortable drawing box and arrow diagrams to show how delete from a doubly linked list will not get an "inclined to hire", no matter how many wiz-bang libraries they know how to use.
posted by autopilot at 4:47 PM on October 21, 2010 [1 favorite]
However, the assumption that you never need to implement a linked list because there are lists in the standard library isn't accurate in my experience. The built in lists are great if you have simple requirements, but what if you want lockless concurrency? What if you want items to appear on multiple lists? What if you want to be able to traverse the hash table entries in the order in which they were added? The STL and Java collections do not anticipate every possible application, and as such are only the building blocks for many impromptu "linked lists" of pointers or references to objects.
So a candidate who isn't comfortable drawing box and arrow diagrams to show how delete from a doubly linked list will not get an "inclined to hire", no matter how many wiz-bang libraries they know how to use.
posted by autopilot at 4:47 PM on October 21, 2010 [1 favorite]
I feel like we spent a lot of time here talking about how worthwhile programming tests are[...] This wasn't necessary or even helpful.
To be fair, two of the three questions in your original post were about how worthwhile programming tests are. It wasn't obvious that they were rhetorical.
I'm glad some of the answers have been useful to you, and hope you weren't too distracted by the ones that weren't.
posted by dfan at 6:16 PM on October 21, 2010 [2 favorites]
To be fair, two of the three questions in your original post were about how worthwhile programming tests are. It wasn't obvious that they were rhetorical.
I'm glad some of the answers have been useful to you, and hope you weren't too distracted by the ones that weren't.
posted by dfan at 6:16 PM on October 21, 2010 [2 favorites]
Best answer: This blog post by Steve Yegge has a lot of good suggestions. (Warning: He's very verbose, so skim and take the good stuff.)
But some ideas in that post (and comments) are simple and useful, like: practice answering questions on your own whiteboard ahead of time to get comfortable with it and learn whiteboard space management, bring your own whiteboard markers. If there's going to be a coding section of the interview, bring your own laptop and ask if you can use that.
posted by losvedir at 7:44 PM on October 21, 2010 [2 favorites]
But some ideas in that post (and comments) are simple and useful, like: practice answering questions on your own whiteboard ahead of time to get comfortable with it and learn whiteboard space management, bring your own whiteboard markers. If there's going to be a coding section of the interview, bring your own laptop and ask if you can use that.
posted by losvedir at 7:44 PM on October 21, 2010 [2 favorites]
I've already resigned myself to the fact that these tests are a fact of life.
I think that people might be trying to say that adjusting your attitude from resignation (plus barely hidden contempt) to something more positive, with regard to this portion of the interview, might be as important as figuring out how to nail the answers. I know I'd rather have a programmer with average technical skills who was a great cultural fit on my team than a hot-shit curmudgeon, any day.
posted by Kwine at 7:56 PM on October 21, 2010 [1 favorite]
I think that people might be trying to say that adjusting your attitude from resignation (plus barely hidden contempt) to something more positive, with regard to this portion of the interview, might be as important as figuring out how to nail the answers. I know I'd rather have a programmer with average technical skills who was a great cultural fit on my team than a hot-shit curmudgeon, any day.
posted by Kwine at 7:56 PM on October 21, 2010 [1 favorite]
If you'd like, I'd be willing to do a practice interview and give you more specific feedback. Just let me know.
posted by jeffamaphone at 10:15 PM on October 21, 2010 [3 favorites]
posted by jeffamaphone at 10:15 PM on October 21, 2010 [3 favorites]
Best answer: I do best when I can take a moment to think about a problem, walk away from my computer for a while, get a snack, and maybe sit in the corner with a pad and pen for a while.
You can ask "Do you mind if I sit in the corner with a pad and pen for a while?". I'd rather hire someone who takes time to think about a problem than someone who dives right into solving it.
You can also say something like "Well, linked list algorithms aren't something I've worked with recently. So, if this came up in a job situation I'd definitely sit down and do some research on the subject rather than trying to reinvent the wheel."
If you are stuck in a situation where you have to think out loud, remember you don't have to get it right first time. You can go completely up a wrong alley, so long as you notice, you make it clear that you understand why it's wrong, and you go and try something else.
If you think of a way to solve the problem and you KNOW it's wrong, you can still use it. "Well, one option you might think of would be to X, but in fact that wouldn't work because Y". "A simplistic approach to the problem would be X, but it's not very efficient, so unless we were working on really tiny datasets we'd probably want to do something a bit more complex".
Here you're still demonstrating competence even though you aren't answering the question.
Finally, I've interviewed for quite a few jobs now and never yet had to solve a puzzle or write code on a whiteboard. My current employer paid me to write them a code sample (at home), before they would even interview me. Previous employers have used written tests, in which you have say half an hour on your own to answer some questions about the provided code snippets. So, if you do a lot of interviews you'll probably hit some that are better designed for you to do well.
posted by emilyw at 4:12 AM on October 22, 2010 [1 favorite]
You can ask "Do you mind if I sit in the corner with a pad and pen for a while?". I'd rather hire someone who takes time to think about a problem than someone who dives right into solving it.
You can also say something like "Well, linked list algorithms aren't something I've worked with recently. So, if this came up in a job situation I'd definitely sit down and do some research on the subject rather than trying to reinvent the wheel."
If you are stuck in a situation where you have to think out loud, remember you don't have to get it right first time. You can go completely up a wrong alley, so long as you notice, you make it clear that you understand why it's wrong, and you go and try something else.
If you think of a way to solve the problem and you KNOW it's wrong, you can still use it. "Well, one option you might think of would be to X, but in fact that wouldn't work because Y". "A simplistic approach to the problem would be X, but it's not very efficient, so unless we were working on really tiny datasets we'd probably want to do something a bit more complex".
Here you're still demonstrating competence even though you aren't answering the question.
Finally, I've interviewed for quite a few jobs now and never yet had to solve a puzzle or write code on a whiteboard. My current employer paid me to write them a code sample (at home), before they would even interview me. Previous employers have used written tests, in which you have say half an hour on your own to answer some questions about the provided code snippets. So, if you do a lot of interviews you'll probably hit some that are better designed for you to do well.
posted by emilyw at 4:12 AM on October 22, 2010 [1 favorite]
I want to preface that I don't usually ask interviewees to write code. But, every good candidate must display some understanding and enthusiasm for the craft of programming and software development.
Software development is a difficult job, and it justifiably pays well. And well, because it pays so finely, it also tends to attract a lot of hucksters. More time than I'd like to admit seems taken up dealing with hucksters. (Ok, I'm sure it's not as bad as it seems.)
Put yourself in the shoes of someone managing the development of a world-class product. The number one success factor for that product is how many awesome developers that are on staff. Seriously. Awesome developers are ones who can code, can read code, can test, can work with 'users', develop requirements, can set up infrastructure, can deploy. They are the hackers that play and experiment and have a lot of pride in their code and in advancing the field.
Skill and knowledge will only get you so far in software development. Luckily there are plenty of jobs in IT for those with skill and knowledge and experience, but lacking in talent and enthusiasm and diligence. IT pays well; it just doesn't have a lot of interesting career paths. You can make good loot in IT, yes, but you won't be developing awesome products. Sorry.
And, yes, you must know how a linked list works. You must know why you would use one over, say, an array or a hashtable. You should be able to at least explain how it works and why. I don't care if you implement one. You should be able to talk about it. Otherwise, look into jobs in IT.
posted by TheOtherSide at 7:05 AM on October 22, 2010 [2 favorites]
Software development is a difficult job, and it justifiably pays well. And well, because it pays so finely, it also tends to attract a lot of hucksters. More time than I'd like to admit seems taken up dealing with hucksters. (Ok, I'm sure it's not as bad as it seems.)
Put yourself in the shoes of someone managing the development of a world-class product. The number one success factor for that product is how many awesome developers that are on staff. Seriously. Awesome developers are ones who can code, can read code, can test, can work with 'users', develop requirements, can set up infrastructure, can deploy. They are the hackers that play and experiment and have a lot of pride in their code and in advancing the field.
Skill and knowledge will only get you so far in software development. Luckily there are plenty of jobs in IT for those with skill and knowledge and experience, but lacking in talent and enthusiasm and diligence. IT pays well; it just doesn't have a lot of interesting career paths. You can make good loot in IT, yes, but you won't be developing awesome products. Sorry.
And, yes, you must know how a linked list works. You must know why you would use one over, say, an array or a hashtable. You should be able to at least explain how it works and why. I don't care if you implement one. You should be able to talk about it. Otherwise, look into jobs in IT.
posted by TheOtherSide at 7:05 AM on October 22, 2010 [2 favorites]
A friend of mine has made a career out of helping people with the whiteboard programming interview. Check out http://www.careercup.com/. She has a book, which I've heard is good, as well as a bunch of on-line resources.
posted by jeffamaphone at 7:29 PM on October 23, 2010 [1 favorite]
posted by jeffamaphone at 7:29 PM on October 23, 2010 [1 favorite]
Best answer:
Part of this was a lack of confidence, and it got a bit better once I had more exposure to peers in general and realised I was at least as competent as most of them. Looking at your question, this is probably not an issue for you -- you seem pretty secure in your self-knowledge about your ability.
But the bigger part was that programming was always a solo activity for me. Doing it in front of, or in collaboration with, another programmer made all my normal, perfectly acceptable behaviours (e.g. pausing to think for a minute, having to look up a really everyday API method that slipped my recall that second, repeating the same typo three times) feel like glaring indictments of unbelievable incompetence.
The only way I found to fix this was to simply force myself to be in those situations. I've done some pair-programming for a while through work, but more often I put myself in casual for-fun coding situations with other geeks (e.g. working on open source projects, at conferences, etc.). If you've not programmed with someone before, it feels very weird at first, but it fairly quickly becomes at least bearable. The key trick is to make yourself talk out loud about what you're thinking, and to not be afraid to ask for the other person's opinion/knowledge when you're not feeling sure about something.
Also, the experience of seeing someone else take the driving seat and make all the same kinds of apparently-boneheaded 'mistakes' that you're worried about making is pretty reassuring.
Obviously it's not exactly the same behaviour you'd apply in an interview situation, but getting accustomed to being in that position in a much more low-key, no-pressure context is a really good way to get used to working 'on display'.
posted by chrismear at 8:38 AM on October 24, 2010 [2 favorites]
These types of interviews are antithetical to my entire working style. I'm not somebody who does well under extreme pressure. I can't even type when somebody is watching me. I do best when I can take a moment to think about a problem, walk away from my computer for a while, get a snack, and maybe sit in the corner with a pad and pen for a while. Sometimes I get my best inspiration when walking home from work.I think I know exactly the 'pressure to perform', 'forced to think on-the-spot' feeling that you're describing here. I started out my career as one of those self-taught, lone-guman sort of coders (not suggesting that this is you, but hear me out), and subsequently felt very nervous about doing programming in front of anyone else who might actually understand what I was doing.
Part of this was a lack of confidence, and it got a bit better once I had more exposure to peers in general and realised I was at least as competent as most of them. Looking at your question, this is probably not an issue for you -- you seem pretty secure in your self-knowledge about your ability.
But the bigger part was that programming was always a solo activity for me. Doing it in front of, or in collaboration with, another programmer made all my normal, perfectly acceptable behaviours (e.g. pausing to think for a minute, having to look up a really everyday API method that slipped my recall that second, repeating the same typo three times) feel like glaring indictments of unbelievable incompetence.
The only way I found to fix this was to simply force myself to be in those situations. I've done some pair-programming for a while through work, but more often I put myself in casual for-fun coding situations with other geeks (e.g. working on open source projects, at conferences, etc.). If you've not programmed with someone before, it feels very weird at first, but it fairly quickly becomes at least bearable. The key trick is to make yourself talk out loud about what you're thinking, and to not be afraid to ask for the other person's opinion/knowledge when you're not feeling sure about something.
Also, the experience of seeing someone else take the driving seat and make all the same kinds of apparently-boneheaded 'mistakes' that you're worried about making is pretty reassuring.
Obviously it's not exactly the same behaviour you'd apply in an interview situation, but getting accustomed to being in that position in a much more low-key, no-pressure context is a really good way to get used to working 'on display'.
posted by chrismear at 8:38 AM on October 24, 2010 [2 favorites]
Response by poster: You know, looking back on this thread, I really do wish I had left out some of the more emotional stuff. The fact is, I'd recently been turned down for a couple positions that I knew I'd be perfect for, and was feeling rubbed raw by an interview process that I've never been very good at.
I mean, I understand the whole "false positives are worse than false negatives," but that can be really hurtful when you're one of the false negatives. You get to feeling pretty worthless after a while, and you start to doubt your own skills, even though you know you're a good engineer and you've produced quality work.
I wish people hadn't rushed to make judgments about my character or my skills, but whatever, this is AskMe, that happens here sometimes. I think maybe we have some people in this thread who were really strong believers in this kind of interview, and maybe they were offended by some of my phrasing. Anyway, there was a lot of good, really good, really solid advice here, and also a number of people who were sympathetic to my plight ;)
I've taken your advice to heart, and it will help me in my next round of interviewing.
Thanks, AskMe!
posted by coelacanth! at 10:44 PM on October 28, 2010
I mean, I understand the whole "false positives are worse than false negatives," but that can be really hurtful when you're one of the false negatives. You get to feeling pretty worthless after a while, and you start to doubt your own skills, even though you know you're a good engineer and you've produced quality work.
I wish people hadn't rushed to make judgments about my character or my skills, but whatever, this is AskMe, that happens here sometimes. I think maybe we have some people in this thread who were really strong believers in this kind of interview, and maybe they were offended by some of my phrasing. Anyway, there was a lot of good, really good, really solid advice here, and also a number of people who were sympathetic to my plight ;)
I've taken your advice to heart, and it will help me in my next round of interviewing.
Thanks, AskMe!
posted by coelacanth! at 10:44 PM on October 28, 2010
« Older The strong, silent type does not compute. | Is there an inn with all-glass ceilings (for... Newer »
This thread is closed to new comments.
posted by griphus at 10:51 AM on October 21, 2010 [1 favorite]