Slashdot Mirror


Programmers Are Confessing Their Coding Sins To Protest a Broken Job Interview Process (theoutline.com)

A number of programmers have taken it to Twitter to bring it to everyone's, but particularly recruiter's, attention about the grueling interview process in their field that relies heavily on technical questions. David Heinemeier Hansson, a well-known programmer and the creator of the popular Ruby on Rails coding framework, started it when he tweeted, "Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles." Another coder added, "Hello, my name is Tim. I'm a lead at Google with over 30 years coding experience and I need to look up how to get length of a python string." Another coder chimed in, "Hello my name is Mike, I'm a GDE and lead at NY Times, I don't know what np complete means. Should I?" A feature story on The Outline adds: This interview style, widely used by major tech companies including Google and Amazon, typically pits candidates against a whiteboard without access to reference material -- a scenario working programmers say is demoralizing and an unrealistic test of actual ability. People spend weeks preparing for this process, afraid that the interviewer will quiz them on the one obscure algorithm they haven't studied. "A cottage industry has emerged that reminds us uncomfortably of SAT prep," Karla Monterroso, VP of programs for Code2040, an organization for black and Latino techies, wrote in a critique of the whiteboard interview. [...] This means companies tend to favor recent computer science grads from top-tier schools who have had time to cram; in other words, it doesn't help diversify the field with women, older people, and people of color.

22 of 1,001 comments (clear)

  1. Perhaps a better method... by johnsmithperson123 · · Score: 5, Interesting

    Would be a trial (as in free trial). Throw a fairly standard problem at them, but not one with a simple, common place implementation. Drop them at a computer with internet access, give them a couple hours, and see what they have at the end of it. It's not perfect, but it's probably a better way to evaluate skills.

    1. Re:Perhaps a better method... by JoeMerchant · · Score: 5, Insightful

      If the "friends" are always available and willing to help, then I don't care - use them, get paid.

      There's an incredible resource of programming advice available through Google and the various help boards - being able to effectively leverage that resource is a skill far beyond the value of solving obscure statistical riddles about colored marbles in jars.

    2. Re:Perhaps a better method... by infolation · · Score: 5, Interesting

      USA Airport Immigration has recently started putting programming questions to travellers who claim to be software engineers. In one case they asked the traveller Python questions.

      (Not to be confused with the Monty Python questions the UK immigration authorities ask.)

    3. Re:Perhaps a better method... by alvinrod · · Score: 5, Interesting

      If you're basing hiring on whether or not someone gets the correct answer to a statistics problem, you're probably hiring wrong. Instead, if you're using it to evaluate how a person approaches solving a problem, what steps they take, how they go about verifying if their solution is correct, what questions they ask about the problem, etc. then the problem itself really doesn't matter. In fact, it would be better to give them something impossible just so you get the added kicker of seeing how they react to that because management will sure as shit ask for impossible things from time to time.

      Hell, you could even give them a computer to see how they search for information. If I'm really stuck on something, after five minutes I start searching online as a rule because occasionally the solution requires some obscure piece of information only found in the errata or there's a bug that hasn't been patched yet and there's no point banging my head against the wall if someone else has already done that. Someone who has good Google-fu and can quickly find the information they need may well be more valuable than someone who could eventually work through the problem on their own, but only after spending 3 hours on what could have been solved in 3 seconds.

      I'd be a little leery of someone who always needs friends, because if they aren't available they might make new friends at work and then you've got someone who's eating up other developers time and hurting their productivity. However, interview processes shouldn't be about knowing answers to esoteric or eclectic problems, but rather making sure the individual has a healthy approach to solving problems, because that's what you're paying them to do. If the code is really boiler plate, you can probably just get a machine to generate it.

    4. Re:Perhaps a better method... by Blymie · · Score: 5, Insightful

      I once had a potential employer, ask me to complete a 15 hour long coding project as part of the interview process, over a weekend. Quite frankly, I just didn't have time. I told them so, and never heard from them again. What was I supposed to do, cancel plans I made, going out of town for the weekend?

      Not to mention, I have a full-time job working 60 hours a week. I'm supposed to lose sleep, for a potential job which may never come? It was only the first interview too.

        Ridiculous.

    5. Re:Perhaps a better method... by tsstahl · · Score: 5, Insightful

      I have to chime in on this. It comes down to the interviewer's expectations. Many years ago I had a white board interview with one of the 3 letter acronym companies. I wrote my answers to the questions in plain language P-code; I was prepared to defend in C++ and Pascal.

      The interviewer said I 'flunked' because the code wouldn't compile. I asked him to show me his white board compiler as that would be really cool tech. I only knew he was truly serious when he didn't laugh.

      This was one of the moments that guided me out of full time development.

      Back to the point, if the white board is merely a tool to demonstrate knowledge of, and insight into, Foo, then fine; otherwise it is an artificial somewhat nonsensical barrier.

  2. I could not agree more by Anonymous Coward · · Score: 5, Insightful

    I have interviewed many people and I don't believe in trick questions. Programmers are not supposed to memorize every algorithm. They should understand how to attack and solve a problem. I was always more interested in their thought process rather than if they get the right answer. How they look at the problem is more important

    1. Re:I could not agree more by glenebob · · Score: 5, Insightful

      Isn't bubble sort a trick question?

      "Please implement bubble sort."
      "No. That would be stupid."
      "Good answer."

    2. Re:I could not agree more by CaptainDork · · Score: 5, Insightful

      Mod +1, Insightful

      --
      It little behooves the best of us to comment on the rest of us.
    3. Re:I could not agree more by Anonymous Coward · · Score: 5, Informative

      Bubble sort is also good for almost sorted datasets (pretty much n in this case). It's used for very fast broad phase collision detection where overlaps are detected during swaps. Since the sort happens every timestep, the endpoints stay pretty much sorted and the broad phase collection detection runs in near n time.

    4. Re:I could not agree more by markus · · Score: 5, Insightful

      I am not sure why you got downvoted.

      You are absolutely correct. There are cases where bubble sort is entirely applicable and in fact preferable. I don't require a candidate to have memorized the exact implementation of bubble sort (why would they; that is in fact something you can look up). But if a candidate can meaningfully discuss performance characteristics and explain why a certain algorithm would do better or worse in a specific situation, then that's exactly what I am looking for.

      It demonstrates a better understanding of how computers actually work. For some tasks, it is perfectly acceptable to treat a computer as a black box and to fully rely on very abstract high-level APIs. And there are in fact advantages to this approach. But there are plenty of problems where this results in horrible scalability problems that can never be fixed afterwards. And in this day and age, we need to know how to scale to millions or hundreds of millions of users. A software engineer who doesn't understand these concepts is not a good fit for the openings that I am looking to fill.

  3. SubjectsSuck by aardvarkjoe · · Score: 5, Insightful

    in other words, it doesn't help diversify the field with women, older people, and people of color.

    While there are some good reasons to dislike "code on a whiteboard" interviews, this is not one of them.

    --

    How can we continue to believe in a just universe and freedom to eat crackers if we have no ale?
    1. Re:SubjectsSuck by GuB-42 · · Score: 5, Funny

      It is always about whiteboards. Blackboards are never given a chance.
      There is no way such an environment could help diversity.

  4. Same by darkain · · Score: 5, Informative

    Hi, my name is Vince. I interviewed for Amazon, specifically for their PHP API for AWS development team. Despite an entire background of 10+ years of developing front-facing PHP APIs for other businesses, plus having a major part of my code available for public review on GitHub, I failed their interview process because they wanted me to write a specific type of searching and sorting algorithm, by hand, on white-board. This type of code would never have been used on the job, ever. Yet this is what they interview on. The job was to build a PHP API so PHP developers can call basic PHP functions, and the library would translate them over to HHTPS calls to AWS. All of the complex computing/searching/sorting is handled by the existing AWS services.

  5. Sick of the trick questions on interviews by Anonymous Coward · · Score: 5, Insightful

    There's always that one guy on the interview team that would rather stroke his own ego by asking a "trick question". 100% of the time it will be either on an obscure function or feature of a language that may be used once in a career, or it will be so poorly worded as to be unrecognizable. I really don't believe that any other profession runs into this problem. With 40 years experience, an extensive resume, 100's of successful projects, I'm still treated like I graduated yesterday and am "tested" on what I know. It's insulting and companies need to stop. I'm at the point in my career that when the "trick question" person hits the white board, I ignore them and redirect the conversation back to the people asking real questions. If you are an interviewer you'll do yourself and the potential hire a much greater service by either presenting them with a challenge you've recently overcome or asking them to narrate one they've recently overcome.

    IOW - trick question guy, knock the shit off, you're annoying the rest of us. It is much more important to determine the prospects problem solving methods and skills than their fluency in the programming flavor of the month.

  6. The best interview coding question by Jeremi · · Score: 5, Insightful

    "Show me an example of a program that you wrote and are proud of"

    (and then go over the program with them to make sure they understand how it works and why they wrote it the way they did)

    The proof is in the pudding.

    --


    I don't care if it's 90,000 hectares. That lake was not my doing.
  7. Hello, my name is Donald by TeknoHog · · Score: 5, Funny

    and I don't know what "truth" means. I look up things like "democracy" and "separation of powers". I don't do riddles.

    --
    Escher was the first MC and Giger invented the HR department.
  8. Now hi-tech are companies the "old grognards" by Anonymous Coward · · Score: 5, Funny

    As a CS professor, I find the use of these kind of review processes kind of contradictory.

    In education, we often based pass/fail on two hours long exams where the student has no access to outside information. Then companies say that's not how the real world works. CS evaluation sucks!

    We change to continuous evaluation or project based learning, where student has longer time (well, certainly not 2 hours in a closed room) and can access external resources. You know, like the real world. And now it's companies the ones evaluating candidates the old fashioned way!

    Let's go back further in time and go for corporal punishments...

  9. Interviews need training, too by rockmuelle · · Score: 5, Interesting

    What I've always found funny about this interview process is that the assumption is always that the interviewer knows the correct answer(s) to the question. It's painful when they don't.

    Years ago I interviewed at Google and was asked a question about bit counting (some variation on "given a bit vector, wat's the fastest way to count the number of 1s?"). I quickly answered, "well, if your processor has a population count instruction, stream your vector through that and accumulate the result in a register". Having just evaluated bit counting methods as part of my Ph.D. dissertation, I knew this was the fastest way to do it, assuming the instruction was available (it's not on x86, but is on Power/VMX and most DSPs support it as well).

    After I got a blank stare back from the interviewee, I said, "Oh, you were looking for the lookup table answer". We could have left it at that, but he went on to explain using some very convoluted logic how the lookup table would actually be faster than using a dedicated instruction and that my answer was clearly wrong. I mentioned a little bit about the number of cycles required for each approach, but he had none of it. In his mind, I had the wrong answer, even though my second answer was what he was looking for.

    It was at that moment that I realized Google was not going to be a good place to work.

    -Chris

  10. Re:some things should be trivial for any expert by doconnor · · Score: 5, Insightful

    Experts know that it is almost always better to use the sort from the language's library, and if they can't then they would look up the code for Quick sort and use that.

  11. No. Wrong. by presidenteloco · · Score: 5, Insightful

    By using a "name-brand algorithm" which I learned in 2nd year or whatever, umpteen years ago, you are testing for cramming ability, recency of test-cramming at school, and mental copy-paste of whatever was crammed.

    You are definitely not testing for problem comprehension and creativity of solution or methodical approach to solution. All of those skills will be severely impaired by time-pressure panic, if you have a good programmer in front of you who has not crammed that particular cookie-cutter name-brand algorithm lately.

    It would be one step better if you just said: write an algorithm to sort this array/list of values. But you still chose a problem for which comprehension, creativity, and methodical solution skills are not needed, if the person happens to pattern match your posed problem with the bubble-sort they just memorized for interview-readiness purposes.

    So if anything, choose a simple-ish problem that is NOT one that has readily available mental copy-paste cheats available.
     

    --

    Where are we going and why are we in a handbasket?
  12. Hello, my name is... by uncqual · · Score: 5, Interesting

    Hello, my name is Anonymous Coward. I am a software developer.

    I was talking to you about a database kernel position which is a field I have spent much of my career in and in one case was a key member of the design/coding team developing the initial (and several subsequent) releases of a revolutionary enterprise class scalable DBMS which is still being sold over thirty years later and in production at many of the biggest companies. You, of course, must have known that because you contacted me and, unusually, I decided to stop by and chat with you because I have a soft spot for startup companies, database, and engineering managers who look around seeking talent themselves rather than relying solely on recruiters. You asserted that your startup was developing an enterprise class scalable DBMS system so it seemed like it might be interesting.

    You then asked me to write, on the whiteboard, a 'debit/credit' function that took three arguments and returned, IIRC, the amount transferred (admittedly that was a little odd). The first two arguments were account objects (passed by reference if I recall) representing the source and destination accounts respectively and the third argument was an amount (presumably in the same currency as both accounts were maintained in) to transfer (a float if I recall -- that, of course, is likely stupid in itself when dealing with currency).

    I, understandably, was perplexed -- you must want something more than this simple function (I'm not fresh out of high school looking for a summer job) and I tried to get more requirements out of you and got none except when I asked if this function was to provide its own concurrency control or if a higher level would have insured both accounts were sufficiently locked you said something like "Okay, you need to provide the locking" and agreed that I could assume existence of "Acquire/ReleaseWriteLockAccount(AccountObject)" functions.

    Okay -- so I'm thinking this is a concurrency problem, no problem (still lame, but okay...). Obviously I need to deal with deadlock potential so I ask if I there is some unique attribute of each account (you didn't give me a description of the account object's public members) that had a well defined order that I (and other developers) agreed to use to order locks when locking multiple accounts to eliminate or at least reduce deadlocks. You weren't prepared for the question so I asked if I could assume (I think) that the account number was a public field, unique among all accounts, and supported the LessThan operator with traditional semantics. You said, sure.

    I wrote the code making sure to lock the accounts in order of account number, transfer the funds, unlock correctly and return the required value.

    You were not happy -- what you really wanted me to check, it turns out, was that the source account would not end up with a negative balance and fail to do the transfer and return 0 as the result.

    What you didn't seem to realize is that in the real world cash balances on individual accounts go negative sometimes. In fact, at that instant, I had one (of multiple) accounts at one brokerage firm which had had a small negative cash balance due to an inter-account transfer out for over six months and no one cared because I had multiple accounts at that firm with a net value of well over a million dollars and cash balances (well, "cash equivalents"), overall, of a few hundred thousand dollars.

    Both of us made a decision in that discussion. You decided you didn't want to hire me. I decided I would never work for you or your company as I didn't want to risk working on/at a team/company which was so poor at evaluating people and would pass on good developers who know how the real world works and would likely hire unqualified people who answered your kindergarten questions the particular way you wanted.

    Of course, I was glad that we both made those decisions because your company seems to have never got past a very modest A round and seems to have disappeared off the face of the Earth quietly.

    --
    Why is there an "insightful" mod and why isn't it "-1"? If I wanted insight, I wouldn't be reading /.