Great post. I hate interviewing. I think a lot about it since I'm the type of person who performs horribly in an interview call when some person I've never met is asking me trivia questions on speaker phone...
One thing I wonder. Why are people being interviewed for technical positions in a google doc or whatever fake coding environment? Servers are cheap.
If you have to go the way of the technical phone interview, doesn't it make more sense to have both (interviewer and interviewee) parties SSH into a server and work together on some type of problem for an hour? The interviewer can even watch the candidate program or work in screen. This type of interview isn't perfect, but closed book "Programming Jeopardy" style interviews are just worse in every way.
Can confirm. They used Google Docs with me as well. I didn't find it to be all that bad, actually. Their back-to-back whiteboard interviews later on were much more nerve-wracking.
No, they passed, but invited me to apply again in a year and a half. That was a couple years ago, and their recruiters have started emailing again, so I guess I didn't do too terrible.
When they told me they passed they also told me that "some people get passed the first time and then study for the next 18 months and do amazing the next time!" and I just don't have the time for that. I already worked myself half to death in my twenties for two startups, I'm not going to study for a test as a second job for a year just to get a job at Google, although I still think it'd be fun and clearly challenging.
I recommend studying your ass off for algorithms (specifically figuring out what algorithm would be best for different real world problems, especially in regards to various Google products, including those you've never really used before) and practicing writing code on a whiteboard before you go. I studied for a solid week and a half beforehand, and it wasn't enough. I was prepared, just not prepared for what they asked me.
That's a common issue I have with these interviews, is that computer science is such a vast field that it's impossible to have everything in your head ready to shoot off in any interview, but interviewers somehow think that if you missed a question or two you're somehow not qualified to work for them, despite having years of direct experience at companies beforehand and being able to Google and refresh literally any topic you might encounter at your job in less than a minute.
Google seemed better than most at that, though. I still found the experience to be valuable and interesting.
(specifically figuring out what algorithm would be best for different real world problems, especially in regards to various Google products, including those you've never really used before) and practicing writing code on a whiteboard before you go.
"... I already worked myself half to death in my twenties for two startups, I'm not going to study for a test as a second job for a year just to get a job at Google, although I still think it'd be fun and clearly challenging. ..."
What's "good for google" right?
@cableshaft how would you rate @tptacek s observations on hiring with what you observed at google?
Google still does interviews. They try to do them better --- eg separating the hire / no hire decision maker from the face to face interviewer. But I'd like to see them try out more work samples.
I'm going through interviewer training at Google at the moment. (There's a few courses they like you to take before letting you loose on candidates.)
This is second time I'm interviewing Google and I felt the difference. They asked me questions more related to my work and less from "Cracking the coding interview" book. Hopefully it would be the same on-site. I'm confident that I'm good at what I'm doing and if Google really wants me to work on things that I'm interested, I would be a good employee. I have zero days of no-commits in my Github strike. I have more open source projects than many 500+ employees companies.
With all of that "Cracking the coding interview" book in my hand anyway! :D
thx for replying @eru, I don't envy the task evaluating candidates. By work samples do you mean real code you've created to solve problems?
“bring the same level of rigor to people-decisions
that we do to engineering decisions.” [0]
The weakness at google is understanding people. So I can understand the allure of HRA (HR Analytics) but feel google is missing something not intuitively understanding people and behaviour. [1]
"the 'rigor' that people bring to engineering decisions is oversold."
Possibly, I don't see google going down, so the engineering is sound. That's missing the real issue though.
Google, the people who lead and work there fundamentally do not grok people or psychology. This will is problematic as they attempt to diversify their workforce. I'm sure this is a known-known at google, hence the training that @eru is receiving. This is why the @tptacek article is such a good read. A tech-company attempting to understand more about hiring humans who understand machines.
people were discussing stackexchange testing people with google docs as well. Writing code in it sucks; it's surprising how annoying the wrong indent / return behavior is. I also was surprised how much I clearly rely on autocomplete, though java's api is so fat who can remember all of it.
I once had a phone interview wherein I was required to write some code and then read it to the interviewer (character by character!) over the phone. I asked him whether it would make more sense for us to use etherpad (this was maybe five years ago), but he said no.
Yes, I recently had two productive phone screens, as a candidate.
The first one taught me a bit about the company and team, and gave me a good impression of the interviewer (the hiring manager), which then led to me doing a work sample. (Without the phone screen I don't know if I would have sunk several hours into the work sample.) I ended up getting an offer but not taking it.
The second one also gave me a good impression of the company, team, and interviewer (a senior engineer) and led to me doing an full day of interviews. Which led to me accepting an offer. The one used Collabedit in addition to the phone.
I know they're not perfect, but it's much cheaper to talk on the phone for an hour than to fly someone in for face-to-face interviews. Given way more resumes than resources for in-person interviews, I'd rather narrow the field using phone screens than narrow the field based solely on what's in the resumes.
I saw the part in your article about work samples, and I agree that they're great, but they are significant work for the candidate. So I think it makes sense to do have some kind of phone call first, to see if there's enough mutual interest to make it worth the candidate's time.
There's a semantic gap getting in the way between us. Phone calls with candidates: very good. See "Warm up candidates" in the post we're commenting on for my thoughts about that.
A phone screen is a call whose purpose is to select out candidates. It's a call whose outcome can be "stop talking to this developer". They're very common, and I think uniformly evil.
Understood. I know that at least my second example was a phone screen: if that interviewer didn't like me, the interviewing process would have ended.
I don't know how you avoid that. If you have 1000 candidates per open position, you probably can't afford to do in-person interviews with all of them, or even all the ones with decent-looking resumes. What's the alternative to phone screens? An automated remote work sample system, maybe?
The whole point of work-sample tests is to minimize time wasted on subjective interviews, and to collect objective facts instead. You definitely don't want to do thousands of in-person interviews! Interviews are terrible.
For full time devs? Rarely. For interns? Absolutely. We had many applicants whose programming experience was closer to web design, and weren't conversant in basic data structures. I don't think it was inherently evil to tell them to come back next year, after they've taken a course in algorithms.
I use Google doc because I don't care if the syntax is perfect. Those IDEs do and when someone is nervous, they make simple mistakes and can't see them right away. It spirals from there.
I ask people to do the best they can to get the syntax right, and I will ask for corrections if it's way off.
I just got an interview with HackerRank and it sucked. It has some absurd code completion and a browser is not a good place to code in.
I tried to copy/paste in/out from vim and it was a disastrous process. Nearly I could not use my previously implemented bst implementation. (Which I was told to).
I screwed the test - of course it was not HackerRank's problem - and retried in vim after time ended. I could code it in a fraction of the time that I could in that ide. Time limits never work for the candidate.
I do that on all remote interviews. Code a simple-ish thing that doesn't require that you've read about it before and show me how you'd do it. Complete with the build & run command.
I think google's reasoning for using google docs is that they would rather use whiteboards but can't for phone calls. Google docs are similar to whiteboards in that they provide no highlighting or code completion.
One thing I wonder. Why are people being interviewed for technical positions in a google doc or whatever fake coding environment? Servers are cheap.
If you have to go the way of the technical phone interview, doesn't it make more sense to have both (interviewer and interviewee) parties SSH into a server and work together on some type of problem for an hour? The interviewer can even watch the candidate program or work in screen. This type of interview isn't perfect, but closed book "Programming Jeopardy" style interviews are just worse in every way.