Live data from Hacker News

Google's “Director of Engineering” Hiring Test

gwan.com

681–690 of 969 posts

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

#681

I had very similar intervies at Palantir and Yelp, albeit Yelp was understandably just a quick phone screen with a recruiter. However, the "trivia" interview at Palantir came from a forward deployed engineer on the DC based team I was interested in working with and one of my last hour long, onsite interviews of the day. Seemed like a big red flag at the time.

> the "trivia" interview at Palantir ... Seemed like a big red flag at the time.

Besides the bigger red flag that it was Palantir, you mean.

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

#682
I think the person interviewing in this article should have seen the person doing the interview was looking for short answers. It is not a perfect interview process but I am not shocked he did not get it as you can see his annoyance as the interview goes on.

He could have answered, "because Quicksort is N * lg(N)". Instead he opted to have a long answer about it depends how the algorithm is implemented. It either shows he is completely unfamiliar with big-O or he chose to give a annoyed answer. He could have also answered that there are a family of algorithms such as merge sort which are also N * lg(N).

A bit skeptical of the transcript as well. Knowing a MAC address in bytes off the top of your head? Almost every other person would first think okay how many HEX characters is it, and how many bytes in a HEX. But he has this knowledge immediately?

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

#683

Earlier quoted context omitted.

The length of an ethernet address is a trivia question. It's a good way to score a board game. Filtering out candidates based on it is lunacy.

I agree with the first and second sentence. As to the third: what would be your thought process as to someone who claimed to be a network programmer on the phone but couldn't answer most of those questions?

I think you can probably predict it: I would generate a work-sample test for it. For a network programmer, I might have them implement a 3WH coded directly to pcap_write() (which requires you to populate the Ethernet frame header). Like the best work-sample challenges, doing a raw 3WH is kind of fun if you haven't done it before.

My friends and I used to spend bar nights drinking over torturous interview questions (yes, I have always been this nerdy). For instance: we had a gruesome sequence of questions on how to implement the fastest possible traceroute that you could only clear if you knew about a trick using the IP timestamp option.

Later, I got (what I thought was) smarter about interviewing, and moved to more surgical questions. I'd ask candidates to debug a C program that segfaulted in malloc, or ask them to describe the utility functions they carried with them from project to project.

After taking over recruiting for a company that really needed to hire at a specific clip in order to balance sales and delivery, I'm embarrassed that I thought I was interviewing effectively with stuff like this.

You can't learn about someone's capabilities by putting them on the spot with trivia questions.

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

#684

Perhaps they are looking for a pointy-haired-boss type rather than someone who actually knows his thing.

Sorry, you got too many right, you're not right for this role!

Actually, come to think of it, I did have an interview experience like that, just a few years ago. At the time, my title was VP of engineering, but for a small startup. A bigger company was interested in hiring me for a VP-level (or maybe director level, I can't remember) position, and phone screened me. After about ten minutes of talking, he said, "are you sure you wouldn't be more interested in our technical architecture team? You sound like a good fit for our technical architecture team".

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

#685
post #502
post #443

I think the candidate made a simple mistake: the interviewer is always right. Your job in an interview isn't to be right or to teach the interviewer. Your job is to make the interviewer like you foremost, and second make the interview think that you're qualified. And of course no one likes being corrected or told they are wrong. In my opinion, it is better to do well on an interview and decide after the fact that you…

> the interviewer is always right That is an awful sentiment, and I find myself in violent disagreement with you. A good number of my enjoyable interviews have been with candidates who clearly knew more than I did, and could expand from an interesting detail to a short ex-tempore lecture on the topic. I cherish each of those. An interview where I, as an interviewer, learn something is a fine thing indeed.

> That is an awful sentiment, and I find myself in violent disagreement with you.

You find yourself in violent insistence that the world is the way you wish it was, rather than the way it actually is.

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

#686
post #320

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…

I would 100% back you up in my mind had it not been for the "Why Quicksort is the best sorting method?" question. I hope you'll agree that there is no way a correct answer would ever validate this question.

I'm another Google employee. I really don't think that's an accurate transcription. There's a standard SRE question which is related, but different. I won't give the exact question, but you could try searching Glassdoor.

If "Why Quicksort is the best sorting method?" really was the question, then the recruiter must have asked it from memory and misconstrued it. It's certainly not a standard Google SRE interview question.

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

#687
post #623

Earlier quoted context omitted.

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…

The number of web devs I've encountered who regard my ability to talk HTTP over telnet as black magic makes me sad.

In all fairness, if you can talk normal HTTP 1.1 over telnet with some service, someone configured TLS wrong ;) And if you can talk HTTPS over telnet unassisted... well, I am truly impressed.

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

#688

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…

This was very similar to my first experience interviewing for an SRE role at Google. After about 20 minutes I got tired of arguing with a clearly non-technical recruiter and politely excused myself. My second interview well, that was a whole different bucket of problems.

Yeah. I'll never interview with Google again. I've got friends who work in (mostly nontechnical) roles there who had very different experiences, but my interview was such a hot mess of disorganization, cluelessness and arrogance that I ended it early and told them I had no interest in the role or the company.

Two years on, I think I made the right call.

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

#689
post #672

Earlier quoted context omitted.

"They'd be internal to recruiting, so you wouldn't see them unless you were heavily involved (doing interviews and recruiting trips isn't being heavily involved)." Actually, this is a super-bad assumption, pre-screening questions, etc, are all public to google internally. There are no magic internal-to-recruiting parts to the questions, and they are in fact, listed as SRE pre-screening questions, so ...

But they appear to be changed in subtle ways from what's listed on other sites. For example, googling for: Google SRE interview questions inode returns a few hits, including: https://www.glassdoor.com/Interview/Linux-system-call-for-in... which lists the question as "system call for inode data" - which is importantly different from a system call to return an actual inode. This post says something similar: http://greg…

http://webcache.googleusercontent.com/search?q=cache:rPrtrh1...

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

#690
post #368

Earlier quoted context omitted.

So you're saying Google's recruiters don't tell what position they are interviewing for and that they found a 20+ years experienced engineering manager holding patents on computer networking under-qualified for an ordinary site maintenance position. Well, that sounds like a dumb recruitment process.

First, it is definitely standard process to tell him (if they didn't, that's a definite failure). Again, remember you only have one side of the story here. I like to try to gather facts before assuming things. IE Ready, aim, fire, not fire, ready, aim. Admittedly more difficult in this case (and certainly, i have no access to it) Second i'm going to point out a few things: Experience may translate into wisdom, it may…

>First, it is definitely standard process to tell him (if they didn't, that's a definite failure). Again, remember you only have one side of the story here.

"Standard process" is what actually happens in the real world. Alas, standard process is to not tell him.

>But everyone in this entire thread seems to be making snap judgements without a lot of critical thinking. That makes me believe a lot of people here have a ton of pre-existing biases they are projecting onto this in one direction or the other (and you are, of course, welcome to claim i fall into this category too!)

Your story is also just one side of the story - actually, you weren't even involved so it's neither side. Still, you spend all your effort on saying why for example this guy's patents mean nothing and he's likely incompetent. I'd call that snap judgement, lack of critical thinking, and biased conjecture,

Post reply on HN