Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

221–230 of 969 posts

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

#221

I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are? You just need to know what they're used for, and if you need the specifics, you'll find out with a single search. He seemed to know that as well though. Kernighan for bit twiddling algos, that kind of thing. It's a bit strange to have someone non-technical interviewing a techie…

"I'm amazed he knew things in such detail. I mean who would know just how long a MAC address is? Or what the actual SYN/ACK etc tcp flags are?"

I was more impressed by how simply he explained many of them in real-world terms. Especially countering Big O. That plus what he's already built indicates he's exactly the kind of person to direct the sort of projects they're building. That they filtered him with this garbage Q&A speaks volumes about Google's ineffective hiring. Plus, indicates what kind of people might have made it into the organization.

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

#222

Earlier quoted context omitted.

What are the components that make up a color? "Well, it depends what color model you are using, which differentiates between additive and subtractive color mixing, the medium used (print, screen, etc.)... No. It's Red, Green, and Blue.

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

Those primary colors are real to me dammit!

/colorblind

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

#223
post #158

Earlier quoted context omitted.

I'm just reaching here, but is there a chance at all that the test wasn't really about whether or not he knew the correct answers but more that he knew the correct answers and was able to simplify them to the extent that a non-technical user could understand and compare them? I have a feeling that Google is far more interested in someone being able to get their point across than someone that just wants to sit there a…

> this guy always has to be right and would work terribly with people of different levels of skills Are you talking about the recruiter?

No, I'm talking about the person that wrote the post. Since this was a phone interview, this is a paraphrase of what happened, written by the post author. The whole thing smacks of "I knew way more than that person, they were clearly an idiot".

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

#224
7. what is the name of the KILL signal?

Me: SIGKILL which #define is set to 9.

Recruiter: no, it's "TERMINATE".

Me: SIGTERM (15) is different from the KILL signal (9).

Recruiter: that's not the answer I have on my sheet of paper.

You know, I think I've been asked this question on a Google phone screen - and I think the question is specifically "What is the signal that the `kill` command sends?". The answer is in fact SIGTERM, not SIGKILL; if you want SIGKILL you need to specifically say `kill -KILL` or `kill -9`. If you insist that it's SIGKILL, you're just technically wrong. And if you can't understand the question, you're missing very important skills; this sort of confusion will cause actual production problems.

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

#227
I have interviewed many people, in large and small companies, and saw how interview processes get built in the wrong and right way.

First, here's two reasons why interview processes suck. One, is that no one wants to help recruiting, or HR, do their job. Helping them is an errand and is done in a robotic way. You end up with an idiotic checklist that is a shame to great engineers. Second, is when the team finally realizes idiots joining the team are hurting the team - they will go about and have more motivation to support the recruitment process. Then, when you let a group of people devise such a task you get: an average process designed to leave out the human parts (shift bytes in array) and fit each person's interview style, or a crazy idiotic processes made by people mentally jerking off to each other (implement raft. in assembly). A team can be a company or an actual software development team.

The right way to do it, is this. I believe a single person, who cares about developers, who is passionate about developer experience - should build his/her team's interview process. He/she can take feedback from the team, but that person should eventually build the process and make the calls.

In this specific case I want to believe there is an accurate answer, and a correct answer, and they wanted the correct answer, or at least to see him negotiate his way to the correct answer even though it is subpar (although his accurate answers are impressive). That being said, I'm giving Google credit here. There is a small chance it might just be one of the first options I've described here.

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

#228
post #103

Earlier quoted context omitted.

Yah I get the feeling you're supposed to "act stupid" so you can get to the next interview. Definitely not an idea way of getting candidates - you are selecting for people who know how to manipulate screens (and thus increasing the risk of getting a bad candidate), or rejecting otherwise knowledgeable people who just don't have the time/inclination/"social savvy" to pretend to be stupid.

Why not? Especially in a managerial position, you will occasionally need to build a rapport with people who are convinced they have good technical knowledge, but don't. Being able to talk to them productively instead of picking fights is a skill worth selecting for . If you can't figure out that the first person who's interviewing you has answers on a sheet of paper and you're supposed to parrot them until you get to…

> Being able to talk to them productively instead of picking fights is a skill worth selecting for.

Perhaps, but if the story is true, then it's wishful thinking to assume Google tried to do just that by putting a moron or someone acting like one in the recruiter chair. That way you risk hiring a quick talker who can talk, joke or laugh his/her way out of a wrong answer. If technical skills don't really matter, it's fine though.

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

#229

Earlier quoted context omitted.

I'm just reaching here, but is there a chance at all that the test wasn't really about whether or not he knew the correct answers but more that he knew the correct answers and was able to simplify them to the extent that a non-technical user could understand and compare them? I have a feeling that Google is far more interested in someone being able to get their point across than someone that just wants to sit there a…

That's not the problem, a non-tech recruiter cannot assess the correctness. Even the simplification can be done, which I disagree, the answer will be rejected because it's not a literal match. That, is the problem.

That's not the point of the test. The point of the test is to see whether or not the person attempted to get on the level of the person they were talking to. I have a feeling that the interview would have kept going had the author not started to argue. They're looking for someone that can translate, not someone that will talk down and argue just so that they can be "right".

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

#230
post #196

Earlier quoted context omitted.

"Dumb recruiter"? What? Nobody's calling the recruiter dumb. Everybody is calling the process dumb. A process that puts somebody that cannot answer these questions, in charge of asking them and evaluating the answers. Having the candidate evaluate the competence of their recruiter is not part of the interview process. What the hell.

I believe in the phone screen Google uses non-technical people to ask technical questions (as engineers are a scarce resource) so they're only able to handle "right or wrong" but you can probably work your way around that by being nice - this guy seemed to be being an ass...

[deleted]
Post reply on HN