More whiteboard coding won’t build you a better team
blog.hackerhires.com
blog.hackerhires.com
The worst have been ones where it was clear the interviewer had pulled questions out of the company's interview playbook and didn't have the depth of understanding to discuss them.
I'd argue that also belongs under the "best" list, because it told you exactly the level of the people you'd be working for/with.
In one such interview, I was asked for a way to implement Rock Paper Scissors in OOP without using a conditional. I came up with a neat way to do it with modulo operations and array lookups, but that wasn't The Right Way. So I came up with a way to do it with exceptions, but it wasn't The Right Way. Finally I came up with the solution the interviewer had in mind, which used Java's method overloading (my background is not Java).
I'm not sure if I "passed" the interview, but it certainly didn't make me want to.
The most important aspect of OOP is message passing, and in Java, message-passing is implemented via non-final methods. OOP is a model of computation, just as FP and imperative programming are, and certain jobs require that you understand that model of computation well.
I think the point was that, outside of specific cases, programming has many solutions. The fact that Paul gave two correct answers before getting to the 'right one' says that this was one of those cases.
Perhaps method overloading was not on the forefront of his mind that day.
A simple question of 'Why did you do it this way instead of using method overloading?' would've sufficed in figuring out whether or not they had a grasp on OOP and wouldn't have insulted the interviewee with open-ended questions where they were looking for one answer.
That would be the same as asking what is another way to write 49 and expecting only the squareroot of 2401.
This is a false statement. I have programmed for years, but never in Javascript, so I have no clue what "add a cache to a Javascript function" even means. I can quite easily write code "that determines if a number is prime", but the assumption that everybody knows JS even if they don't "specialize" in it is problematic from my PoV.
Maybe it's because my I come from the family business of construction years ago, but I believe that it should be easy to hire someone and get them involved quickly. Then we can find out if they are worth it or not. Anything up until that point is talk, and talk is cheap. If they don't past muster eventually I get rid of them. Explaining this up front makes it even easier. I'll hire you quick, but if you don't do what I need you're out. It's not personal.
"Google is a very successful technology company. While some of the problems they solve are very challenging and require innovative thinking and research, they have employees with decades of research experience and long publication track records to crack those.
New and seasoned developers will almost certainly have plug-n-chug everyday responsibilities, yet their interview process is still a fearsome battery of computer science questions. Their hiring also produces what is regarded as the most skilled CS workforce in the world and the market rewards them richly for it.
Why shouldn't we emulate this? Isn't it working? Aren't advocates of a disruption of this system essentially saying "Go ahead, relax your standards, what's the worst that could happen"? Is it taking your company 6 months to find a decent employee? Maybe that's about how long it should take because there just aren't that many decent employees."
Rephrasing (a): who are we passing on, are they in fact good potential employees, and what qualities do they have that our new hires might not?
Rephrasing (b): who have we hired that, despite whiteboard coding proficiency, isn't cutting it? And why?
In my experience whiteboard coding sessions feel adversarial, like a trap or a test, and you're basically waiting for the candidate to have an epiphany moment. Either they know the problem, or they don't but they get lucky and hit the "right" answer.
Doing reviews of code samples (or even pair programming against a new problem) puts interviewer and candidate both on the same side of the problem and feels more collaborative - I want to believe this gets you a better sense of what someone would be like to work with, and fewer false positives and negatives.
If anyone has evidence or studies either way I'd love to read them.
in my experience, false positives in early ventures (research projects, startups, project partnerships, whatever) are the kiss of death. If you need a group of people to do work at high capacity, bringing someone who does not 'fit' in when the group is young will probably destroy it. existing high-capacity people will become angry, there is less fault tolerance in the quality of the work and the rate at which it has to be done, etc.
it is usually the case that it is better to have 2 workers who click and are highly productive than 5 workers where 1 is not productive. so in the early days, failing closed seems very valuable.
when you are larger, there could be a higher tolerance. you could afford to hire someone and fire them a few months later if they do not work out, because the work that they are doing for you immediately is not as critical. however, there is also a certain culture that comes along with this and if you want to avoid that culture it seems like you still want to 'think lean' and part of that thinking could be to keep the amount of productive people high.
and it might also not go well with your current group members to say "yes, that hire was bad and we'll terminate them next week" for the fifth, sixth time in a quarter ...
In a larger organization, if you hire someone, you're stuck with them in almost all cases. So be picky.
Has someone suggested whiteboard proficiency is sufficient by itself?
The whiteboard is meant to filter out people who suck. "Add a cache to a JavaScript function" is a dumb question for reasons many others have pointed out. Joel's classic article[1] recommends these as examples:
• Write a function that determines if a string starts with an upper-case letter A-Z
• Write a function that determines the area of a circle given the radius
• Add up all the values in an array
Those are all trivial. You should be able to come up with another half-dozen if you sit and think for a bit. The language doesn't matter, and the syntax shouldn't matter (as compared to the semantics).
I hear lots of scare-stories of "great coders who choke on interviews," but I find it very hard to believe any kind of "great coder" can't add up the values in an array. I might ask "how do you find the median value in the array" just to see what they come up with. There isn't a right answer, but there are lots wrong answers.
[1] http://www.joelonsoftware.com/articles/GuerrillaInterviewing...
Fair point, that is a straw man. I haven't experienced an all-whiteboard interview - there's always been more to it.
The whiteboard is meant to filter out people who suck.
I think that's what some interviewers have missed. They jump straight in at the deep end with difficult algorithmic puzzles, and don't ever do an easy one. I have experienced this.
Yeah, I have hard algorithm questions I ask, but I don't open with them, and I know they are hard. I expect them to possibly fill the entire remaining time.
Also, for the hard question, it's not even about getting it "right": the one person I ever had get my hardest question right was flushed by other people in my process, and I've hired many people who never got close. I want to see how they try.
Sure, I'll be happy to discuss deep issues with you - after you've shown me that you're proficient in basic CS. It used to be that you could screen that over the phone, but now that you can look up the answers on your phone, that's kind of hard :)
If I have a false positive (i.e. you seem to understand CS but don't fit the company), it's not like the CS question is all that's asked. It's the launch point for a deeper discussion. That means a false positive hopefully gets caught in that later stage, but deep CS knowledge is sine qua non.
If that skill (knowledge of CS) doesn't matter to your shop, then yes, you shouldn't use it for gating.
My other point is that some companies might find there are other qualities they're looking for that occur in the pool of people they pass on. That's what's really worth looking at, I think - all the while being careful not to mistake "good cultural fit" for "promotes long term monoculture".
It was one of my favorite interviews.
The reality is that (like everything at Google), the hiring process is constantly evolving and changing. Google puts considerable effort into improving its hiring process.
So, my counterargument is this: If Google is tweaking its hiring process and trying to make it better, why shouldn't you? Don't think of it as relaxing your standards, because it isn't. Think of it as changing your standards to better suit the kind of people you want to hire.
At first I understood the question as described, but then looking at the javascript code I suddenly became lost and frightened. It wasn't until I clicked "run" that I realized the code wasn't working "as is" and needed to be made to work. Then it was just a matter of adding cache to the function (at least that's what I did). I had first read the blog as "this an example of caching" not "this is an example of the starting point for the problem".
I still prefer to not have 1 "golden" question but a list of problems the interviewee can choose from. That way they can find something that matches with areas they might be more famalier with (oh crap, I haven't thought of Fibonacci in awhile so I'll take on this robot-battle-engine quiz)
On an unrelated side note I had some fun making quiz #27 pass assertions but fail the meaning of the test:
for ( var i = 0; i < array.length; i++ ) {
var d = [];
d.fn = fn;
d.fn(i);
}1. It checks that you still know the basics of what's required for a CS degree.
2. Quite possibly, it also checks your capacity to (re-)learn some things for preparation.
Both of these are good indications of your ability to adapt to a new technical environment.
So you need to hire a developer who knows 'how not to code', 'when not to code', how to write as little code as possible (libraries, reuse and designing things that don't take much code, clean, concise, elegant, and well-structured).
These sort of developers are indeed the best to hire - but hard to find. And, as the article points out, is not what most technical interviews test for.
As an aside, did anyone else see the irony in the word "competent" being misspelled?
On the other hand. What would be the difference between a script-kiddie and an "actual hacker"? The years of experience? Or the purpose for what the code will be used for?
When asked questions without a context, you have no motivation and they seem weird. If you want to know if I know what a b-tree or a hash-table is, or what is database normalization, just ask me to explain you what it is. I also, wouldn't expect a candidate to implement one of those things right out of their head... that's just crazy. I would expect for him to be able to use them or at least how they work. If you need to see what I've done or how I perform against a particular issue your company might be having, code review of already code-reviewed code is a great, great way to test a candidate.
Github profiles are also a good indicator: it shows what you want, want motivates you, it can show real-world code that you have written.
Just talking of your experiences and how you've solved problems is also a good thing.
I think it's good to see how people learn new things and to see if the candidate looks for existing libraries rather than writing everything from scratch. You'd need to be able to give the candidate some time but I think it would be a valuable exercise.
It's a great method to hire, but it's expensive - you better make sure that the people you invite in are pre-checked quite well.
It definitely was the most fun I ever had interviewing.
The fact of the matter is, the hypothesis that "whiteboard skills == mondo real life developer skillz" is pretty much an unspoken, and utterly unquestioned article of faith out in vast stretches of startupland.