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.
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
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?
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.
"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.
Quick cheat sheets are important. Not everyone can memorize every single library function in every single language they use on a daily basis, even simple functions.
Is it:
strlen(string)
len(string)
length(string)
count(string)
string.len
string.len()
string.length
string.length()
or any number of other variations.
As a developer, I'm sure most everyone knows the task they're trying to do (get the length of a string), but there are so many variations of the same function between libraries and languages, that it is often quicker and easier just to search which one is appropriate for the given language, than to simply type each one out and test the code to see which one doesn't bail on execution.
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.
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.
It's not just the coding side that is broken, most interviews are; at lest what I've seen from both sides. From my experience, what really counts is being able to answer yes to the question "Would I want to spend 8 hours sitting next to this person on an airplane seat?" I can read a resume and assume most of it is true or at least not overly hyped, verify it with a question or two and ask a question out of left field simply to see if you can think on your feet; but that doesn't really tell me if you can do the job, nor would 8 hours of grilling. If I think I can get along with you then I can help you learn the job assuming your resume is reasonably accurate in regards to your skill set; if you are an insufferable jerk than I really don't care how good you are, go make someone else's life miserable; life's too short and work hours too long to deal with you.
I'm a consultant - I convert gibberish into cash-flow.
So make the expectations clear. Isn't that what you would do for an employee on a daily basis? Stacking the deck against the candidate by asking an academic-style question and not expecting an academic-style answer is a poor method for getting a good result. Just be open in the interview by stating up front that you're not looking for A-grade answers or code that necessarily compiles perfectly, but conceptual understanding and to see a candidate's coding process.
Maybe you already do that, but hopefully others who don't will start so the interview process can become a more useful measure.
Technical expertise is only one part of the whole picture. But it may be the part people thrust into the interviewer chair are most familiar with. Sometimes the interviews feel like a final exam and I wonder if they interviewer had final exams pretty recently.
I have been known to point out these annoying little things to my colleagues when we are hunting to fill positions:
Do the candidates' personalities mesh well with yours? Do you think you can stand being around them and working with them day after day?
Will they be reliable?
Do they seem easy to train? They will need to learn how this group does business and works together after all.
Do they express curiosity when they don't know the real answer?
Do they make things up to fake an answer? Or do they say "I don't know the answer, but based on my experience I would guess this..."?
Do they communicate well? Do they listen well?
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.
It's more like asking an expert pianist to tune a piano. Yes, some can, and that's great. But others can't, and it's usually not relevant--because you usually hire a piano tuner to tune the piano. Just like how you really should use an existing function for sorting.
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.
I probably learned about the difference between NP-complete and NP-hard 25 years ago. It hasn't come up since. Much is the academic stuff can be fun to study, it's useless in most jobs. The only algorithmic question that ever comes up in practice is "is it better then O(n^2)". In-memory efficiency so rarely matters.
Socialism: a lie told by totalitarians and believed by fools.
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?
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.