Hacker News Reader

Comment by calcsam | Hacker News Reader

We use HackerRank, which has an in-browser IDE that can runs pretty much every language, has highlighting, etc.

I can't believe anyone would use Google Docs. Even if you don't care about your interviewees' experience, huge waste of dev time.

View on HN

I just interviewed with Google and they use Google Docs.

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.

Did you get the job? I have the interview next week. :S

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.

"... 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

We'll see what happens!

If Google doesn't take you, there's always Facebook.

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]

[0] http://www.tlnt.com/2013/02/26/how-google-is-using-people-an... [1] Adam Bryant: 'In Head-Hunting, Big Data May Not Be Such a Big Deal' http://www.nytimes.com/2013/06/20/business/in-head-hunting-b...

Let's be honest- the 'rigor' that people bring to engineering decisions is oversold.

"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 are not machines.

cf: http://www.sfweekly.com/thesnitch/2015/03/07/former-google-e...

(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.

Sounds like a nightmare.

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.

Have you ever had a productive phone screen? I think they might all be evil.

I haven't. I think they are pointless at best.

This particular phone screen was probably the most nervous I've been during any interview ever. Predictably, it was enough to disqualify me.

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.

Be carful not to forget reading off a semi-colon. Syntax counts!

Just imagine if it were a whitespace sensitive language like Coffeescript.

"Newline. Tab. Tab. Tab. Tab."

Heh. "Wait, was that 'Tab. Tab. Tab.' or 'Tab. Tab. Tab. Tab.'?"

A Lisp would be nasty, too. "... Close paren. Close paren. Close paren. Close paren. ..."

"newline, indent one tab beyond the previous line."

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.

Reply on news.ycombinator.com