10 ms·

Today's Coding Interview Game

132 points by grayhairmomma 16y ago

jchonphoenix 16y ago
I understand where the author is coming from because many interviews questions are unreasonable and test absolutely nothing. However, if someone couldn't code a linked list on a whiteboard, I'd be severely worried. Same goes for a binary tree. If you know what a linked list or binary tree is, you should have no issues figuring out how to represent them with code in 10 minutes. The other trickier problems are there to test problem solving ability, which I believe is a valid thing to test. I think the reason for this style of interview is that companies are afraid of false negatives. They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified. Additionally, swearing all over the place never helps your case...
- tkahn6 16y ago
  I think you mean that companies fear false positives which, in turn, causes a high false negative rate.
- tgflynn 16y ago
  They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified. And then they complain that they can't hire developers. I don't think these types of interviews are well conceived. Human memory is extremely context dependent and a whiteboard/interview type situation doesn't establish the right context for someone who's accustomed to working alone with a mouse, keyboard and compiler. Also the more knowledge you have the more difficult it becomes to retrieve that knowledge quickly. So these types of interviews might be good at selecting people who know all about linked lists and binary trees but not much else.
  - jchonphoenix 16y ago
    I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?
    - jonafato 16y ago
      I'll agree with this on one condition: don't hold syntax errors against me. I interviewed for a position about eight months ago. I was rusty with my C (had been doing more java and python around that time), and put "int i = 0" in a for loop on a white board and seemingly had it counted against me. This kind of thing, along with things like missed semicolons, should be ignored by interviewers. Not only is it a simple fix, it also says nothing about the logic in the code.
      - nostrademons 16y ago
        That's even legal syntax in C99.
      - aplusbi 16y ago
        What makes you think it was held against you? Most programmers can be kind of OCD about code and would want to point out that kind of error, whether they thought it was relevant to your abilities or not.
      - matwood 16y ago
        Unless I've needed a specific language, like SQL for example, anytime I've asked a candidate to code on the whiteboard pseudocode has always been fine.
      - thornkin 16y ago
        Assuming you mean for (int i = 0; ; ) {} that is legal syntax. Perhaps I'm dull, but what is the error?
        lunaru 16y ago
        I think the point was that in C(89) you need to declare all variables at the beginning of the scope block.
    - j_baker 16y ago
      Can't code one on a whiteboard != can't code one
  - chollida1 16y ago
    > Also the more knowledge you have the more difficult it becomes to retrieve that knowledge quickly. I've never heard this about the human brain before. I'm not saying you're wrong, because I don't know, but statements of fact like this deserve a good reference. Do you have anything to back up this assertion of fact?
    - deleted 16y ago
      [deleted]
    - tgflynn 16y ago
      Actually I intended that statement more as an hypothesis/conjecture than as a statement of fact. It does agree with my own introspective observations. If I have seen many different approaches to solving a certain class of problems and I'm presented with a problem which shares features of that class I'm going to have to spend time trying to figure out which of those approaches is most appropriate to the problem and circumstances. If I've only ever seen one approach to that type of problem then the initial phase of the solution space search is simplified and I can immediately begin to try to adapt that one approach to the particular problem. An example might be solving a max flow problem. There are graph based and linear programming based approaches to that problem. If you're only aware of the graph based approaches then you won't lose time trying to figure out which of the two approaches is most appropriate for the problem you're facing. Of course if you're confronted with hard real world problems then having more knowledge increases the likelihood that you will be able to find a solution. That may not apply however to artificial interview questions in a time constrained context.
- rsl7 16y ago
  Code on the whiteboard is counterproductive at best. Let's hook up your laptop to the projector so I can get a glimpse of how you interact with your computer. I learn more about you by seeing your relationship with your text editor, how you look up information you can't remember, etc. Not watching you sweat with a marker in your hand.
  - phillijw 16y ago
    I agree. I can type a good chunk of code in a few seconds and have it nicely placed in my head to think about other things. On a whiteboard it may take me a minute just to write something out and by that time I've forgotten what I was doing.
  - ssp 16y ago
    I learn more about you by seeing your relationship with your text editor Are you sure you are not just learning whether the candidate is superficially similar to you?
    - weaksauce 16y ago
      well a programmer that is coding a linked list in c/c++ probably(definitely) should know the pointer semantics. If they are looking that up then they should be a pass unless you are looking for a really junior programmer. Now if you are asking them to connect to a db and update a record with a stored procedure and they looked up the syntax for a db connection to a mysql database then you know they are fairly proficient at that type of coding but just forgot the exact syntax of a db connection because it's not something done every day whereas any c programmer worth their salt should know basic pointer rules.
      - Retric 16y ago
        Any language I have not used for a while get’s tossed out of the buffer, and I need to lookup even the most basic of syntax when I start coding in it. Once I get going I can easily recall if it’s *, &, ->, or ^ but at the start I really do need a refresher. PS: Oddly enough, I have little issue working on a multi language programs, it's just I think in terms of pointer not C pointer.
- grayhairmomma 16y ago
  Bill Maher is my hero. Sorry if my swearing offended you, but it's just who I am.
KevinMS 16y ago
Its because credentialism has permeated the software business recently. Credentialists love tests, its how they got their credentials, and if they don't keep believing in tests over real world performance, they will have to re-examine the true worth of their credentials.
- Dilpil 16y ago
  It is the opposite. Interviewers are coming to realize credentials, be they Microsoft certs or computer science degrees, are not great indicators of software engineering aptitude. The more you believe in the accuracy of credentials, the less you would want to ask coding questions in an interview. Better to simply examine resumes for the appropriate certifications and then ask fit questions. If on the other hand, you believe nothing but on the spot coding demonstrations can prove a candidates abilities, you would do exactly what these interviewers are doing. Perhaps these tests are not the optimal tests, but they sure beat credentialism.
nowarninglabel 16y ago
Coding general solutions should be par for the course. I agree that some interviewers are coming up with contrived examples. But of the 6 data points I have now from hiring people, those who could code on the white board turned out to be good employees (4 of them) and those who could not turned out to be a vast waste of time (2 of them). As jconphoenix was alluding to, I would have rather ended up rejecting more of the qualified applicants than ending up with a time-wasting employee.
- j_baker 16y ago
  This sounds like risk aversion to me. People place twice as much emphasis on avoiding loss than they place on gaining something equivalent (even though the end result is the same). If you look at it in this light, then of course the good ones weren't as good as the bad ones were bad. The end result is that you end up with employees who definitely don't suck, but aren't really great either because you spent all of your time avoiding bad programmers and not enough finding good ones.
  - wtracy 16y ago
    Given how hard it can be to fire people, I don't blame managers for being risk averse.
- hackinthebochs 16y ago
  I don't really understand this mentality. Is is really that hard to get rid of the charlatans that slip through after the fact? Just monitor them fairly closely (but secretly) for a couple of weeks. Have some sort of object measure of performance for that time period. If they don't pass muster, get rid of them. This seems like a better method than spending 6 months to fill a couple of positions.
  - hc5 16y ago
    Training and getting someone up to speed for a few weeks, then getting rid of them (if it doesn't work out) wastes more time and money than spending several months to fill the position with the right person. Laying people off for performance is hard to quantify, not to mention I certainly wouldn't want to be working for a company who is secretly monitoring new hires' performance.
mikeklaas 16y ago
If I found this article by a potential applicant, I'd be much less likely to hire them. Besides the obvious red flag of the sentiment why should I have to code at a programming interview, the knowledge that they have been rejected by many other companies would make me worry.
- AndrewMoffat 16y ago
  I understand where you're coming from, and yes, most people would probably do that, but personally, if I found a article by a potential candidate expressing their frustration with not being able to adequately convey their skillets and abilities, I'd make an extra effort to reach out and evaluate them more carefully so that I don't miss what they have to offer. Maybe you haven't been in their shoes, so I can't blame you for your approach, but the phrase "diamond in the rough" exists for a reason.
- alain94040 16y ago
  I didn't have that impression (and I have been a hiring manager for 10 years+). It gave me the impression of someone senior. What I would then try to determine in the interview is whether that person has grown to become a strong developer, or rather has reached a level of incompetency. But I wouldn't pass judgment either way based on that blog post.
- rimantas 16y ago
  If the job is to code on whiteboard: definitely don't hire.
- grayhairmomma 16y ago
  Sorry you feel that way. Several hiring managers from top companies feel differently than you though, because they have contacted me directly and even asked me to apply at their companies. Does this mean that I've got an instant job ? Of course not. I still have much proving to accomplish -- to these hiring managers and their crew. But they obviously see a glimpse of something special in me -- which you don't. I speak my mind...I live authentically. Yes, it's a risk to live that way, but I am willing to accept the consequences of my actions.
sblom 16y ago
If you remember what a linked list is, how pointers (or references) work, and have written more than 10k real world lines of code in your favorite programming language, I would fully expect you to be able to write, not memorize, any of the linked list functions that you mention. I certainly understand your frustration, but I really don't think either the tone or the content of this blog post is going to help land a job in this era where hiring managers ask Google what it knows about a candidate.
- blahedo 16y ago
  But possibly not error-free the first time at a whiteboard. Talk about unrealistic conditions.
  - angelbob 16y ago
    Sure. And a good interviewer should take that into account. I ask this kind of question ("write me code to reverse this linked list, re-using the existing nodes") quite frequently. I don't expect even experienced programmers to have memorized it, and it's (a bit) more interesting than it sounds. While I do give mental brownie points for people who can just write it in one go, I don't consider it a non-starter if you can't. But if you can't get to the point of having written it, with prompting and help, in half an hour, that's a non-starter.
AndrewMoffat 16y ago
This blog post strikes home. Anyone who has worked with me or seen my work has identified me as a top-tier developer, and yet I rarely nail any interviews because I never "sound" how the hiring manager thinks a good candidate should sound. I've boiled it down to my salesmanship, or lack thereof. I don't like talking myself up, and therefore I have difficulty conveying myself confidently. And, as it goes with vicious cycles, each time I fail to do so lessens my ability at future attempts. > Mistrust in applicants runs deep among hiring managers, and I have found that I must still perform Houdini tricks during the interview process, even if an insider vouches for me. Even though I know I'm accountable for my salesmanship, I get this sense as well. It's incredibly frustrating to sense that you're being looked over as being a phony trying to pull one over on a company (how does this work exactly, anyways?) More often than not though, I've noticed this happens more with hiring managers who are not qualified technically to hire developers.
- MetallicCloud 16y ago
  Yep, I'm right there with you. I know I'm not selling myself correctly, but the thought of putting anything on my resume that even remotely embellishes the truth a little makes me want to hurl. Also, combine that with the fact that I hate my current job so much that I am afraid that my next just might suck as much, so I am being /very/ picky. I've turned down a couple of job offers that in hindsight I probably should have taken.
  - sokoloff 16y ago
    I would encourage people like yourself to put enough information your HN profile that you can be reached for networking purposes by other HN readers. Many of us may be in a position to offer interviews for non-suck jobs or pointers towards same, that we aren't going to post in open comments to the entire HN community, but would send targetted to the email in your HN profile. If you are shy or anti-marketing, you may need to work just a little harder in mediums you are comfortable with to network. (This isn't directed at you specifically, MC.)
    - 16y ago
Swizec 16y ago
> Those who code at an alarmingly rapid rate, who get complex code compiled and running the first time around. One word: Emergent design. Coding shouldn't be done in large patches of perfect code, it should be done in small segments of perfect code that are individually tested for their correctness and build up the whole solution. The fact I couldn't run my code every few lines would completely destroy my ability to produce anything beyond what I would deem pseudo-code even if it did, on the surface of it, look like real code.
- JoachimSchipper 16y ago
  It's a linked list. It is a small segment of code.
deleted 16y ago
[deleted]
skybrian 16y ago
I wonder how he knows what they're downgrading him for? Most interview processes don't give the candidate any feedback - just "hire" or "no hire". From the other side, I certainly don't expect perfect code on a whiteboard, especially if they're typical mistakes that even experienced coders sometimes make.
- Popcorn 16y ago
  > I wonder how he _He_ is a she.
- varjag 16y ago
  > I wonder how he knows what they're downgrading him for? She. And yes, probably she knows. One usually has the feeling which part of the interview they fail.
  - grayhairmomma 16y ago
    Oh I always know why I'm being downgraded. During whiteboard coding sessions, I often need hints. But given these hints, I get to the answer most of the time. In this economy, everyone is looking for "A" players. My blog post says that. "Today’s interviews seem heavily geared toward software engineers who rarely need to look stuff up. Those who code at an alarmingly rapid rate, who get complex code compiled and running the first time around.". So sorry, but this does not describe me. Nor does it describe the majority of good programmers out there ! But interviews do seem to screen for these whiz kids. Joel Spolsky said it right -- top notch "A" player software engineers don't apply for jobs. They don't need to. Jobs find them. But does this mean that B or B+ players are utterly worthless and unemployable ?
    - varjag 16y ago
      It doesn't, and am against sorting people into A, B etc buckets at all. Nor am a big fan of interview puzzles in principle. Looking at how my grandparent post sunk though, seems like an opposite came across to a number of people. Good luck to you with job search.
zackattack 16y ago
Do you think that being able to implement a linked list is a fundamental programming skill? Because if an advanced programmer is lost her ability to relate with novices ("my boss can't even implement a fucking linked list") I'd say that'd be a bad thing. In my humble estimation, experts tend to be bad teachers because they have lost touch with the frames of novices. The best teachers are ones who have most recently mastered a skill.
- angelbob 16y ago
  Depends on the position. I have worked, recently, on codebases where that kind of thing was absolutely a core skill and we asked people to write linked list code in the interview process. We were also doing manually-managed core OS and display manager code for a mobile operating system. In my current job writing server-side Java and Ruby on Rails code, I wouldn't dream of asking that question. It would be pointless.
  - eftpotrm 16y ago
    Amen. I've worked perfectly happily and successfully in software for the last 10 years, writing what most of the software industry is writing - database apps. I've never, ever, needed to write a linked list, a sorting algorithm, access memory directly and pass around pointers or any of the sample problems that are being cited here. I know the theory, I've done them in academia many years ago but I've got more important and useful things to remember on a day-to-day basis. These are firmly under the category of 'look them up if I ever need them again' and I'd be perfectly happy with a hypothetical candidate (I've not interviewed anyone in years) who said they knew the theory and would look up the exact details. I do that all the time with the more esoteric features. At my last place, we did have a coding test as part of the interview. We checked all sorts of little things but could usually mark the entire test with some accuracy on the first question. 1. Please write a valid SQL inner join statement. Seriously. For a position specifying SQL, to maintain an SQL backed custom business application, a majority of applicants couldn't write an inner join. I suppose I'm saying - do whiteboard / paper coding tests, but do the _right_ ones for your projects. Don't give them a test on something that's clever but unnecessary for what you do, check they know the basics and are up to speed with independent learning and they should be fine.
deleted 16y ago
[deleted]
aplusbi 16y ago
I've interviewed a lot of programmers and I think there are many misconceptions about what an interviewer is looking for or expecting. I don't expect you to be able to code quicksort from memory. I do expect you to be able to code quicksort given the spec for it. Just because I point out an error doesn't mean I'm counting it against you. I'm pointing it out to see how you handle it. I do expect you to ask questions. If you are unfamiliar with an algorithm or forget the details, ask. I may not give you the answer but I'll at least point you in the right direction. I generally try to make this clear to candidates so that they don't get uncomfortable if I point out some problem, but a lot of interviewers don't, which can be hard on the interviewee. I doubt, however, that there are many who expect perfect code on a whiteboard. It's as much about the process than the result.
- timcederman 16y ago
  I feel exactly the same. Don't try to make stuff up you don't know, do ask me questions, do just TRY, rather than noodling about and not saying or doing anything.
  - mech4bg 16y ago
    The thing that sucks is when the interviewer doesn't care about that, but instead cares about specific answers to their particular list of questions. It can be astonishingly random who gets through an interview. Bizarre that just a few words can tip the balance.
- ZoFreX 16y ago
  This reminds me of my Cambridge University interview. I thought I'd done terribly because I couldn't provide the answer to most of the questions they asked, but I did explain how I would find that answer if they gave me 10 minutes and some paper. I passed the interview, and many of my peers that were able to recite the formulae by rote when prompted (and thus felt they had done well) did not.
- misterbwong 16y ago
  I believe this was the original intention of the "coding" interview, but it morphed from being used to expose thought processes into a binary checklist (e.g. Can he code a linked list? Yes. Can he code a quicksort? No. Oops, no job). As the blogpost pointed out, it's pretty useless to require the knowledge of the implementation of these items because 99% of programmers will never need to code it from scratch. If someone on our (web) team was building a new linked list library, they're doing something wrong.
aristus 16y ago
I worry a lot about this. I don't think it's distrust so much as thoughtlessness. From what I can tell, Google (and other companies) started using these kinds of questions as a way to cheaply filter sudden floods of applicants, not because this is the way to find the greatest geniuses of our time. Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact. As the tactics of successful companies percolate through the rest of the industry, they take on a third unfortunate property: cargo-cult foolishness. Google asks binary search questions and they have great engineers. I want only the best engineers, therefore I will ask binary search questions. I don't know what else to do so I shall grade strictly on style points, because points are scientific, right? Bleh. Put it another way: if there are a large number of productive creative people shut out by a culture of thoughtless interview checklisting, that's an opportunity for some smarter company to snap them up. Such a company would by necessity have an outlaw air about them. Who else would hire misfits? But gangs of talented misfits can be a powerful force.
- Natsu 16y ago
  > Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact. You've just described how we ended up with many of our problems in the government, military, education & private industry all in one sentence. A single upvote doesn't seem like enough.
- sokoloff 16y ago
  Thoughtful comment, but there's a practical problem with your last point: how can YOU (as a hiring manager at this "some smarter company") effectively filter through the enormous set of screened-out candidates that Google rejected and find those productive, creative misfits that you want to interview/hire out of the teeming throng of vocational misfits? Of the people actively applying for jobs at any given point in time, the "truly excellent" are under-represented as compared to the total population of programmers. I'm not a Joel fan boy, but I think http://www.joelonsoftware.com/items/2005/01/27.html http://www.joelonsoftware.com/items/2005/01/27.html states this problem more clearly than I can in a few paragraphs on HN.
Evansbee 16y ago
I feel bad for this lady, but there's a flaw in this logic (and with the logic of many commenters here). Everyone assumes that the battle is between... Person 1: -Great resume -Relevant work history -Strong sense of corporate citizenship -Can't code on white board and Person 2: -Can code on whiteboard -Smokes crack in the bathroom But the reality is, you're all interviewing for the same job! You're not getting the job, not because you can't whiteboard code, but because someone else has the same qualifications AND CAN whiteboard code. Which would you choose?
- j_baker 16y ago
  Unless I was hiring a professional whiteboard coder, I would find another method.
  - Evansbee 16y ago
    I believe that /this/ is short sighted. I do interviews, I care less about the right answer than I do about the problem solving approach. I interview electrical engineers and I make them do simple transistor problems. If someone gave up and said that they couldn't do it without some sort of SPICE program, I'd cut the interview pretty short. But if the fundamentals are there, even if they don't remember something stupid, knowing how they approach a problem and if they know how to ask for help is more important. Every time someone says "I didn't get the job b/c I couldn't do a linked list on the whiteboard." I'm fairly certain it was more than that.
    - j_baker 16y ago
      My point is that a person's inability to code on a whiteboard has little to do with the value they can provide to the business. Some people just aren't good at it, and why should they be penalized for it? There are other ways to get programmers to write code in an interview, and a simple "Do you prefer to code on the whiteboard or on a computer?" can resolve this. It's not as though that's a huge burden on the business or the interviewer.
      - 16y ago
msie 16y ago
It's hilarious that some commenters here refer to the author as a guy.
- mmt 16y ago
  Your amusement seems to me to be based on a false assumption. "He" could be gender-neutral, and perhaps they're encouraging equality by ignoring the sex of the referent. http://news.ycombinator.com/item?id=1795518 http://news.ycombinator.com/item?id=1795518
  - grayhairmomma 16y ago
    Trust me. I'm all girl.
mech4bg 16y ago
I've had some astonishing questions asked in interviews lately. Very esoteric and obscure parts of C++ that if you followed good design you wouldn't even see or need to know about - and if you did, it's a short google query away. Testing esoteric knowledge rather than actual intelligence and programming ability is a complete fallacy imo. But then it goes even further at some places where you have to do a psychometric test to get in...! At least Google's interview questions (from what I saw) made sense in their challenge. It's not stuff you would know from being an everyday programmer but it's stuff a truly great programmer should know.
mavelikara 16y ago
My theory is that many other technical fields have high barriers of entry where a newcomer has to really prove her chops, usually with a certification exam, before being allowed to practice the profession; but once she starts, fellow professionals treat her with respect and take it as understood some minimum capability. In programming, almost anyone can start on the job - but we play out the hazing ritual throughout entire careers. Every time a programmer has to change jobs, she has to face a barrage of pointless trivia questions from megalomaniacs. Of course, many of them then grumble that they can't find competent programmers. Also, I think that the interviewer anti-loop that Steve Yegge mentions (http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...) is real. Well, back when I was at Amazon, we did (and they undoubtedly still do) a LOT of soul-searching about this exact problem. We eventually concluded that every single employee E at Amazon has at least one "Interview Anti-Loop": a set of other employees S who would not hire E.
- deleted 16y ago
  [deleted]
csjohnst 16y ago
How good a programmer can she be when there's not even a Hello World post on her blog, just this rant... just saying...
ericflo 16y ago
This is why I don't ask candidates to code. I ask them to describe concepts, articulate trade-offs, and/or walk me through their process of solving a real problem (usually something I've just solved so that I'm intimately familiar with the space).
- RiderOfGiraffes 16y ago
  I hired someone who did brilliantly on walking and talking through all the conceptual issues. Turned out they couldn't code, and they couldn't touch someone else's code without breaking it. I need to see someone code.
  - ericflo 16y ago
    Yeah, but then there's that whole other class of people who are great but can't deal with the pressure and awkwardness of coding on a whiteboard in an interview. No interview process can be perfect, so unfortunately the trick is in correcting hiring mistakes early.
    - RiderOfGiraffes 16y ago
      > people who are great but can't deal with the pressure > and awkwardness of coding on a whiteboard in an interview. We try really, really hard to allow for that. We try to get people talking first, and make moving to the whiteboard or paper or whatever part of the discussion, rather than propping them up and saying "Go!". Additionally, in our line of work sometimes you have to program in a team under extreme time pressures. We've found that most people who can't talk about programming while sketching ideas and solutions in interview, can't do it for real. The upshot is that you should always be testing for what you actually want. We want programmers who can design solutions, work in a team, get stuff done, ask questions when unsure, make decisions when necessary, change their mind when appropriate, and write programs that work. That's what we try to test for in interview, and before.
      - ericflo 16y ago
RiderOfGiraffes 16y ago
Like so many complaints about coding in interviews, this is talking about coding for a bad interviewer. Listening to both sides of the argument I've come to the following conclusion. Just as the unthinking mantra is now "90% of applicants for programming jobs can't program," equally often we hear "99% of interviewers can't interview." Interviewing is a two way street, and programming jobs require more than just programming wizardry. You will need to work with a team, you will need to communicate with management, and you will need to understand people who aren't programmers. Start by understanding interviewers.
aarp 16y ago
and you, you're just too f*cking, blond!!! blond = old.
varjag 16y ago
Perhaps it just shows there's more junior people in hiring decisions now than it was before. They remember what they had to pass to get a grade in their CS class two years back, and that's it. All these tests are really assignments from Data Structures and Algorithms class, and being fresh out of college can help here a lot.
edw519 16y ago
on a white board, no syntax errors, compilable Huh? You're worrying about whether or not what you write on a white board will compile? How do you know? Press a magic button to OCR what you've written, download it into some computer somewhere, and compile it? Sounds like you're interviewing at firms with technology I didn't know existed. Your interviewers have you code on a white board so that they can evaluate you, not your code. They want to see how you handle a problem, how you approach your work, how you think on your feet, how you deal with interaction, and how your intelligence and experience applies to their business. Anyone who worries about whether white board code actually compiles is missing the point. If they're more interested in perfect syntax than embracing you and your potential contribution, then you don't want to work for them anyway. I think you're making this too hard on yourself. Memorize nothing. Just be yourself. Programming is like riding a bike; once it's part of your DNA, you don't have to worry about it. Just relax, trust your inner programmer, and let this become a self-solving problem; some jerks may reject you, but the right fit will come when someone sees who you really are.
- bmj 16y ago
  I agree, though I think, perhaps, the author has a point about something. It's one thing to be asked to write code on the whiteboard for a practical problem. During the interview process for my current employer, I was asked to sketch out a database design for a given application, including actually writing out some of the SQL to generate the tables, constraints, etc. I was then asked to write queries to pull reports against my schema. I was also asked to show some code to pull said queries from the database, in the language of my choice. Those sorts of questions seems appropriate for the position in question. Asking me to implement a linked list or binary tree? Not so applicable. Might I use these sorts of things? Yeah, but the senior engineers assume I know how to use Google.
  - aplusbi 16y ago
    It's often hard to ask relevant questions that will fit into the time allotted for an interview. Your DB schema example is a good one - it shows that the candidate can design (and to a lesser extent, implement) an application. Your example (I'm assuming) is missing strong algorithmic problem solving however. It would be good to have an additional question to test this kind of knowledge. It's also important to realize that most technical interviews are really about weeding out bad candidates than finding good ones. It may also be necessary to have questions general enough that any given candidate stands a chance at solving it. If a candidate doesn't have SQL experience your example would be bad (assuming the company didn't require SQL experience). This is why you see questions like "implement a binary tree." Any competent programmer should be able to implement a binary tree. If they have never seen a binary tree before, they are simple enough to describe in 5 minutes. I once asked a candidate to implement a trie. He had never heard of a trie before so I drew one on the whiteboard and briefly explained it. He asked me a few questions and then proceeded to implement one. We then discussed the pros and cons of different methods to store the nodes (vector, list, map). It showed me that, given a spec, he could code a data structure and the following discussion showed me he understood memory and time constraints.
agentultra 16y ago
Coding problems in interviews can be a put off for me (though not a complete turn off if everything else about the job looks good). 1. It shows unfamiliarity with my work. It seems rude to invite me all the way into your office just to be filtered. In a perfect world (or at least the one I knew some years ago) I'd be invited into an interview because you were already familiar with my work and wanted to talk to me -- not just to see if I was worth talking to in the first place. 2. Anxiety. I don't operate normally under conditions where everything I say is being evaluated. 3. They can be easily regurgitated. 4. They don't really tell you anything unless you know what you're asking for. I've been in interviews for web development positions where we started getting into the finer details of C++, sorting algorithms, and file system implementations. These are positions where I was being asked to write web applications in Python. I've been writing web applications in Python for years -- I don't think I've ever actually needed to implement a file system or even write a sort routine (tim sort is pretty good and most sorting in web apps is done by search engines or rdbms's anyway). The problem is most people seem to think that since Google does it, they should do it too. However, if you don't know how to ask the right questions, you're just going to waste everyone's time. My time has been wasted in interviews as the interviewee. Boring technical questions that lead no-where and have little to do with the relevant skills for the job; often just for the sake of asking technical questions and appearing smart. Anyone can do that even if you yourself don't know the answers. In a perfect world you wouldn't need to look at my resume to remember my name when I walk in the door. You wouldn't need to bother "screening" me. You want me to be there to meet me and see if I'm the right fit for the job. But I also understand that businesses get a mountain of resumes and that some large portion of them just aren't worth looking at. It'd be nice if there was some way that you could at least know where to look in the pile for relevant resumes. That way you could spend less time screening (how draconian sounding) and more time interviewing. Sounds like a problem some decent software could solve...
- aplusbi 16y ago
  My company is currently in the middle of a lot of college recruiting. Most college students/recent grads have very little to show. If you're lucky they had the forethought to save some of their school projects and post them online. Even a lot of industry people don't have much to show. Plenty of decent programmers don't have serious side projects (or aren't comfortable releasing them to the public). As for regurgitated answers, I keep my eye out for those. You can usually tell if someone has seen a similar problem before. If I think they have I ask them. I sometimes ask a different question to see if it was raw ability or familiarity. They do tell you a lot. They tell you whether the candidate can actually write basic code or not. I'm not trying to see if you are a great programmer, I'm trying to see if you are a bad programmer. It can be really difficult to spot a great programmer, but it's usually very easy to spot a bad one. Anxiety is a real problem however. I try to take that into account but it affects so many people in so many different ways. Personally I think resume's are worthless. I think the best form of application would involve some form of code submission - either a simple "screener" problem or perhaps a personal project. That might still be followed by an on-site screening interview (people lie and cheat all the time).
pitdesi 16y ago
I'd be interested to know what people think about coding pre-screening tests in general. As is obvious from my profile, I'm working on a startup trying that helps companies and recruiters easily implement coding tests to weed out people who can't code. This is a bit different than asking someone to whiteboard a solution - we're aiming to help companies get from a few hundred resumes to the top 10 or 15. We've commonly heard the problem (and experienced it first-hand) that people can't code, and we think coding tests helps solve that problem. I think it's a better solution than going by your past experience, because that's often fluff.
deleted 16y ago
[deleted]
z0r 16y ago
Data structures and algorithms are the foundation. If I ever find myself unable to write a list or a tree or a sort, I'd better be doing a different job.
davidjhall 16y ago
We've been interviewing MS-SQL dba's for months now. Each time, we ask them to rate their SQL experience on a scale from 1-10 and most candidates have said 7-8. When brought in and asked to do a simple SQL select with a group by, none of these candidates could write any SQL. Any SQL. That's what makes tests important.
golgo13 16y ago
I dunno guys. Shouldn't the C++/C#/Java dudes be ready for this? I am an SQL Server Dev/DBA and the code/design something on paper type questions are expected for us. Plus it goes even deeper with DMVs, system stored procedures, etc. I just don't get why the dev folks are surprised when an interviewer asks them to implement a doubly linked list or something along those lines.

132 points by grayhairmomma 16y ago

I understand where the author is coming from because many interviews questions are unreasonable and test absolutely nothing. However, if someone couldn't code a linked list on a whiteboard, I'd be severely worried. Same goes for a binary tree. If you know what a linked list or binary tree is, you should have no issues figuring out how to represent them with code in 10 minutes. The other trickier problems are there to test problem solving ability, which I believe is a valid thing to test. I think the reason for this style of interview is that companies are afraid of false negatives. They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified. Additionally, swearing all over the place never helps your case...

tkahn6 16y ago
I think you mean that companies fear false positives which, in turn, causes a high false negative rate.
tgflynn 16y ago
They'd rather reject 95% of the qualified people and 99.9% of the unqualified people rather than 94% qualified and 99.5% unqualified. And then they complain that they can't hire developers. I don't think these types of interviews are well conceived. Human memory is extremely context dependent and a whiteboard/interview type situation doesn't establish the right context for someone who's accustomed to working alone with a mouse, keyboard and compiler. Also the more knowledge you have the more difficult it becomes to retrieve that knowledge quickly. So these types of interviews might be good at selecting people who know all about linked lists and binary trees but not much else.
- jchonphoenix 16y ago
  I disagree. If you know what a binary search tree or linked list is, you should be able to code them. If you can't do something this simple, how can you be expected to actually solve a problem that you can't just look up the answer too?
  - jonafato 16y ago
    I'll agree with this on one condition: don't hold syntax errors against me. I interviewed for a position about eight months ago. I was rusty with my C (had been doing more java and python around that time), and put "int i = 0" in a for loop on a white board and seemingly had it counted against me. This kind of thing, along with things like missed semicolons, should be ignored by interviewers. Not only is it a simple fix, it also says nothing about the logic in the code.
    - nostrademons 16y ago
      That's even legal syntax in C99.
    - aplusbi 16y ago
      What makes you think it was held against you? Most programmers can be kind of OCD about code and would want to point out that kind of error, whether they thought it was relevant to your abilities or not.
    - matwood 16y ago
      Unless I've needed a specific language, like SQL for example, anytime I've asked a candidate to code on the whiteboard pseudocode has always been fine.
    - thornkin 16y ago
      Assuming you mean for (int i = 0; ; ) {} that is legal syntax. Perhaps I'm dull, but what is the error?
      - lunaru 16y ago
        I think the point was that in C(89) you need to declare all variables at the beginning of the scope block.
  - j_baker 16y ago
    Can't code one on a whiteboard != can't code one
- chollida1 16y ago
  > Also the more knowledge you have the more difficult it becomes to retrieve that knowledge quickly. I've never heard this about the human brain before. I'm not saying you're wrong, because I don't know, but statements of fact like this deserve a good reference. Do you have anything to back up this assertion of fact?
  - deleted 16y ago
    [deleted]
  - tgflynn 16y ago
    Actually I intended that statement more as an hypothesis/conjecture than as a statement of fact. It does agree with my own introspective observations. If I have seen many different approaches to solving a certain class of problems and I'm presented with a problem which shares features of that class I'm going to have to spend time trying to figure out which of those approaches is most appropriate to the problem and circumstances. If I've only ever seen one approach to that type of problem then the initial phase of the solution space search is simplified and I can immediately begin to try to adapt that one approach to the particular problem. An example might be solving a max flow problem. There are graph based and linear programming based approaches to that problem. If you're only aware of the graph based approaches then you won't lose time trying to figure out which of the two approaches is most appropriate for the problem you're facing. Of course if you're confronted with hard real world problems then having more knowledge increases the likelihood that you will be able to find a solution. That may not apply however to artificial interview questions in a time constrained context.
rsl7 16y ago
Code on the whiteboard is counterproductive at best. Let's hook up your laptop to the projector so I can get a glimpse of how you interact with your computer. I learn more about you by seeing your relationship with your text editor, how you look up information you can't remember, etc. Not watching you sweat with a marker in your hand.
- phillijw 16y ago
  I agree. I can type a good chunk of code in a few seconds and have it nicely placed in my head to think about other things. On a whiteboard it may take me a minute just to write something out and by that time I've forgotten what I was doing.
- ssp 16y ago
  I learn more about you by seeing your relationship with your text editor Are you sure you are not just learning whether the candidate is superficially similar to you?
  - weaksauce 16y ago
    well a programmer that is coding a linked list in c/c++ probably(definitely) should know the pointer semantics. If they are looking that up then they should be a pass unless you are looking for a really junior programmer. Now if you are asking them to connect to a db and update a record with a stored procedure and they looked up the syntax for a db connection to a mysql database then you know they are fairly proficient at that type of coding but just forgot the exact syntax of a db connection because it's not something done every day whereas any c programmer worth their salt should know basic pointer rules.
    - Retric 16y ago
      Any language I have not used for a while get’s tossed out of the buffer, and I need to lookup even the most basic of syntax when I start coding in it. Once I get going I can easily recall if it’s *, &, ->, or ^ but at the start I really do need a refresher. PS: Oddly enough, I have little issue working on a multi language programs, it's just I think in terms of pointer not C pointer.
grayhairmomma 16y ago
Bill Maher is my hero. Sorry if my swearing offended you, but it's just who I am.

KevinMS 16y ago

Its because credentialism has permeated the software business recently. Credentialists love tests, its how they got their credentials, and if they don't keep believing in tests over real world performance, they will have to re-examine the true worth of their credentials.

Dilpil 16y ago
It is the opposite. Interviewers are coming to realize credentials, be they Microsoft certs or computer science degrees, are not great indicators of software engineering aptitude. The more you believe in the accuracy of credentials, the less you would want to ask coding questions in an interview. Better to simply examine resumes for the appropriate certifications and then ask fit questions. If on the other hand, you believe nothing but on the spot coding demonstrations can prove a candidates abilities, you would do exactly what these interviewers are doing. Perhaps these tests are not the optimal tests, but they sure beat credentialism.

nowarninglabel 16y ago

Coding general solutions should be par for the course. I agree that some interviewers are coming up with contrived examples. But of the 6 data points I have now from hiring people, those who could code on the white board turned out to be good employees (4 of them) and those who could not turned out to be a vast waste of time (2 of them). As jconphoenix was alluding to, I would have rather ended up rejecting more of the qualified applicants than ending up with a time-wasting employee.

j_baker 16y ago
This sounds like risk aversion to me. People place twice as much emphasis on avoiding loss than they place on gaining something equivalent (even though the end result is the same). If you look at it in this light, then of course the good ones weren't as good as the bad ones were bad. The end result is that you end up with employees who definitely don't suck, but aren't really great either because you spent all of your time avoiding bad programmers and not enough finding good ones.
- wtracy 16y ago
  Given how hard it can be to fire people, I don't blame managers for being risk averse.
hackinthebochs 16y ago
I don't really understand this mentality. Is is really that hard to get rid of the charlatans that slip through after the fact? Just monitor them fairly closely (but secretly) for a couple of weeks. Have some sort of object measure of performance for that time period. If they don't pass muster, get rid of them. This seems like a better method than spending 6 months to fill a couple of positions.
- hc5 16y ago
  Training and getting someone up to speed for a few weeks, then getting rid of them (if it doesn't work out) wastes more time and money than spending several months to fill the position with the right person. Laying people off for performance is hard to quantify, not to mention I certainly wouldn't want to be working for a company who is secretly monitoring new hires' performance.

mikeklaas 16y ago

If I found this article by a potential applicant, I'd be much less likely to hire them. Besides the obvious red flag of the sentiment why should I have to code at a programming interview, the knowledge that they have been rejected by many other companies would make me worry.

AndrewMoffat 16y ago
I understand where you're coming from, and yes, most people would probably do that, but personally, if I found a article by a potential candidate expressing their frustration with not being able to adequately convey their skillets and abilities, I'd make an extra effort to reach out and evaluate them more carefully so that I don't miss what they have to offer. Maybe you haven't been in their shoes, so I can't blame you for your approach, but the phrase "diamond in the rough" exists for a reason.
alain94040 16y ago
I didn't have that impression (and I have been a hiring manager for 10 years+). It gave me the impression of someone senior. What I would then try to determine in the interview is whether that person has grown to become a strong developer, or rather has reached a level of incompetency. But I wouldn't pass judgment either way based on that blog post.
rimantas 16y ago
If the job is to code on whiteboard: definitely don't hire.
grayhairmomma 16y ago
Sorry you feel that way. Several hiring managers from top companies feel differently than you though, because they have contacted me directly and even asked me to apply at their companies. Does this mean that I've got an instant job ? Of course not. I still have much proving to accomplish -- to these hiring managers and their crew. But they obviously see a glimpse of something special in me -- which you don't. I speak my mind...I live authentically. Yes, it's a risk to live that way, but I am willing to accept the consequences of my actions.

sblom 16y ago

If you remember what a linked list is, how pointers (or references) work, and have written more than 10k real world lines of code in your favorite programming language, I would fully expect you to be able to write, not memorize, any of the linked list functions that you mention. I certainly understand your frustration, but I really don't think either the tone or the content of this blog post is going to help land a job in this era where hiring managers ask Google what it knows about a candidate.

blahedo 16y ago
But possibly not error-free the first time at a whiteboard. Talk about unrealistic conditions.
- angelbob 16y ago
  Sure. And a good interviewer should take that into account. I ask this kind of question ("write me code to reverse this linked list, re-using the existing nodes") quite frequently. I don't expect even experienced programmers to have memorized it, and it's (a bit) more interesting than it sounds. While I do give mental brownie points for people who can just write it in one go, I don't consider it a non-starter if you can't. But if you can't get to the point of having written it, with prompting and help, in half an hour, that's a non-starter.

AndrewMoffat 16y ago

This blog post strikes home. Anyone who has worked with me or seen my work has identified me as a top-tier developer, and yet I rarely nail any interviews because I never "sound" how the hiring manager thinks a good candidate should sound. I've boiled it down to my salesmanship, or lack thereof. I don't like talking myself up, and therefore I have difficulty conveying myself confidently. And, as it goes with vicious cycles, each time I fail to do so lessens my ability at future attempts. > Mistrust in applicants runs deep among hiring managers, and I have found that I must still perform Houdini tricks during the interview process, even if an insider vouches for me. Even though I know I'm accountable for my salesmanship, I get this sense as well. It's incredibly frustrating to sense that you're being looked over as being a phony trying to pull one over on a company (how does this work exactly, anyways?) More often than not though, I've noticed this happens more with hiring managers who are not qualified technically to hire developers.

MetallicCloud 16y ago
Yep, I'm right there with you. I know I'm not selling myself correctly, but the thought of putting anything on my resume that even remotely embellishes the truth a little makes me want to hurl. Also, combine that with the fact that I hate my current job so much that I am afraid that my next just might suck as much, so I am being /very/ picky. I've turned down a couple of job offers that in hindsight I probably should have taken.
- sokoloff 16y ago
  I would encourage people like yourself to put enough information your HN profile that you can be reached for networking purposes by other HN readers. Many of us may be in a position to offer interviews for non-suck jobs or pointers towards same, that we aren't going to post in open comments to the entire HN community, but would send targetted to the email in your HN profile. If you are shy or anti-marketing, you may need to work just a little harder in mediums you are comfortable with to network. (This isn't directed at you specifically, MC.)
  - 16y ago

Swizec 16y ago

> Those who code at an alarmingly rapid rate, who get complex code compiled and running the first time around. One word: Emergent design. Coding shouldn't be done in large patches of perfect code, it should be done in small segments of perfect code that are individually tested for their correctness and build up the whole solution. The fact I couldn't run my code every few lines would completely destroy my ability to produce anything beyond what I would deem pseudo-code even if it did, on the surface of it, look like real code.

JoachimSchipper 16y ago
It's a linked list. It is a small segment of code.

deleted 16y ago

[deleted]

skybrian 16y ago

I wonder how he knows what they're downgrading him for? Most interview processes don't give the candidate any feedback - just "hire" or "no hire". From the other side, I certainly don't expect perfect code on a whiteboard, especially if they're typical mistakes that even experienced coders sometimes make.

Popcorn 16y ago
> I wonder how he _He_ is a she.
varjag 16y ago
> I wonder how he knows what they're downgrading him for? She. And yes, probably she knows. One usually has the feeling which part of the interview they fail.
- grayhairmomma 16y ago
  Oh I always know why I'm being downgraded. During whiteboard coding sessions, I often need hints. But given these hints, I get to the answer most of the time. In this economy, everyone is looking for "A" players. My blog post says that. "Today’s interviews seem heavily geared toward software engineers who rarely need to look stuff up. Those who code at an alarmingly rapid rate, who get complex code compiled and running the first time around.". So sorry, but this does not describe me. Nor does it describe the majority of good programmers out there ! But interviews do seem to screen for these whiz kids. Joel Spolsky said it right -- top notch "A" player software engineers don't apply for jobs. They don't need to. Jobs find them. But does this mean that B or B+ players are utterly worthless and unemployable ?
  - varjag 16y ago
    It doesn't, and am against sorting people into A, B etc buckets at all. Nor am a big fan of interview puzzles in principle. Looking at how my grandparent post sunk though, seems like an opposite came across to a number of people. Good luck to you with job search.

zackattack 16y ago

Do you think that being able to implement a linked list is a fundamental programming skill? Because if an advanced programmer is lost her ability to relate with novices ("my boss can't even implement a fucking linked list") I'd say that'd be a bad thing. In my humble estimation, experts tend to be bad teachers because they have lost touch with the frames of novices. The best teachers are ones who have most recently mastered a skill.

angelbob 16y ago
Depends on the position. I have worked, recently, on codebases where that kind of thing was absolutely a core skill and we asked people to write linked list code in the interview process. We were also doing manually-managed core OS and display manager code for a mobile operating system. In my current job writing server-side Java and Ruby on Rails code, I wouldn't dream of asking that question. It would be pointless.
- eftpotrm 16y ago
  Amen. I've worked perfectly happily and successfully in software for the last 10 years, writing what most of the software industry is writing - database apps. I've never, ever, needed to write a linked list, a sorting algorithm, access memory directly and pass around pointers or any of the sample problems that are being cited here. I know the theory, I've done them in academia many years ago but I've got more important and useful things to remember on a day-to-day basis. These are firmly under the category of 'look them up if I ever need them again' and I'd be perfectly happy with a hypothetical candidate (I've not interviewed anyone in years) who said they knew the theory and would look up the exact details. I do that all the time with the more esoteric features. At my last place, we did have a coding test as part of the interview. We checked all sorts of little things but could usually mark the entire test with some accuracy on the first question. 1. Please write a valid SQL inner join statement. Seriously. For a position specifying SQL, to maintain an SQL backed custom business application, a majority of applicants couldn't write an inner join. I suppose I'm saying - do whiteboard / paper coding tests, but do the _right_ ones for your projects. Don't give them a test on something that's clever but unnecessary for what you do, check they know the basics and are up to speed with independent learning and they should be fine.

deleted 16y ago

[deleted]

aplusbi 16y ago

I've interviewed a lot of programmers and I think there are many misconceptions about what an interviewer is looking for or expecting. I don't expect you to be able to code quicksort from memory. I do expect you to be able to code quicksort given the spec for it. Just because I point out an error doesn't mean I'm counting it against you. I'm pointing it out to see how you handle it. I do expect you to ask questions. If you are unfamiliar with an algorithm or forget the details, ask. I may not give you the answer but I'll at least point you in the right direction. I generally try to make this clear to candidates so that they don't get uncomfortable if I point out some problem, but a lot of interviewers don't, which can be hard on the interviewee. I doubt, however, that there are many who expect perfect code on a whiteboard. It's as much about the process than the result.

timcederman 16y ago
I feel exactly the same. Don't try to make stuff up you don't know, do ask me questions, do just TRY, rather than noodling about and not saying or doing anything.
- mech4bg 16y ago
  The thing that sucks is when the interviewer doesn't care about that, but instead cares about specific answers to their particular list of questions. It can be astonishingly random who gets through an interview. Bizarre that just a few words can tip the balance.
ZoFreX 16y ago
This reminds me of my Cambridge University interview. I thought I'd done terribly because I couldn't provide the answer to most of the questions they asked, but I did explain how I would find that answer if they gave me 10 minutes and some paper. I passed the interview, and many of my peers that were able to recite the formulae by rote when prompted (and thus felt they had done well) did not.
misterbwong 16y ago
I believe this was the original intention of the "coding" interview, but it morphed from being used to expose thought processes into a binary checklist (e.g. Can he code a linked list? Yes. Can he code a quicksort? No. Oops, no job). As the blogpost pointed out, it's pretty useless to require the knowledge of the implementation of these items because 99% of programmers will never need to code it from scratch. If someone on our (web) team was building a new linked list library, they're doing something wrong.

aristus 16y ago

I worry a lot about this. I don't think it's distrust so much as thoughtlessness. From what I can tell, Google (and other companies) started using these kinds of questions as a way to cheaply filter sudden floods of applicants, not because this is the way to find the greatest geniuses of our time. Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact. As the tactics of successful companies percolate through the rest of the industry, they take on a third unfortunate property: cargo-cult foolishness. Google asks binary search questions and they have great engineers. I want only the best engineers, therefore I will ask binary search questions. I don't know what else to do so I shall grade strictly on style points, because points are scientific, right? Bleh. Put it another way: if there are a large number of productive creative people shut out by a culture of thoughtless interview checklisting, that's an opportunity for some smarter company to snap them up. Such a company would by necessity have an outlaw air about them. Who else would hire misfits? But gangs of talented misfits can be a powerful force.

Natsu 16y ago
> Policies implemented under the gun have two unfortunate properties: they are wasteful and hard to change after the fact. You've just described how we ended up with many of our problems in the government, military, education & private industry all in one sentence. A single upvote doesn't seem like enough.
sokoloff 16y ago
Thoughtful comment, but there's a practical problem with your last point: how can YOU (as a hiring manager at this "some smarter company") effectively filter through the enormous set of screened-out candidates that Google rejected and find those productive, creative misfits that you want to interview/hire out of the teeming throng of vocational misfits? Of the people actively applying for jobs at any given point in time, the "truly excellent" are under-represented as compared to the total population of programmers. I'm not a Joel fan boy, but I think http://www.joelonsoftware.com/items/2005/01/27.html http://www.joelonsoftware.com/items/2005/01/27.html states this problem more clearly than I can in a few paragraphs on HN.

Evansbee 16y ago

I feel bad for this lady, but there's a flaw in this logic (and with the logic of many commenters here). Everyone assumes that the battle is between... Person 1: -Great resume -Relevant work history -Strong sense of corporate citizenship -Can't code on white board and Person 2: -Can code on whiteboard -Smokes crack in the bathroom But the reality is, you're all interviewing for the same job! You're not getting the job, not because you can't whiteboard code, but because someone else has the same qualifications AND CAN whiteboard code. Which would you choose?

j_baker 16y ago
Unless I was hiring a professional whiteboard coder, I would find another method.
- Evansbee 16y ago
  I believe that /this/ is short sighted. I do interviews, I care less about the right answer than I do about the problem solving approach. I interview electrical engineers and I make them do simple transistor problems. If someone gave up and said that they couldn't do it without some sort of SPICE program, I'd cut the interview pretty short. But if the fundamentals are there, even if they don't remember something stupid, knowing how they approach a problem and if they know how to ask for help is more important. Every time someone says "I didn't get the job b/c I couldn't do a linked list on the whiteboard." I'm fairly certain it was more than that.
  - j_baker 16y ago
    My point is that a person's inability to code on a whiteboard has little to do with the value they can provide to the business. Some people just aren't good at it, and why should they be penalized for it? There are other ways to get programmers to write code in an interview, and a simple "Do you prefer to code on the whiteboard or on a computer?" can resolve this. It's not as though that's a huge burden on the business or the interviewer.
    - 16y ago

msie 16y ago

It's hilarious that some commenters here refer to the author as a guy.

mmt 16y ago
Your amusement seems to me to be based on a false assumption. "He" could be gender-neutral, and perhaps they're encouraging equality by ignoring the sex of the referent. http://news.ycombinator.com/item?id=1795518 http://news.ycombinator.com/item?id=1795518
- grayhairmomma 16y ago
  Trust me. I'm all girl.

mech4bg 16y ago

I've had some astonishing questions asked in interviews lately. Very esoteric and obscure parts of C++ that if you followed good design you wouldn't even see or need to know about - and if you did, it's a short google query away. Testing esoteric knowledge rather than actual intelligence and programming ability is a complete fallacy imo. But then it goes even further at some places where you have to do a psychometric test to get in...! At least Google's interview questions (from what I saw) made sense in their challenge. It's not stuff you would know from being an everyday programmer but it's stuff a truly great programmer should know.

mavelikara 16y ago

My theory is that many other technical fields have high barriers of entry where a newcomer has to really prove her chops, usually with a certification exam, before being allowed to practice the profession; but once she starts, fellow professionals treat her with respect and take it as understood some minimum capability. In programming, almost anyone can start on the job - but we play out the hazing ritual throughout entire careers. Every time a programmer has to change jobs, she has to face a barrage of pointless trivia questions from megalomaniacs. Of course, many of them then grumble that they can't find competent programmers. Also, I think that the interviewer anti-loop that Steve Yegge mentions (http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...) is real. Well, back when I was at Amazon, we did (and they undoubtedly still do) a LOT of soul-searching about this exact problem. We eventually concluded that every single employee E at Amazon has at least one "Interview Anti-Loop": a set of other employees S who would not hire E.

deleted 16y ago
[deleted]

csjohnst 16y ago

How good a programmer can she be when there's not even a Hello World post on her blog, just this rant... just saying...

ericflo 16y ago

This is why I don't ask candidates to code. I ask them to describe concepts, articulate trade-offs, and/or walk me through their process of solving a real problem (usually something I've just solved so that I'm intimately familiar with the space).

RiderOfGiraffes 16y ago
I hired someone who did brilliantly on walking and talking through all the conceptual issues. Turned out they couldn't code, and they couldn't touch someone else's code without breaking it. I need to see someone code.
- ericflo 16y ago
  Yeah, but then there's that whole other class of people who are great but can't deal with the pressure and awkwardness of coding on a whiteboard in an interview. No interview process can be perfect, so unfortunately the trick is in correcting hiring mistakes early.
  - RiderOfGiraffes 16y ago
    > people who are great but can't deal with the pressure > and awkwardness of coding on a whiteboard in an interview. We try really, really hard to allow for that. We try to get people talking first, and make moving to the whiteboard or paper or whatever part of the discussion, rather than propping them up and saying "Go!". Additionally, in our line of work sometimes you have to program in a team under extreme time pressures. We've found that most people who can't talk about programming while sketching ideas and solutions in interview, can't do it for real. The upshot is that you should always be testing for what you actually want. We want programmers who can design solutions, work in a team, get stuff done, ask questions when unsure, make decisions when necessary, change their mind when appropriate, and write programs that work. That's what we try to test for in interview, and before.
    - ericflo 16y ago

RiderOfGiraffes 16y ago

Like so many complaints about coding in interviews, this is talking about coding for a bad interviewer. Listening to both sides of the argument I've come to the following conclusion. Just as the unthinking mantra is now "90% of applicants for programming jobs can't program," equally often we hear "99% of interviewers can't interview." Interviewing is a two way street, and programming jobs require more than just programming wizardry. You will need to work with a team, you will need to communicate with management, and you will need to understand people who aren't programmers. Start by understanding interviewers.

aarp 16y ago

and you, you're just too f*cking, blond!!! blond = old.

varjag 16y ago

Perhaps it just shows there's more junior people in hiring decisions now than it was before. They remember what they had to pass to get a grade in their CS class two years back, and that's it. All these tests are really assignments from Data Structures and Algorithms class, and being fresh out of college can help here a lot.

edw519 16y ago

on a white board, no syntax errors, compilable Huh? You're worrying about whether or not what you write on a white board will compile? How do you know? Press a magic button to OCR what you've written, download it into some computer somewhere, and compile it? Sounds like you're interviewing at firms with technology I didn't know existed. Your interviewers have you code on a white board so that they can evaluate you, not your code. They want to see how you handle a problem, how you approach your work, how you think on your feet, how you deal with interaction, and how your intelligence and experience applies to their business. Anyone who worries about whether white board code actually compiles is missing the point. If they're more interested in perfect syntax than embracing you and your potential contribution, then you don't want to work for them anyway. I think you're making this too hard on yourself. Memorize nothing. Just be yourself. Programming is like riding a bike; once it's part of your DNA, you don't have to worry about it. Just relax, trust your inner programmer, and let this become a self-solving problem; some jerks may reject you, but the right fit will come when someone sees who you really are.

bmj 16y ago
I agree, though I think, perhaps, the author has a point about something. It's one thing to be asked to write code on the whiteboard for a practical problem. During the interview process for my current employer, I was asked to sketch out a database design for a given application, including actually writing out some of the SQL to generate the tables, constraints, etc. I was then asked to write queries to pull reports against my schema. I was also asked to show some code to pull said queries from the database, in the language of my choice. Those sorts of questions seems appropriate for the position in question. Asking me to implement a linked list or binary tree? Not so applicable. Might I use these sorts of things? Yeah, but the senior engineers assume I know how to use Google.
- aplusbi 16y ago
  It's often hard to ask relevant questions that will fit into the time allotted for an interview. Your DB schema example is a good one - it shows that the candidate can design (and to a lesser extent, implement) an application. Your example (I'm assuming) is missing strong algorithmic problem solving however. It would be good to have an additional question to test this kind of knowledge. It's also important to realize that most technical interviews are really about weeding out bad candidates than finding good ones. It may also be necessary to have questions general enough that any given candidate stands a chance at solving it. If a candidate doesn't have SQL experience your example would be bad (assuming the company didn't require SQL experience). This is why you see questions like "implement a binary tree." Any competent programmer should be able to implement a binary tree. If they have never seen a binary tree before, they are simple enough to describe in 5 minutes. I once asked a candidate to implement a trie. He had never heard of a trie before so I drew one on the whiteboard and briefly explained it. He asked me a few questions and then proceeded to implement one. We then discussed the pros and cons of different methods to store the nodes (vector, list, map). It showed me that, given a spec, he could code a data structure and the following discussion showed me he understood memory and time constraints.

agentultra 16y ago

Coding problems in interviews can be a put off for me (though not a complete turn off if everything else about the job looks good). 1. It shows unfamiliarity with my work. It seems rude to invite me all the way into your office just to be filtered. In a perfect world (or at least the one I knew some years ago) I'd be invited into an interview because you were already familiar with my work and wanted to talk to me -- not just to see if I was worth talking to in the first place. 2. Anxiety. I don't operate normally under conditions where everything I say is being evaluated. 3. They can be easily regurgitated. 4. They don't really tell you anything unless you know what you're asking for. I've been in interviews for web development positions where we started getting into the finer details of C++, sorting algorithms, and file system implementations. These are positions where I was being asked to write web applications in Python. I've been writing web applications in Python for years -- I don't think I've ever actually needed to implement a file system or even write a sort routine (tim sort is pretty good and most sorting in web apps is done by search engines or rdbms's anyway). The problem is most people seem to think that since Google does it, they should do it too. However, if you don't know how to ask the right questions, you're just going to waste everyone's time. My time has been wasted in interviews as the interviewee. Boring technical questions that lead no-where and have little to do with the relevant skills for the job; often just for the sake of asking technical questions and appearing smart. Anyone can do that even if you yourself don't know the answers. In a perfect world you wouldn't need to look at my resume to remember my name when I walk in the door. You wouldn't need to bother "screening" me. You want me to be there to meet me and see if I'm the right fit for the job. But I also understand that businesses get a mountain of resumes and that some large portion of them just aren't worth looking at. It'd be nice if there was some way that you could at least know where to look in the pile for relevant resumes. That way you could spend less time screening (how draconian sounding) and more time interviewing. Sounds like a problem some decent software could solve...

aplusbi 16y ago
My company is currently in the middle of a lot of college recruiting. Most college students/recent grads have very little to show. If you're lucky they had the forethought to save some of their school projects and post them online. Even a lot of industry people don't have much to show. Plenty of decent programmers don't have serious side projects (or aren't comfortable releasing them to the public). As for regurgitated answers, I keep my eye out for those. You can usually tell if someone has seen a similar problem before. If I think they have I ask them. I sometimes ask a different question to see if it was raw ability or familiarity. They do tell you a lot. They tell you whether the candidate can actually write basic code or not. I'm not trying to see if you are a great programmer, I'm trying to see if you are a bad programmer. It can be really difficult to spot a great programmer, but it's usually very easy to spot a bad one. Anxiety is a real problem however. I try to take that into account but it affects so many people in so many different ways. Personally I think resume's are worthless. I think the best form of application would involve some form of code submission - either a simple "screener" problem or perhaps a personal project. That might still be followed by an on-site screening interview (people lie and cheat all the time).

pitdesi 16y ago

I'd be interested to know what people think about coding pre-screening tests in general. As is obvious from my profile, I'm working on a startup trying that helps companies and recruiters easily implement coding tests to weed out people who can't code. This is a bit different than asking someone to whiteboard a solution - we're aiming to help companies get from a few hundred resumes to the top 10 or 15. We've commonly heard the problem (and experienced it first-hand) that people can't code, and we think coding tests helps solve that problem. I think it's a better solution than going by your past experience, because that's often fluff.

deleted 16y ago

[deleted]

z0r 16y ago

Data structures and algorithms are the foundation. If I ever find myself unable to write a list or a tree or a sort, I'd better be doing a different job.

davidjhall 16y ago

We've been interviewing MS-SQL dba's for months now. Each time, we ask them to rate their SQL experience on a scale from 1-10 and most candidates have said 7-8. When brought in and asked to do a simple SQL select with a group by, none of these candidates could write any SQL. Any SQL. That's what makes tests important.

golgo13 16y ago

I dunno guys. Shouldn't the C++/C#/Java dudes be ready for this? I am an SQL Server Dev/DBA and the code/design something on paper type questions are expected for us. Plus it goes even deeper with DMVs, system stored procedures, etc. I just don't get why the dev folks are surprised when an interviewer asks them to implement a doubly linked list or something along those lines.