Comment by notacoward
11 years ago
Humorous answer: Maybe I can't invert a tree, but watch me flip this table.
Serious answer: Companies that pull this crap deserve to starve and die.
11 years ago
Humorous answer: Maybe I can't invert a tree, but watch me flip this table.
Serious answer: Companies that pull this crap deserve to starve and die.
What specifically are you objecting to? That specific question? Writing code on a whiteboard?
How would you interview software engineering candidates?
If you rate engineers on their ability to memorize something they could have looked up on Google in 5 seconds, what are you really actually testing?
If you're not at Google's scale, a take-home test that involves them producing a working solution to a problem in their own time, that you then expect them to be able to discuss, reason about, justify, and so on is a much better tool; even at Google's scale, where you might be worried people who copy answers off the net, have them bring the laptop they used in, and then get them to expand upon their solution.
All that said, I'd be surprised if that was the only factor at play. The Twitter comment itself seems to indicate a - uh - cultural fit issue. Additionally, and with no actual knowledge of the insides of HomeBrew, that a piece of software is widely used isn't evidence that the author is an excellent (or even good) developer.
Honestly, is reversing a binary tree something you need to memorize? I assume that's what he/she means by "invert".
6 replies →
>If you rate engineers on their ability to memorize something they could have looked up on Google in 5 seconds, what are you really actually testing?
Repeating what I said earlier - You can't build a plane by opening a physics textbook. Starting with a LARGE pool of fundamental and higher order building blocks allows you to fit them together using whatever skill/talent you have at solving problems, in a MUCH shorter time than someone who doesn't.
Someone who constantly google's basic stuff is a net drag on a team's productivity. Rather than operating at their skill level, they're constantly being distracted by having to task-switch and waste hours researching stuff. The internet isn't going to magically know the exact problem you're working on and whether certain data structures or algorithms are appropriate for solving it, or if they need further tuning depending on what your priorities are, or what have you. Getting questions answered, and googling/learning about CS stuff is great on its own, and should be encouraged as much as possible, but it is not a substitute for actually retaining that knowledge.
Interviews break most people's intellectual context. Talky/show-me interviews are designed around interviewing MBA "how well can you present yourself" roles, but it completely fails to evaluate a technical person.
Doing a blind and "surprise me with a clever (or traditional) algorithm" whiteboard interview is a teaching skill, not a coding competency. You have to illustrate, explain, make your self vulnerable while understanding the problem, and work in front of someone while being judged confrontationally. It's not sane. (and glob help you if you don't wrap your entire brain around the problem in the first 5 seconds, then you're clearly subpar and are worth less than dirt even with your 15 years of experience shipping products to millions of users.)
Google is happy to have 1,000 nerd projects and only one thing that makes money. As long as they continue to interview smart people on technicalities instead of well-roundness and ability to actually contribute or move the company forward, they have no need to fix their insultingly irrelevant interview process.
Why not just take a chunk of code the candidate has written that was interesting and talk about it?
The main problem with interviews [imo] is it grabs stuff the interviewer is familiar with and throws it at the person in the more stressful position of being the interviewee. Its also [often] a very non-standard way of communicating. I don't know about you but all of my communication is via text or graphic, not whiteboard.
And, honestly, do you care more about the fact they can invert a binary tree from memory? Or that they can learn to in the next hour and implement it?
My guess is for 90% of jobs, its the second.
The point about interviewer vs. interviewee familiarity with the problem is important. It's hard to avoid comparing the interviewee's off-the-cuff solution to one that was researched at leisure and refined over multiple previous interviews. Really damn hard. Psychologists and teachers are trained in avoiding that kind of bias, and still struggle. Very few engineers are equipped to see through the "fog" and interpret a candidate's performance in a useful way. I've only encountered one - a recently former CS prof - and I've been in the business a long time.
I think the best way is to give them access to a code base, give them 48 hours and have them submit a pull request for a feature. That way you can see that they can learn the codebase and implement the feature in their own time. During the interview, you can discuss their code and the reasoning behind the implementation details.
I once got asked to spin off an ec2 instance from an image provided by the company I applied to, and then answer certain questions about the dataset on that thing. I had to write actual code to obtain the answers. All that had to happen within 24 hours. Then there was an on-site interview where they asked questions about stuff like JVM garbage collector fine-tuning and such. That was the best interview I had, ever.
Which is fine and dandy until you get that one person that cheats by getting help from someone else.
3 replies →
good thinking, very nice solution.
Demonstrating one small part of a real working software engineer's job, by solving an artificial problem in an artificial environment under artificial time constraints, while one or more people with no pedagogical training look on and (sometimes) interfere. The amount of information gained is less than the amount lost from having poisoned the entire rest of the interview environment.