Previous link: http://seldo.com/weblog/2014/08/26/you_suck_at_technical_int...
Previous discussion: https://news.ycombinator.com/item?id=8232746
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.
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 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").
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.
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
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.
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.
More here: http://short-sharp.blogspot.ca/2013/04/stop-white-board-codi...
What about developers who push non-polished projects to GitHub? Can the candidate specify which project you're reviewing?
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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!
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?
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.
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".
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.
To the OP, I would suggest using the context of the interview to start (e.g. I am here because....).