Programmers Are Confessing Their Coding Sins To Protest a Broken Job Interview Process (theoutline.com) 1001
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.
Perhaps a better method... (Score:5, Interesting)
Re:Perhaps a better method... (Score:4, Insightful)
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.
Re:Perhaps a better method... (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.
Re:Perhaps a better method... (Score:5, Interesting)
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.
Re:Perhaps a better method... (Score:4, 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.
Re: (Score:3)
So what you are really saying is that the sum of your experience and intelligence and education is measured in how efficient you can do a sort?
What if you used your intelligence and those other traits and abilities to do bigger and better things and just simply looked up how to do a sort? Aren't you yourself wasting your time dealing with trivial tasks of marginal impact, versus other things you could do?
Re: (Score:3)
Even worse, a lot of candidates don't even know what a bubble sort is, or that there's such a thing as a bubble sort. They don't understand that there's more than one way of sorting a list, or that some ways are more efficient than others. They don't realize that the best method in one case could be different from the best method in another. They don't realize that some methods scale better than others with list size, or that some are faster if the input list is partially sorted, or that some require ext
Re:Perhaps a better method... (Score:5, Funny)
Sorry but we don't hire people who use monospace in their posts.
Re:Perhaps a better method... (Score:5, Funny)
Fontism.
Re: (Score:3)
Re:Perhaps a better method... (Score:4, Informative)
Because you should have used a < instead of a >. Jesus.
Re: Perhaps a better method... (Score:4, Funny)
It's perl, so there's probably a pragma that reverses the meaning of the signs because one guy had a reason once.
Re:Perhaps a better method... (Score:5, Interesting)
(Not to be confused with the Monty Python questions [theguardian.com] the UK immigration authorities ask.)
Re:Perhaps a better method... (Score:5, 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/... [wikipedia.org]
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.
Re: (Score:3)
The language closest to Japanese is Korean, partly because they use many of the same Chinese loan words, but also because they have the same sentence structure (Subject, Object, Verb), as well as the use of markers to indicate who the subject is or what the object is. In many cases it's very easy to translate directly from one to the other. They both use Chinese numbering as wel
Re: (Score:3)
Chinese is actually in an entirely different language family than Japanese. They even have entirely different sentence structure.
Yeah, I believe I said this before. The only similarity they have is that Japanese borrowed a bunch of words/glyphs from Chinese and then called them "Kanji". It's not that much different than English borrowing words from French or Sanskrit, except that in Japanese, all they borrowed was the glyphs and the meaning of the word, while coming up with their own, different pronunciat
Re: (Score:3)
Re:Perhaps a better method... (Score:4, Insightful)
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.
Re: (Score:3)
If you can simply rely on code from StackOverflow to get the job done, or just pull down a library or three and write a dozen lines of wrapping code then it's not a very well thought out problem.
The company I work for has a rather novel way of doing this which we call a 'day of code', where a candidate is given a computer, a write up of the problem and desired solution, and a copy of our code base from a year or two ago. Along the way, the other employees are there to help/advise should things be not clear
No. Wrong. (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.
Re:Perhaps a better method... (Score:4, Insightful)
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.
Re: (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.
Re:Perhaps a better method... (Score:4, Interesting)
You ask people to do work for your company and don't compensate them for it?
Re: (Score:3)
It doesn't matter if it goes into a product or not. You're employing the candidate by having them complete a software project.
Re:Perhaps a better method... (Score:4, Informative)
Re:Perhaps a better method... (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.
Re:Perhaps a better method... (Score:5, 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.
Re:Perhaps a better method... (Score:5, Informative)
Honestly, I see all of the complaints above as whines by people who don't understand what a whiteboard interview is.
* If I ask you to write a sorting algorithm on a white board, I am not asking you to by rote copy out a bubble sort - in fact, if you do it by rote, I'm likely to go "oh, well that was uninformative, he didn't solve any problems, he just copied something out" (and that's why I'm unlikely to ask you to sort things, but instead, something more obscure)
* If you "don't do riddles" then I actively don't want to hire you - the entire purpose of a software engineer (i.e. not a flunky programmer) is to do riddles, all day, every day. If you don't want to do that, you don't want to do the job I'm interviewing you for.
* If you need to look up how to find the length of a string in python, I don't give any shits. I don't care if you write x.length(), x.size(), x.count, length(x), I'm asking for you to solve a problem, not get the code in the exact shape it'll compile in.
* If you don't know what NP complete means, I don't care. Of course I'm going to probe a bit into whether you can analyse the performance of your code - that's absolutely part of the job, and something I need to know you can do. But not knowing what one term means is not going to not get you hired.
Long story short - don't assume that everything in a whiteboard interview should be taken literally. I don't want to find out if you can write exact algorithm x perfectly so that it will compile. I want to know if you can solve a problem, and can talk rationally about your solution, its trade offs, its performance, etc.
Re:Perhaps a better method... (Score:5, Insightful)
Maybe you already do that, but hopefully others who don't will start so the interview process can become a more useful measure.
Re: (Score:3)
Maybe I've been lucky. I've never ever ever been to one of these white board coding interviews where someone has not made it clear that what they're after is seeing how you work, not perfect code written on a whiteboard.
Re: (Score:3)
This is what we do in engineering interviews, flat out say that we are more interested in the thought process than the correct answer.
We have a standard question of drawing a schematic for a linear AC/DC conversion. The last person we employed was also the only one who got the answer wrong. It was a trivial mistake in drawing, but his self checking of the answer is diverting no other candidate attempted.
Re:Perhaps a better method... (Score:4, Informative)
I would vote you up, if I had moderator points today.
I am in full agreement. Whiteboard tests are very informative and they often are the easiest part of any interview. I usually ask candidates a problem that they can demonstrate with pencil-and-paper or with everyday objects. Yes, this could be a sorting problem, or it could be a simplified subset of long-hand multiplication, or it could be a resource pooling problem, ... . It's things that they intuitively understand how to do in the real world, and I want to see if they can transfer this simple task to something that remotely looks like working code. If they remember the basic tools and concepts of what they learned in their first semester, that certainly helps (and I am worried, if they don't remember that much), but I agree with you that rote memorization doesn't give me any useful insights. And yes, I fully expect that this is a dialog and I'll have to keep dropping hints and answer questions as we go. That's actually another thing I test for. Asking for help is good.
Same as you, I don't care about correct use of the API or of the language's syntax. Heck, I have accepted pseudo code, and I have accepted code where somebody wrote C and Java simultaneously -- with a little bit of Ruby sprinkled in for good measure.
I do expect though that candidates have a solid sense of the scale of their problem. They have to be able to explain how many resources they need and how performance goes up when there are millions, billions or even more data sets or users. This might not be needed for every job opening, but in this day and age it is needed for many -- including the ones that I do interviews for. In other words, I expect a high-level understanding of algorithms, of CS theory (e.g. big-O behavior), and of fundamental engineering concepts (e.g. estimate latency of operations, estimate caching performance, ...).
These are things we actually need for a candidate to be successful in their work. And there are literally thousands of candidates applying for each job. It only makes sense to sort through them and find the candidates who can do the work.
Re:Perhaps a better method... (Score:5, 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.
Re: (Score:3)
So ask about actual work problem that you find puzzling, not freaking pirates.
Re: (Score:3)
I've tried that, didn't quite work out. First you can't ask anything with code you can't share, so you spend a lot of time stripping out all the proprietary stuff. I show them the paper and ask them to find the bug. They inevitably can't find it because it's way outside their experience or skill level and I'm seriously regretting even asking it because they want to know the answer when I want to move on to the next question. So I have a really really short snippet of code with tons of errors in it and as
Re:Perhaps a better method... (Score:5, Interesting)
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.
Re: (Score:3)
Arrogant prick, meet arrogant bitch. When you write "the entire purpose of a software engineer (i.e. not a flunky programmer) is to do riddles, all day, every day", you contradict yourself - you've just defined a flunky programmer.
It's bullsh*t like this that makes me glad I no longer have to deal with asshole bosses who don't know shit, and don't know they don't know shit.
Think of it - before the Internet, people didn't do "cut-n-paste coding". You actually had to have large quantities of code between yo
Re:Perhaps a better method... (Score:4, Insightful)
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.
Re:Perhaps a better method... (Score:4, 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.
Re: (Score:3)
I had an interviewer (i think at Google even) ask me to write code to calculate the value of an index in the fibonacci sequence. I wrote it using a loop that simply cached the two previous values, when they were expecting me to write it using a recursive call. Since apparently it was a test on big-O I had to then think of the less efficient way to write the code so that they could make sure i understood the issues around algorithmic efficiency.
Re:Perhaps a better method... (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.
Re: (Score:3)
I had someone refuse to write anything on the white board. Not even simple one-liners. Passing notes back and forth with the other interviewer we agreed to no go further with the candidate and have other interviewers waste their time. I imagine that the person left thinking he was too good for us. But to be honest he really wasn't really coming across great while talking to him and we were hoping that maybe he could program and redeem himself.
If someone really is too good for such things then walking out
Re: (Score:3)
That was my very first job interview out of college. They sat me down with emacs and a screen recorder and asked me to write, compile and test several basic programs while they were talking to the next prospect. Very relaxed process, I liked it, but they decided I wasn't a good fit for the job .
My next job interview was with a company that asked me to implement a binary tree class. There was no whiteboard, no computer, no paper. I had to recite to them verbally the class with methods for adding, removing
Re: (Score:3)
Indeed, out of ~10 companies I interviewed last year (among FitBits, SkyCatch and other) - there was only one that did "open laptop" interview: LeapMotion.
They asked if I use Windows or Mac or Linux, than offered a laptop with opposite to my answer. They gave me a task opposite to my day experience (using different build system) than asked to create a shareable library project. I could use whatever I want - rip the code out of GitHub, use google etc. 10min later after I solved it they were happy and I was t
I could not agree more (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
Re:I could not agree more (Score:5, Insightful)
Isn't bubble sort a trick question?
"Please implement bubble sort."
"No. That would be stupid."
"Good answer."
Re:I could not agree more (Score:5, Insightful)
Mod +1, Insightful
Re: (Score:3)
But bubble sort is a horrendous sorting algorithm with no practical applications. You do not, under any circumstances, need to know it. Seriously, a first-timer making up their own sorting algorithm tends to rediscover selection sort, and that's better than bubble sort.
Re:I could not agree more (Score:4, Insightful)
A thermostat displaying the last 30 days by high temp, bubble sort is fine, and is easily fit into a few bytes in firmware.
Re:I could not agree more (Score:5, 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!
Re:I could not agree more (Score:4, Insightful)
No, BubbleSort has perfectly valid application!
if (x.length() < 4)
{
if(x[0]>x[1]) swap(x[0],x[1]);
if(x[1]>x[2]) swap(x[1],x[2]);
if(x[0]>x[1]) swap(x[0],x[1]);
}
else throw( wrongSortAlgorithmChoiceException );
(yep, BubbleSort is about the fastest sort algorithm for tiny sets of data.)
Re:I could not agree more (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.
Re:I could not agree more (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.
Re: (Score:3)
That subroutine will be implemented at inline. And the compiler will reduce it to a single CPU instruction.
Re:I could not agree more (Score:4, Insightful)
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.
This. I've used bubble sort before professionally. Need a hand-coded-in-assembly sort for a small, nearly-sorted data set? Bubble sort is the answer. You're trying to solve the problem at hand, not show off.
Re: (Score:3)
Trick questions are great - not to get a right answer, but to just see how they answer the question.
I have interviewed many people in my career as a manager, from developers to QA to project managers.
One thing I always try to do is gauge their responses. I ask candidates to tell me about a time they failed, that they really screwed up.
It is surprising how many people give some non-answer because they think you want to hear that they don't screw up. I love when people tell me a really good one, all the bet
SubjectsSuck (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.
Re:SubjectsSuck (Score:5, Funny)
It is always about whiteboards. Blackboards are never given a chance.
There is no way such an environment could help diversity.
Re: (Score:3)
Look at who is saying it, and it's easy to spot the stupidity
Karla Monterroso, VP of programs for Code2040, an organization for black and Latino techies
Created less than a year ago. "Oh, look, let's create jobs for ourselves by exploiting minorities in the name of diversity." By 2040, there won't be any techies, not in coding, not in networking, not in much of anything.
Also, it recycles outdated content from 2015
Our Entrepreneurs in Residence (EIRs) will spend a year launching a company as well as connecting communities of color to their local entrepreneurial ecosystem. This program will be piloted in three cities in 2015: Austin, Chicago, and Durham with partners Capitol Factory, 1871, and American Underground, respectively.
Guess that didn't work out too well or they'd be bragging about it. And what a "diverse" bunch of minorities they cater to - young black women and young latino women. That's it. Men, old
Same (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.
Re: (Score:3)
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.
Amazon did you a favor by not hiring you. Ending up there would have stressed you out beyond belief with lower pay and a toxic environment. I've not worked there myself, but known many who have, and you are better off without them.
Re:Same (Score:5, Insightful)
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.
Re:Same (Score:4, Informative)
Its worse for me, because I did electronics BEFORE programming. I see a bunch of P's and N's and think they're talking transistors, not algorithms
I'll answer this one. (Score:3, Insightful)
"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.
Re:I'll answer this one. (Score:5, Insightful)
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.
Sick of the trick questions on interviews (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.
Re: (Score:3)
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.
Funny, I have literally half that resume (20 years of successful projects) and I never get "tested" for interviews. Every interview I have is along the lines of "So Hodr, we heard about you from X who said you were a key player in the success of project Y. Let me tell you about all the wonderful benefits of working for us here at Z Corp."
The best interview coding question (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.
Re: (Score:3)
Missing the Point of those Tests (Score:3, Insightful)
Not very effective, anyway (Score:3, 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 lived this another way ... (Score:3)
... I was interviewing a lady for a clerk job at Mobil Oil, where she'd be doing data entry.
I was looking for:
1.) Dedication to accuracy and detail
2.) Willingness to work overtime
3.) Ability to get along with others
She was a single mom who was hungry to work; liked people; her children were almost grown, so she had the time.
SHE FLUNKED THE GODDAM TYPEWRITER TEST!
Typewriter? I told HR I didn't have a goddam typewriter -- test her keyboard skills.
Nope.
That was in the mid-Dilbert years at Corporation.
Re: (Score:3, Funny)
... I was interviewing a lady for a clerk job at Mobil Oil, where she'd be doing data entry.
I was looking for:
1.) Dedication to accuracy and detail 2.) Willingness to work overtime 3.) Ability to get along with others
She was a single mom who was hungry to work; liked people; her children were almost grown, so she had the time.
SHE FLUNKED THE GODDAM TYPEWRITER TEST!
Typewriter? I told HR I didn't have a goddam typewriter -- test her keyboard skills.
Nope.
That was in the mid-Dilbert years at Corporation.
You gotta love it when HR decides who you can hire. I once was asked to apply for a job at a company I was currently doing work for as a consultant. They had to post the job and HR decided I wasn't qualified enough, even though I was currently doing it, to forward my resume so the hiring manager couldn't offer me the job. As a result, I stayed on as a contractor at 1.5x the pay and they didn't hire anyone.
Re: (Score:3)
Initial screening bad resumes takes me s
Hello, my name is Donald (Score:5, Funny)
What's so Special about an Algorithms Class (Score:4, Insightful)
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.
No Notes (Score:4, Insightful)
"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.
Now hi-tech are companies the "old grognards" (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...
Missing the point (as usual) (Score:3)
Programming is not about rote procedure. It is about finding a way to accomplish a goal.
Clean and efficient code is a bonus, but not mandatory. Complying with any else's definition of Good Practices may be a consideration, but only to the ones making the definition. Working well with a carefully assembled maximally-diverse team may be helpful, or may be something to overcome.
In any event, rule # 1 is paramount. Get the job Done. Everything else is value-add, at best.
*Statistics independently verified by Slashdot
Interviews need training, too (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
Re: (Score:3, Informative)
Yeah, you probably should have just left it at that instead of trying to explain the optimal answer... Interviews are often performed by junior level guys who are out to prove are smart they are (open-minded senior devs are too busy and valuable to do the the initial screening pass). To get past the first tier, sometimes you just have to swallow your pride, pat them on the head, and congratulate them on how clever their "fastest possible" solutions are.
By the way, Intel supports a POPCNT instruction now (st
Re: (Score:3)
You ran into the "I work for Google and you do not, ergo I am correct and you are not." ethos that is rampant there. Didn't you know? They have the correct answer to every problem. That's why Spaces is such a huge hit; and how they've been able to maintain a single, unified messaging platform all these years.
Re:Interviews need training, too (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
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.
Re:Interviews need training, too (Score:4, Informative)
I posted a similar comment to this effect. Also a PhD holder, and if I answer a question directly and without pause, it means I really know a good answer. Otherwise, I will ask some questions and explore like everybody else.
Seriously, I've had people tell me recursion is terrible and knew nothing about tail call optimization, or if they heard of that, they don't understand exactly what it means. Never mind I took advanced coursework on programming language semantics where we had to formally define it. Now, if you asked me for a formal definition, I would look that up, because it's been a while,
Add in the fact I don't have the PhD from the right schools, so for a few, it can't be that useful, and I really wish it wasn't near impossible to find academic appointments.
Testing (Score:3)
I find it hard to take anyone who thinks these coding tests really test for anything.
Other things to interview for (Score:5, Insightful)
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?
Happens in IT/sys engineering too (Score:3)
From the IT side of the house, I can say I've been there. In the development world, it's the whiteboard test, but in the IT world it's a tool-matching exercise and trivia contest. I freely admit that I have a very bad memory and constantly look up information unless it's actively used in my daily work. I feel the field of IT is too broad for one person to remember even the basics of _everything_. I've failed interviews because I couldn't recall some trivia questions, and I've done well on others when I was given the chance to demonstrate skills I'm comfortable with. Worse yet, I've gotten shut out of interviews because I haven't used the exact brand and version of some tool they have in the toolbox, regardless of how easy it is to pick up on the job.
In an IT context, matching a laundry list of tools, platforms and software isn't going to get you the right candidate. I hate to self-promote, but I've been told by many employers that the reason they like me is my willingness to dig in and learn new stuff, then document what I know and teach people before moving on to something else. One example I like to cite is that this is essentially the 4th time I'm relearning Citrix XenApp at a level deep enough to do a new deployment -- when this is done I'll get assigned some other project working with a completely different tool set. Some people in our field are experts in Foo but not Bar, or worse yet, specific Foo 3.6.1 experts. There are products that I work with daily (Citrix XenApp, SCCM, etc.) that are easily full time positions, and are so complex that people get to be tunnel-vision geniuses on them. Same goes for platforms -- there are Cisco configuration and management experts who go so far down in the weeds that they can't see things like SDN and hybrid network gear slowly taking over. They'll continue to get paid a lot for quite a while, but eventually the contracts and FTE positions will dry up as the product is phased out. Look at how different a typical SAN engineer's job is these days compared to the times when you had to be an EMC or NetApp savant to get things functioning.
If you're looking for someone fresh out of school, the whiteboard interview is only going to get you a sense of whether or not the candidate absorbed basic concepts from their computer science degree. In IT, most of us don't come from CS and end up here because we're crazy people who like complexity and troubleshooting/firefighting. Smart employers recognize this, but often you get programmer-style interviews when you are trying out for a spot at a software or IT services company.
When All Else Fails, Honesty Works (Score:3)
Hello, my name is... (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.
I run technical tests (Score:4, Insightful)
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.
This reminds me of a joke (Score:4, Funny)
Way back in the 1980s, one of my physics professors told the following joke:
The trustees of the university want to find out if the professors really knew their stuff so they came up with a question: What's 2+2?
They go to the math department and the professors there said, "Oh, that's easy. It's 4."
Then the go to the physics department and the professors there said, "Oh, it's 4.000000000 with an uncertainty of another decimal place."
Then the go to the engineering department and the professors there said, "Just a minute while I get my handbook."
Finally, they go to the accounting department and the professors there look around to see if anyone can hear them and then the whisper, "What do you want to be?"
Re: (Score:3)
Sins, not fetishes.
Re:CS Fundamentals are important (Score:5, Insightful)
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.
Re: (Score:3)
If you can't write bubble sort or can't figure out how to get a length of a string in Python, you shouldn't be hired.
Tell us what company you work for so we'll all know where not to apply.
Re: (Score:3)
How does a programming interview discriminate against "people of color"?
Red-black trees I suppose.
Re: (Score:3)
. But if you can't code a sorting algorithm without a reference, ... then you don't have the skills I need.
Except for a very small subset of the industry, the only skill you need to code a sorting algorithm is knowing how to type in the search box on google (or stackoverflow). Or know how to call whatever the sort() function is in whatever language you're using.
It's simply not knowledge that's relevant anymore.
Re:some things should be trivial for any expert (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.
Re:some things should be trivial for any expert (Score:5, Insightful)
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.
Re: (Score:3)
No FOSS projects? Ask them to re-apply later.
Not everyone is going to spend months doing work for free just so they can apply to your company. Some of them have better things to do, like actual paid work.
Re:Best way: Code review their github repo (Score:4, Insightful)
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.