I've also noticed that the title has been changed twice. First it was "You suck at technical interviews", then it was changed to "People suck at technical interviews", then to "This is why you never end up hiring good developers".
Fizzbizz? Naah. What you want to do is something more like Minesweep. You go, "Mr. or Mrs. Candidate-Person, we're designing a Minesweep game. You've probably played it before. Here are the rules if you need clarifications. I'm handling the front-end, you write something for the backend."
It doesn't matter the programming language they go for or the precise implementation they choose to any one of a number of issues. The question is whether they can build something coherent that actually does what they intend it to. There are basically two main types of candidates: the candidate who approaches the problem and says "I need to loop over every cell in sequence and assign a mine or not based on a random probability! Wait, what do you mean, I need to get a specific number of mines on the board? I'm not sure I can make that happen" ... and the candidate who's worth hiring.
That said, I have seen interviewers use this premise to try and push for one particular algorithm as The Answer (the one where you shuffle the coordinates and take N) under the premise that "pick random coordinates, check, and retry" could be slower on ultra-dense gameboards -- but hey, dude, nobody plays 99%-full minesweeps because they're not fun. Meh.
The interview's pressure makes finding these relatively easy tricks difficult. While in the flow of programming, or discussing the problem with colleagues, you'd probably knock this one out in a few seconds, the power difference in the interview does bad things to the visual reasoning part of your brain.
A good outcome I'd look for is the candidate recognizes that loop and mark will not always produce an exact number of mines.
So the ideal interview question I think gives the candidate is a simple task with lots of pitfalls that arise in the naive implementation. The goal is for the candidate to enumerate the pitfalls, and also develop an abstract representation of the problem. Leave the solution / most efficient algorithm out of it.
The idea of the FizzBuzz is that a lot of candidates are so bad at programming that can't even program FizzBuzz. So you can filter them early and don't lose you time. It's not designed to distinguish between the good and very good candidates.
>Fizzbizz? Naah. What you want to do is something more like Minesweep.
The whole idea is that fizzbuzz weeds out tons of people who don't know how to do it, plus it's simple to do in a very short meeting for someone who knows programming it's like 30 seconds tops.
So Minesweeper doesn't make sense in this context. Even trying to convey the exact set of rules it will have to follow for the gameplay takes time (and, no, not everybody has "played it before").
"There are basically two main types of candidates: the candidate who approaches the problem and says "I need to loop over every cell in sequence and assign a mine or not based on a random probability! Wait, what do you mean, I need to get a specific number of mines on the board? I'm not sure I can make that happen" ... and the candidate who's worth hiring."
Since this interviewer seems to have made up their mind already with pre-conceptions of which candidate is worth hiring, what is the "correct" answer to this question? "Pick random co-ordinates, check, and retry?". I'd like to know, so I can give that as my first answer if I come up before such a person in the interview.
This right here is why everyone tries to game the system and come out with the "worth hiring" answer as if they had thought it out themselves. We are not even given an opportunity to ask questions, maybe come up with an answer, say "That's not optimal", and work towards a good answer -- which is the flow you would use for working at your day-to-day job. And, for the record, I started playing Minesweeper last year, and hadn't even touched it back in the day.
Any answer that gets the job done works. Looping through the mines in one pass with appropriate adjustment of probability (never seen it). Pick random spot and retry. Take all coordinates, shuffle, take N. Something I've never heard of? Sure, if you apply it and it works.
The preconception is that someone who isn't capable of coming up with a way to distributing X values into a data structure representing a M*N playing field isn't worth hiring. It's a stupidly simple task, light on the algorithms (much like the day-to-day programming tasks) and heavier on the "come up with something coherent and quasi-organized to accomplish a very simple goal" in a program.
As for the rules of Minesweeper, if you're rusty, I have a printout. :b
>Since this interviewer seems to have made up their mind already with pre-conceptions of which candidate is worth hiring, what is the "correct" answer to this question? "Pick random co-ordinates, check, and retry?"
The most efficient way (which is arguably unnecessary for Minesweeper) is to treat a 10x10 play field as a 1 dimensional array of size 100, stick your X number of mines in the first X cells in the array, then use something like the Fisher-Yates shuffle* on the array.
* Y = random number 1-100. Swap contents of cell Y and cell 100. Y = random number 1-99, swap contents of cell Y and cell 99. Repeat for entire array.
Funny because companies are still doing these things: just been asked to fizz/buzz...code with someone watching my screen, etc (as someone who was told he was inferior to whites by a HS teacher before a test, the anxiety is terrifying). Another (YC) company did the "culture" thing to me - I believe - because they just stopped calling me after telling me I would be moving on the "the lunch with the team" interview. Didn't return my emails either... This might be 2014 but it still strikes me as lacking taste to use the words "culture" and "fit" to a minority [sic] candidate.
Hiring the right people is a hard problem.
The standard approaches, hiring software developers on the basis of code scribbled on white-boards or a series of narrow technical questions, are bad. Instead, I favor three different approaches, depending on the level of the position:
We should hire new grads based on internship performance.
We should hire senior developers based of their records of design, implementation, and leadership.
We should hire mid-tier developers based on code review, typically based on open-source code.
Sure. If they want me to review specific projects or even specific files, that's fine. I understand there is quite a bit of code out there that is truly experimental, and therefore not up to production standards.
It's also OK for the candidate to tell me that the reviewed code has some problems, which lets us discuss what should be done to fix it.
Code review, if possible. Students of computer science write a lot of code for assignments and projects; I want to see some of it. Obviously, it makes sense to judge the students more leniently than I would judge finished professionals. Grades in relevant courses are also a useful signal.
If a student insists that he has no code suitable for review, fall back to coding problems, since coding under unrealistic conditions is better than no coding at all. But in such cases I have to wonder what the heck the student has been submitting for assignments and projects, so that's definitely a minus.
I can't answer a single question in an interview without getting sweatily nervous. I suffer from telephobia so I screw dearly all phone interviews. I dress awkwardly and they know it, having to shave for the interview is a total emotional pain. I can't code without having google always open in a tab. So why should I go to an interview that doesn't allow me to google the answers?
Next time, set a mind-frame of doing the interview for the experience of the moment, to realize that it's okay - that the universe is still here and nothing has changed, rather than for getting the job.
As a matter of the course, know full well that you are not getting the job. Even if you don't fumble it, know that you'll refuse their offer.
The point is that interview does not matter at all to you.
Go in fully knowing that you are not seeking anything, nor trying to prove anything, nor trying to make some statement about it all. Put this all in your mind, and everything else out.
If done and practiced, this should take you out of your obsessive introspective... To the point of laughing about it all when you walk out - after not being able to answer a single question because it was all over your head and experience level!
Later on, you'll be able to go even further by putting yourself into a buyers inner perceptive (you're shopping for the right employer), rather than a sellers inner perspective (you're selling yourself to an employer).
* As always, this is easier said than done, and will require at least a few minutes of meditation every day.
My uncle once told me something that has helped me be way less nervous at interviews. He said "Don't go in thinking you need them, go in the interview thinking they need you". Just before an interview I repeat this sentence once, seems to take pressure off my chest.
I go into interviews with another mindset. I think that I'm going to get relatively nice problems that I can try to solve without real-world consequences, and that is always fun. I also think that I'm going to meet people who code and possibly do the job I'd like to do, so I really can't wait to meet them. All in all, I treat is as a mini-vacation where I meet people I like and I talk about things I like. Whether I get the job or not is absolutely indifferent to me, I'm just in for a good time.
"The famous fizzbuzz test simply asks 'are you aware of the modulo operator?'"
False.
The fizzbuzz test asks, "Can you algorithmically about a problem? Can you understand variables? Can you program?" And it's the quickest, simplest way to find out.
How do you separate the people who "can do this job" from those who "can talk about doing this job"? There are many more of the latter than you may think.
Okay so the article is fairly standard stuff if you've read the Joel essays.
When I interview now I get the candidate to break down a problem with me and answer it in sudo code. I'll ask questions and guide the candidate about how it could be done better, asking if there are there any edge cases we have missed and generally just build something out (a plan if you like).
The best candidates tell you you are wrong (politely) and come up with a better way of building whatever it is that you've tasked them (I expect the people I hire to be a lot better than me!). You also have a vague idea of what it would be like to work with them. Weak candidates (even after you explain to them) just do not get that it's a discussion and don't ask questions or for help, they just get frustrated.
Use of the Internet is fine and you'll soon see if you can work with their brain or not.
As someone who recently interviewed at a number of Boston area tech companies I disagree with #2 from a candidate's perspective. I agree that interview coding is "far removed from the real practice of writing code" - but that's okay.
If done correctly it can give the interviewer insight into the applicant's thought process - and for the applicant it can be one of the best filters for who you would actually want to work for.
Companies/interviewers that asked very specific questions that tested only my memorization of a particular language's syntax were a huge turnoff. More open-ended ones along the line of "how would you solve this problem" and allowed me to whiteboard in the language of my choice and/or psuedocode made the company much more attractive.
There are so many different approaches to interviewing that come in and out fashion every few years. This is only natural but the common theme in a lot of discussions on HN is how people feel these approaches were not good for their particular case.
Wouldn't it be better if flip the whole thing and ask the candidates under what situation would they feel most comfortable and then conduct the interview that way? Surely, we want to get the best out of people while making them comfortable?
Yes, even this approach is not suitable for those interviewees who don't know what is the best for them but atleast the interviewer will show they they genuinely care.
My approach is basically a mix between a conversation and a mini-work experience.
At any point we have dozens of problems we need fixed or new features implemented. So after some pleasantries the question is, so we have X problem how would you go about fixing it? We want to implement Y feature, where would you look for implementations we can integrate or would you build from scratch and why?
etc...
I also have people play this game and see how they work through the challenges:
Most often people like to hire people who are like themselves. If the interviewer has a fancy degree then he/she will be looking for someone else with a fancy degree. If the interview is self-made then he/she will be be looking for self-made.
There is a certain level of experience and insight required to rise above this as an interviewer. Having a good understanding of the direction of the company and the actual skills you're looking for. I've only seen a few people who actually got this but most of them were looking for clones.
Interview questions often have less to do with the candidate than they have to do with the interviewer.
Meaning: It's either a superiority thing, a desire to impress, or just plainly covering up for lack of real interview skills.
Gauge a candidate's skill set by asking open ended general overview questions like "Tell me about SCM branching and what advantages they provide" or "Tell me about a time you might have encountered a race condition". What the answer is isn't nearly as important as _how_ they answer it.
I've interviewed candidates who can talk an amazing game but can't seem to code. Starting a couple of years ago at our organization, it has been required that candidates produce _something_ that can run (or come real close to it).
I had a friend blow a job interview on something very similar. The company gave a description of an app and asked that he code something up over the weekend and host it on github for them to see. He wrote up a pretty basic app that did what they wanted, but the poor guy completely lost his head and couldn't remember `git init`, so they passed. Whether that's fair or not is another ? (I think it was, given he was interviewing for a senior role), but it's important to keep in mind that even though you may have been a productive maintenance engineer, working within an established codebase, basic infrastructure-level stuff that comes up once a project can still bite you.
Totally agree that is a possibility. I assume you make them write something at the interview? Wouldn't it be more efficient to review code they've already written? I always review code prior to an interview.
Writing code is a process, few people can produce production quality code on the first go especially with someone looking over your shoulder.
If they haven't written code that they can share or that is Open Source, doesn't that really settle it?
I agree completely. If you are hiring someone for a position where they are expected to write code, you should verify that they can actually write code, everything else is secondary.
And yet, here we have this article, and a bunch of commenters who seem to think it's perfectly ok to not verify the main requirement of the position. It's madness!
In the best interview I had, the interviewer started by saying, "Just talk" with a friendly smile. I was taken aback, and it eased the tension I was feeling. I started talking about my experience, and he took an active interest and branched off his questions based on the things I had done. He asked intelligent questions that made his compentency clear. I was able to volly back and forth with him until my competency became clear to him.
Don't grill people with a technical interview about things you care about. Have a technical conversation and try to find common interests. You get to witness the interviewee's chops, see if they're an asshole, and prove that you're not one all at the same time.
This, so much this. Somehow, as if by magic, engineers always just know how good of an engineer somebody is after a thirty minute conversation. Just a conversation. You see this all the time in social settings.
While this is my favourite way to both give and get a technical interview, it does have a major flaw - measurability. In that there is none. The approach works when you're trying to hire one person every couple of months.
But I am fairly certain it breaks down when you have to decide between hundreds of applicants every week and you need to have a measurable and predictable process that goes beyond your engineers saying "I have a good feeling about them".
I've had interviews where the guy will ask me a technical question, and I won't answer it to his liking. Then, he'll proceed to answer the question himself at nauseating length to the point where I can see his original intention was to show me his 'brilliance'.
It's shitty and lacks courtesy in standard conversation to do stuff like that, so it's even worse during an interview when the candidate took the time to prepare, dress up in nice clothes, and show up on site for the interview.
What bothers me about a lot of technical interviewers is they don't set out to measure a candidate's qualifications so much as to reinforce their own feelings of self-importance. It's because they have little incentive to surrender their own statuses within the organization because then they won't be the ones giving interviews and deciding who they get to work with.
Previous link: http://seldo.com/weblog/2014/08/26/you_suck_at_technical_int...
Previous discussion: https://news.ycombinator.com/item?id=8232746