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.

18 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 Anonymous Coward · · Score: 3, 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.

      We give potential applicants a take home programming problem and ask them to send us the result a couple of days later. We then quiz them on their work to make sure they did not get someone else to do it.

    2. Re:Perhaps a better method... by JoeMerchant · · Score: 4, Interesting

      I've seen interviewers (one "remote work" from the Philippines comes to mind in particular) use this technique to get free work: dangle a job offer, present a thorny, nigh intractable, problem as the "interview process," get applicants to submit various solution approaches and even complete solutions - choose the best, use it yourself - never hire anyone.

    3. Re:Perhaps a better method... by computational+super · · Score: 1, Interesting

      I'm with you. I've never understood why so many programmers are so offended at being asked relatively straightforward questions. I think that the people who don't do well in those types of interviews would be better off in technical liaison roles like project, project or release management rather than hands-on coding.

      --
      Proud neuron in the Slashdot hivemind since 2002.
    4. 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.)

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

      You ask people to do work for your company and don't compensate them for it?

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

    7. Re:Perhaps a better method... by angel'o'sphere · · Score: 3, Interesting

      Well,

      I had whiteboard interviews where the interviewer had no clue about coding, so every question regarding clarification to the task where unanswered and the interviewer even got a bad impression of my skills.

      On the other hand I get so often questions that I consider silly, and afterwards I get told I was the *only* one who answered that silly question correctly.

      Funny is it, when the interviewer after accepting my answer tells me what the others had answered.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    8. Re:Perhaps a better method... by lgw · · Score: 4, Interesting

      you "don't do riddles" then I actively don't want to hire you

      There was a famous case at Microsoft about the time they stopped doing stupid puzzles. The interviewer asked some stupid puzzle about perfectly rational pirates diving treasure. The interviewee took out his phone, call his 10-year old son, who solved the puzzle on speakerphone, then walked out of the interview.

      You may have enjoyed such puzzles as a kid yourself. Grow out of that in a professional setting. Ask something job-related. Surely you've had an interesting problem ever at your job - ask the candidate how they'd solve it.

      Same for coding problems - ground your coding problem in a scenario that might ever come up at work, and be open to outside-the-box solutions to the real-world problem that dodge the specific coding problem you had in mind.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    9. Re:Perhaps a better method... by doom · · Score: 4, Interesting

      Long story short - don't assume that everything in a whiteboard interview should be taken literally.

      But this is the old "we don't necessarily expect you to know the answer, we just want to see your mental processes as you attack the problem"-- and that's complete garbage. If the interviewer is asking you trivia that they've got memorized, they're not going to be impressed at you flailing around trying to work it out from scratch.

      Myself, I've started refusing to try to answer questions like that-- this won't get me hired, either, but I feel better for not making a fool of myself for the interviewer's amusement.

    10. Re:Perhaps a better method... by Megane · · Score: 3, Interesting

      As to the "implement a bubblesort on the whiteboard" I have had these kinds of interviews and have always passed them with: "I'll do it if you want, but I'll certainly make at least one error.

      The point of that is to see you implement a relatively simple algorithm, not for you to make something perfect. The one I got was "reverse a linked list" (along with "copy a file", which I already knew backwards and upside-down). The first thing I did was immediately assume that it wasn't too hard, and the second thing was to remember all the linked list stuff from Data Structures class in my second year of college. Later, when we finally got enough budget for me to be on the other side of the table, I was shocked at how many then recent CS grads (early 2Ks) failed at both. The EE grads did much better.

      Oh, and not only can I do a bubble sort from memory, but I know it's less inefficient if the inner loop goes downward, and once in a programming contest, I even coded a bubble sort for a singly-linked list. Ask for any more complicated short (shell sort, quick sort, etc.) and yeah, that's "look it up" time. Bubble sort is good for an interview because it's simple enough to do from memory, just two loops, a compare, and a swap, and it shows that you understand the basic concepts of sorting.

      And yeah, "estimate the number of foo" questions are super retarded. If I was asked to do one, I would say "Seriously?" and give them The Look. Because they never weren't stupid, at least for hiring developers. Riddles (like crossing a bridge that only supports so much weight) are another matter, because there's a specific answer that can be determined by elimination if you have the necessary patience.

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    11. Re:Perhaps a better method... by Grishnakh · · Score: 4, Interesting

      It's sort of like if someone explains Japanese is a language, you know, like Spanish or Portuguese. Don't use two other mutual-intelligible languages, which happen to be totally different than the one you're talking about, as your examples.

      To be fair, there really aren't *any* languages similar to Japanese. The closest is probably Chinese (Mandarin), but that's only because Japanese borrows a bunch of written characters from it, for one of the three character sets, called Kanji. (So Japanese people can make out a few written words in Chinese, and vice versa, much like English speakers can make out a few words in French which we've borrowed.) The pronunciation, grammar rules, syntax, etc. are all completely different. Japanese isn't even a tonal language like Chinese.

      The only languages similar to Japanese are other "Japonic" languages, which are all used only in Japan, and within Japan are merely considered dialects of Japanese, and almost no one outside of Japan would have heard of these languages anyway as they're endangered, much like other languages spoken only by a small number of people, such as Romansh used in a small part of Switzerland by about 60k people, or the Frisian languages used by about 500k people in Netherlands and Germany.

      https://en.wikipedia.org/wiki/...

      So if you wanted to say "Japanese is a language, you know like...", you'd do best just listing 2 or 3 completely unrelated languages, such as Portuguese, Russian, and Hindi, because there simply aren't any well-known languages that are similar to Japanese.

  2. Not very effective, anyway by mcrbids · · Score: 2, Interesting

    I'm an employer. I've interviewed nearly everybody we employ at my company. And treating a hiring interview like a rote memory exam is a terrible way to qualify a potential developer hire!

    What do programmers actually do? Try testing that!

    We do "whiteboard style" for part of our interviews, but only to cover basic comprehension of algorithms. More than anything, we look for basic familiarity with logic structure, and the demonstrated ability to solve problems. Our coding section of our interview process is in the subject's language of choice, including pseudo code, and is "open book" - we want to see what happens when the dev runs into a problem they don't already know! (Critical test: can they come up with a working, supportable algorithm for a problem they don't yet already know an answer for?)

    After 20 years of programming experience, I STILL routinely look up the order of arguments for function calls via Google. Who cares to remember when Google has the answer in 0.10 seconds?

    Test what the devs will actually DO in an anticipated normal work day and make your decisions based on that.

    --
    I have no problem with your religion until you decide it's reason to deprive others of the truth.
  3. Re:I understand this is tough on older programmers by Anonymous Coward · · Score: 1, Interesting

    Nothing of course. But this is what passes for journalism in the 21st century.

    It's infected just about everything including science fiction. Pointless to argue with them since they are full of ideological fervor for their activism. My relatives emigrated from the former Soviet Union and told of similar stories where you repeated the Communist Party line no matter how ridiculous it sounded.

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

    1. Re:Interviews need training, too by jittles · · Score: 4, 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

      I decided not to work for a company after an experience like this. The interviewer asked me a question, I solved it adequately. He then tried to claim that my answer was not sufficient because it didn't handle certain words in French. The guy didn't know that the character in question was covered by extended ASCII and claimed that I had to use UTF8 to handle Latin languages. As someone who is bilingual, I knew this was not the case. I gently suggested that the character was in the extended ascii table and he got very defensive. So, I conceded that perhaps he was right (even though I knew he was not), and proceeded to answer the question using UTF instead of extended ascii. That guy was going to be my new manager, had I accepted the job. I had no interest in working for someone who could not handle being wrong.

  5. 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 /.
  6. Re:I could not agree more by serviscope_minor · · Score: 4, Interesting

    But bubble sort is a horrendous sorting algorithm with no practical applications.

    I heard this one once. You have a bunch of straight lines that go from x=0 to x=1 and start and finish at various points on the y axis. Naturally some lines cross. Start with the lines ordered by their y coordinates at x=0. Then replace the y coordinates with the value at x=1. If you then bubble sort them to get them in the correct order, every exchange corresponds to an intersection of the lines.

    So, if you want to find the intersections, I don't believe there is a more efficient way of doing it (proof needed!). Bubble sort has a particularly large number of exchanges even for an O(N^2) sorting algorithm, but you can't escape that cost in this case since that many intersections exist.

    Fun fact.

    So, if you're doing something with line intersections then there is a use for bubble sort.

    So, there is like ONE practical use for bubble sort in some obscure use cases. Taa-daa!

    --
    SJW n. One who posts facts.