Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

Post reply on HN
Print view View original

641–650 of 969 posts

Re: Google's “Director of Engineering” Hiring Test

#641

Post by to3m »

mayoff wrote: post #491
mox1 wrote: post #84

Earlier quoted context omitted.

The question was what function "returns" an inode. Those functions return a error code, you pass in a stat structure and the function populates that structure. He was saying (correctly), that they don't return (in the classic C sense) the inode. They return an error code. To me that is a big difference... int lstat(const char path, struct stat buf); vs stat* lstat(const char *path); 2 completely different functions.

Here's the first sentence of the DESCRIPTION section of the stat(2) man page on my Linux systems: These functions return information about a file.

Somebody sack the writer ;) - so, OK, I doubt I'd argue the toss if it were an interview situation. But when writing a comment or documentation I think I'd take inspiration from the documentation for either of these two fine systems.

OS X: (OK, so I lied about the "fine" part)

    The stat() function obtains information about the file pointed to by path
Windows, here the VC++ CRT - fantastically poorly described, if you ask me, though of course you shouldn't be using any of this POSIX shit on Windows, so if it confuses anybody enough to make them go and find FindFirstFile then it can only be a good thing:

    Get status information on a file

Re: Google's “Director of Engineering” Hiring Test

#642

Post by scott_s »

dboreham wrote: post #587
potatolicious wrote: post #430

Earlier quoted context omitted.

> "The problem with Google's interview methods is that they all select for a very specific type of programmer: heavily math oriented, deep knowledge of obscure Computer Science theory" I'd be marginally okay with it if the interviews actually selected for this sort of engineer! I've seen multiple people who fit this description to a T who flunked the process, hard. If the goal here is "pick the hyper-mathy, deep-CS t…

Off-topic pet peeve but why is "OK" now apparently spelled "okay" these days? (especially in bandwidth-limited situations such as SMS or IM). OK is not short for "Okay", OK?

I think "okay" looks better than "OK".

Re: Google's “Director of Engineering” Hiring Test

#643

Post by madamelic »

tomsaffell wrote: post #288
madamelic wrote: post #248

Earlier quoted context omitted.

I legitimately had a huge argument with my (former) roommate over primary colors. She was more artsy, I was insistent that the primary colors were RGB, she was insistent that they were RYB. We googled. We were both right in some senses.

Good job you didn't have a third roommate who worked in printing...

Hilariously enough, my fiance now works in printing and actually mixes the colors (t-shirt printing).

I haven't brought it up yet because we once had a fight over whether that thing you put outside your shower is called a bath mat or a bath rug (Both are correct in different circumstances)

Re: Google's “Director of Engineering” Hiring Test

#644

Post by throwawayIndian »

djsumdog wrote: post #555
_t0du wrote: post #520

Earlier quoted context omitted.

Well, general interviewing (unrelated to tech) contains various amounts of "are you lying on your resume" type questions. If someone walks in with a breakdown of 10 years dev, 5 years management, they should be able to at least comfortably answer system/coding type questions. As in, if you do something every day for 10 years, you don't forget all of it in 5. I had a candidate in a few months ago that was interviewing…

My kick-out questions: "Could you write out what an HTTP request and response looks like on the board?" I'm really surprised at how many people can't do this. If you've spent five years developing web, surely you've had to look at raw requests, either debugging using netcat or with wireshark or just looking at the information in the Chrome/Firefox debugger? "What's the difference between a GET and a POST request?" "W…

> "Could you write out what an HTTP request and response looks like on the board?"

Why should anyone remember what an http request or response should look like? Statically typed vs. dynamically typed language?

Fuck.

Are these entry-level positions or for someone with 10 years work-ex? A simple search on Google can tell anyone the answer of these questions, why do you expect people to carry an imprint of it in their memory? If the problem they'll work on mandates knowing these things it'd be pretty easy to solve with just one search. It is exactly questions like these that are worth kicking the host organization back in the butt.

Either your interviewing process is hilariously stupid or you're just spiking it up to boost the ego here.

Re: Google's “Director of Engineering” Hiring Test

#645

Post by pfarnsworth »

ggambetta wrote: post #255
chrismorgan wrote: post #131

Earlier quoted context omitted.

But hang on, the primary colours are red, yellow and blue! I know, they told me so in primary school.

Not sure how much you're kidding, but... that's true for a subtractive colour system, where you start with a white sheet of paper (i.e. reflects every wavelength) and subtract colours (filter out wavelengths) by painting over the paper with crayons. For an additive colour system, where you start with a black monitor screen, and you add wavelengths, the primaries are RGB.

I'm sorry you're incorrect. This paper says Red, Yellow and Blue. Thanks for your time, we'll be in contact.

Re: Google's “Director of Engineering” Hiring Test

#646

Post by dkonofalski »

scrollaway wrote: post #448
dkonofalski wrote: post #431

Earlier quoted context omitted.

I'm glad that someone has some sense around here. I'm getting buried for saying the same thing. Everyone is making the assumption that the author of the post transcribed this interview instead of paraphrasing it. This was a culture interview, not a technical interview, and the fact that the author misinterpreted it only strengthens the interviewer's decision to not consider them further. They are very obviously not a…

Speaking of making assumptions, you're making a lot of them. You say "Everyone is making the assumption that the author of the post transcribed this interview instead of paraphrasing it". As a member of "everyone", I disagree. I do suspect it's not as black and white as the article makes it out to be but the general attitude is not uncommon in tech companies. It's in fact so common it has become a bit of a meme. So I…

Where do you see a "Director of Engineering at Google" above claiming the interview is "super strange"? There are other (supposed) Google employees in this thread that are the source for every single one of my assertions.

Also, as a member of "everyone", how can you disagree with that statement when no one has even bothered to call out the fact that we only have one side of the story and it's the side of the story that wants our sympathies?

EDIT: I found the post you were referring to (it wasn't at the top when I first posted my responses)... The "Director of Engineering" was even saying that he doesn't buy the transcript because it's only one side of the story. That pretty much seals my point.

Re: Google's “Director of Engineering” Hiring Test

#647

Post by microtherion »

DannyBee wrote: post #152

FWIW: As a director of engineering for Google, who interviews other directors of engineering for Google, none of these are on or related to the "director of engineering" interview guidelines or sheets. These are bog standard SWE-SRE questions (particularly, SRE) at some companies, so my guess is he was really being evaluated for a normal SWE-SRE position. IE maybe he applied to a position labeled director of engineer…

Having only seen the candidate's paraphrase of that conversation (and never having worked for or interviewed with Google), I would STILL be inclined to give that candidate a thumbs down.

To solve difficult technical discussions, it's important to be able to restate the other side's arguments in the light most favorable to THEM, while the candidate was entirely focused on paraphrasing the interviewer's argument in the least sympathetic way. Would you want to work with a person like that?

Re: Google's “Director of Engineering” Hiring Test

#648

Post by WillPostForFood »

rockdoe wrote: post #449
WillPostForFood wrote: post #219

Earlier quoted context omitted.

I'm amazed people actually believe the account is accurate. The guy failed the interview, and goes to write a blog post to lash out at google (and try to mess up future interviews for them), So of course he write it to make him look good, and the questioner bad. We will stop here because it's obvious that you don't have the necessary skills to write or review network applications. You should learn the Linux function…

It's true this is probably not exactly what happened, but Google does certainly ask these questions in phone screens and the interviewers read the correct response off of a cheatsheet. The fact that several Google people posting here literally can't believe this is true shows how fucked up their process is.

The fact that several Google people posting here literally can't believe this is true also may mean it isn't true. Not that the questions weren't asked by a recruiter with a cheat sheet, but the quality of response and the attitude of the recruiter has been grossly exaggerated.

Re: Google's “Director of Engineering” Hiring Test

#649

Post by brazzledazzle »

mikeash wrote: post #590
falsedan wrote: post #569

Earlier quoted context omitted.

This looks like a typical pre-interview recruiter phone screen… they're looking for shibboleths that identify the candidate as a genuine computer person who took CS 101, and exclude candidates who spam every job with bogus CVs. I'd start every candidate with this screen, unless I personally knew them & was familiar with their technical ability. > none of these are on or related to the "director of engineering" interv…

I'd hope it's not too typical, since four out of the ten official answers are wrong, and even one of the questions manages to be wrong. (Specifically, the "why is quicksort the best?" is just completely ridiculous.) It's one thing to blindly apply a simple questionnaire without thinking about the answers that come back, and yet another thing to do it with a questionnaire that's doesn't even get stuff right.

I wouldn't be surprised if the recruiter just googled to find a list of questions and answers. This candidate probably isn't even on any official radar. The recruiter probably just uses this as a means to evaluate candidates before they officially call dibs on them. Google could very well be different since they do many things differently but recruiting has always been a sales position with everything it comes with, namely leads, quotas, conversions, etc.

Re: Google's “Director of Engineering” Hiring Test

#650

Post by mitchty »

gcp wrote: post #601
mitchty wrote: post #492

Earlier quoted context omitted.

Honestly I would have said popcnt as well. Lookup table or bit shifts when I can have the cpu count the 1's? I guess i'd need to benchmark it to be sure. Either way I can't say its a good question.

Popcnt isn't particularly well optimized in most micro-architectural implementations.

Looks that way with a quick test. But it looks like there may be a better way with SSE3 PSHUFB: http://wm.ite.pl/articles/sse-popcount.html
Post reply on HN