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
It's not just enough to state that this is a poor interviewing technique and not a fantastic metric to determine job performance. They have to make it about minorities and diversity.
And obviously watch HOW they get to their solution, ie. not by connecting to a chatroom where they have a bunch of friends waiting to help out. Looking up snippets, checking parameters and syntax etc. would obviously be fine, that's what you'll be doing in daily work anyway.
-=This sig has nothing to do with my comment. Move along now=-
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?
"Hello my name is Mike, I'm a GDE and lead at NY Times, I don't know what np complete means. Should I?"
Hey Mike, I once worked for the NY Times Shared Services Center. And, generally, no.
It must have been something you assimilated. . . .
Any "confession" along the lines that "hey, when I need to get the syntax of some specific function or language feature that I'm supposed to be proficient in, I have to google for it, look up the Open Group POSIX help page, check StackOverflow etc" is not really a confession. That's the way most of us work these days.
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.
I did some interviews for a company I worked for a few years back, and my goal for those things wasn't so much to see if they could complete the problem successfully. My goal was to see if I thought the guy I was interviewing would work well with the team. I kept lowering the bar on the programming problem until it was a string reverse, which is just ridiculously simple. Even more so, I allowed the person to do it in the language they felt strongest in. For a couple of the OO scripting languages, that could be as easy as string.reverse(), and I would allowed it if anyone had ever said that. Even so, I was deliberately ambiguous about some things -- did I want the string reversed in place? Were there any error conditions I wanted returned, and should those be exceptions or return values? I had answers prepared, if any of them had ever asked me. I also had a very nice whiteboard, which they would almost to a person go up to and start crapping code onto, immediately. If they'd interacted with me and the whiteboard a bit before doing that, I would have actually stopped them before they'd written a single line of code.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
These technical interview approaches aren't very good, in my opinion, because they basically assume that the beginning and end of all software development training happened in a second year algorithms class. Algorithms are very cool, I understand why people want to talk about them, but they represent a minority programming challenge in today's world.
Speaking only for myself, in a given month of coding I may only have to consider which algorithms I should use once or twice. The rest of my time is spent on GUI design, communicating with coworkers, working on documentation, and switching between projects. Putting aside the value of algorithms in an interview, how can the interviewer ascertain all of my other software development skills if we spend 2 hours mapping trees on a white board? I would argue that they can't, and by asking technical questions about algorithms or brainteasers, they really aren't properly evaluating the skills of a professional software developer.
This reminds me of one the anecdotes I picked up from one of my college engineering professors in regards to his philosophies on tests:
"Would you fly in an airplane forcibly designed in one hour with no notes?"
And before someone starts busting my balls, yes students should learn the underlying fundamental mechanics of the subject matter. It's more of a protest of the unnecessary aspect of memorizing the details that have no bearing on someone's understanding.
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.
The point of having someone solve it without net resources is that when they are working they will run into problems where the answer is not on Stackoverflow and you need to be able to solve from first principles. Obviously as these are future problems you are going to run into you dont have one ready to use as the screening question in an interview and even if you did have a current problem (say from your current project) most such problems are non trivial and cannot be solved in the 1 hour available for a tech interview plus even if they solve it you dont have a way of knowing if they solved it right.
The point of going with a well known problem solution is that you are checking their way of solving problems. If they can come up with one of the standard solutions the library designers have already come up with you can have some confidence they will be able to come up with solutions to unknown problems they will face in the future. And by using something as simple as bubblesort you can have the coding exercise done in 10-15 minutes and spend the rest of the hour on other types of questions to check fit and attitude.
**Life is too short to be serious**
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.
You get a snippet of code (from stackoverflow) which has probably been tested to solve the problem
No. You get something that answers the question. Often the answer, while technically correct, have other (sometimes serious) errors.
This is why the state of PHP on the web is such an abomination. People bought into the "anyone can code" BS and do so by following examples SO and other places. In the case of PHP the most popular answers to "how do I query a table based on form data" answer the question, but are massive SQL-I vectors. Those snippets continue to get upvoted because the "answered" the question so people use them due to the high rankings and then upvote it themselves when it "works" for them.
A hirable programmer needs to know how to go search for answers to questions they don't know, but they also need to know how to evaluate the answers they find to determine if a) it really solves the problem and b) if there is more they need to do.
I've been working in software development for about 30 years, and I've never solved a single riddle. I'd bet that 99.99999% (and I'm being generous) of all software developers have never solved a single riddle as part of their work. I solved a lot of problems, developed algorithms, designed, analysed and optimised systems, but never encountered riddles.
Riddles are questions with simple answers which are deliberately obscure. They are rarely encountered in constructing something that requires rigorous thought and creativity, which is what software development is.
The point is, the FOSS project(s) are your portfolio, similar to how a graphic artist, photographer, architect demonstrates their ability with a portfolio.
The difference is, the artist's portfolio is built up with their paid work. Every project they work on gets added to it. A programmer can't simply take company code with them when they go interviewing, so the project has to be a hobby project.
Can't be bothered to do at least one hobby/self-training/benevolent programming project? You don't love programming enough to be that good at it
That logic doesn't follow. Not everyone who's great at programming works on hobby projects, and not every such project will be published on Github. I work with 2 people who don't program after work, and they are just as productive as everyone else. As for myself, I also don't publish my non-work projects, because I can't be bothered to write documentation for them and I've coded them to serve my use case specifically.
Confession: I run technical tests when recruiting IT persons. But it is on a computer, with Internet access, and looking up documentation or forums is fine.
In fact, using Internet or documentation to find something is a very good indicator that the candidate has skills and experience.