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