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

Google's interview system: it's not about solving the problem

threader.app

Post reply on HN
Print view View original

341–350 of 432 posts

Re: Google's interview system: it's not about solving the problem

#341

Post by C1sc0cat »

dpark wrote: post #243
C1sc0cat wrote: post #229

Earlier quoted context omitted.

And how would an outsider have any idea of the cost do you just mean the plant costs how much does google pay per MW in each locale how much does labour costs what allowance for accrued pension rights.

Costs to Google are not magically different. You can make estimates without insider knowledge, but as in the window cleaner example, your estimates will be as bad as your assumptions. You can also make estimates for compute, network, and storage costs based on the prices Google charged its Cloud customers for the same.

Ah and exactly where in a CS course do you get into the economics of large scale telecoms / networking infrastructure pray?

Let alone the economics of personnel costs or the non standard way google builds its infrastructure.

Re: Google's interview system: it's not about solving the problem

#342

Post by UncleMeat »

rademacher wrote: post #218

All anecdotal evidence points to arriving at the correct, optimal solution as being key to passing the interview. It also seems like often times the interviewers are not even going to be working with the candidate so their opinion on a 'working relationship' is mostly irrelevant. The objective of asking these leetcode style questions is to find candidates who are willing to put in the time to study. Success signals t…

Anecdotal evidence from an interviewer. Maybe 5% of candidates hit the optimal solution for my problem. It is absolutely 100% not necessary in order to do well in my interviews.

Re: Google's interview system: it's not about solving the problem

#343

Post by jandrewrogers »

akudha wrote: post #211
Someone1234 wrote: post #5

> Your interviewers try to understand what it feels like to work with you on a daily basis. If that were true then why not simulate those situations rather than riddles, google-able CS trivia, or whatever the interview flavor of the month is? I'd actually argue that for many companies this post is true (i.e. that getting it "right" is less important than the journey) but I still won't forgive companies that design th…

5-6 years ago, I went for an interview in a real estate company. The introductions lasted all of 2 mins. Then they took me to a computer, showed me a bug in the code base that I would be working on, if I got hired. Then they said "please fix this". Took me about half hour or so to hunt the bug down and fix (it wasn't hard, but it wasn't a cosmetic bug either). Then they asked me how I found the bug. I explained, they…

Netflix hired me in a similar fashion. I would also characterize it as the "best interview ever".

I had a two-hour session with senior tech leads solely about solving a specific severe scalability issue in one of their database systems that they had not made much progress on. I showed them how I'd solve it using a technique unfamiliar to them. Next day, I get a "when do you want to start?" call -- they tried my proposed solution in a test environment and it had worked as advertised.

Two hours solving one real-world design problem in my area of expertise. Simple and on point, without any trace of culture fit, leet code, random whiteboarding puzzles, etc.

Re: Google's interview system: it's not about solving the problem

#344

Post by UncleMeat »

seattle_spring wrote: post #322
CydeWeys wrote: post #303

Earlier quoted context omitted.

I've seen people who otherwise did well at the coding parts of the interview not get an offer because they came off as a jerk, and no one wants to work with a jerk. There's way more to hiring decisions than raw engineering talent. Teamwork matters a lot too.

Ironic, considering 3 of my interviewers during my last on-site with Google were complete jerks.

Give that feedback to your recruiter. Committees can tell interviewers to get more training.

Re: Google's interview system: it's not about solving the problem

#345

Post by dpark »

C1sc0cat wrote: post #341
dpark wrote: post #243

Earlier quoted context omitted.

Costs to Google are not magically different. You can make estimates without insider knowledge, but as in the window cleaner example, your estimates will be as bad as your assumptions. You can also make estimates for compute, network, and storage costs based on the prices Google charged its Cloud customers for the same.

Ah and exactly where in a CS course do you get into the economics of large scale telecoms / networking infrastructure pray? Let alone the economics of personnel costs or the non standard way google builds its infrastructure.

You don't. The exercise is in estimation. This is specifically not a case of the interviewer looking for you to get the "right" answer. The interviewer likely doesn't even know what the right answer is. They want to see if you can make back-of-the-envelope calculations and if you're capable of making sane (if inaccurate) assumptions.

Make a guess at total cost for an hour of compute time and how long it might take to transcode the average video. Guess at how many videos are uploaded on a typical day. Guess at how much the typical SRE costs Google and how many SREs YouTube employs. Do the same for software engineers, or explicitly exclude R&D. Guess at networking, storage, etc. Then roll all that together with some hours of video * (cost to transcode + cost to storage + cost to upload + cost to playback * average viewers) + sre cost +.... Bonus points if you can account for elasticity and peak load instead of just averages.

The point is to show that you can think through the problem. If all you can say is "I don't know what your networking costs are", then you come across as useless.

Re: Google's interview system: it's not about solving the problem

#346

Post by chumboslice »

JeremyBanks wrote: post #228
esoterica wrote: post #65

Anyone who interviews at a "prestigious" company and then complains about how difficult the interview is kind of hypocritical. Google, and other FAANGs/unicorns, make you solve hard algorithms questions because they believe - correctly or wrongly - that in order to succeed as a company they have to filter out the vast majority of candidates who have poor algorithmic skills. They also pay a lot of money because that's…

We’re not complaining that they’re difficult, we’re complaining that they’re stupid and a poor measure. This isn’t jealousy: I was hired by Google twice, but comparing my interviews and outcomes with friends and later coworkers, it seems like I just got luckier twice, and they dropped some way more talented people on the floor. The process is a total crapshoot, but like many things at the company nobody senior enough…

I struggle to find evidence that this is any better anywhere else. At almost every other company I've worked at, the interview process was more about the referral itself (which leads to some pretty awful hires), or whether you can fake it til you make it.

Talent is not a single measure at Google. There are multiple facets to whether Google believes a candidate is solid. Strong technical talent is not an indicator of success, rather just one aspect of it that's taken into consideration by the hiring committees. So yeah, Google will say no to incredibly talented people because they fall short in other areas.

Crapshoot is table stakes practically everywhere you go. At least Google makes an attempt at making things objective and holistic.

There's a lot of myopia in this thread.

Re: Google's interview system: it's not about solving the problem

#347

Post by fizwhiz »

rademacher wrote: post #218

All anecdotal evidence points to arriving at the correct, optimal solution as being key to passing the interview. It also seems like often times the interviewers are not even going to be working with the candidate so their opinion on a 'working relationship' is mostly irrelevant. The objective of asking these leetcode style questions is to find candidates who are willing to put in the time to study. Success signals t…

As someone who conducts interviews frequently on behalf of Google, I'm in a position to categorically reject your claim that someone with {PRESTIGIOUS_COMPANY_X || INDUSTRY_REPUTATION} is given an easier path. Please note that I haven't interviewed anyone with 30+ years of experience (yet) and I only interview candidates for SWE roles (not Research Scientist roles) so view my experience from that lens since because I still think it's applicable to a majority of the crowd here on HN.

Everyone (regardless of background) has to sing for their supper, so to speak. Sure, having good pedigree can make it easier to get scheduled for an interview, but that in no way means you're slated to have interviews with people who will handle you with kid-gloves. On the contrary, the whole process is designed to zap out any bias and cover a large amount of breadth. Interviewers have questions they're calibrated themselves on, and if they get picked for the loop they just usually ask those questions. This is true from the phone screen all the way through the on-site.

You may feel that established engineers cross-pollinating from other competitive companies don't have to jump through as many hoops but that's only because they've been through this rodeo enough to know how to prepare for it well. Many are hobbyist competitive programmers and people who build stuff on the side so the interview questions don't blindside them completely.

Re: Google's interview system: it's not about solving the problem

#348

Post by clarry »

xorcist wrote: post #201
ganeshkrishnan wrote: post #95

Earlier quoted context omitted.

This is really absurd question to ask. Besides kill -s SIGTERM or even htop does the job. But like other commenters have pointed out the questions really depends on the person as there is no specific decided questions.

I sympathize with the general idea however this specific question isn't very representative of it. Signals 9 and 15 and much more well known by their respective value than their symbolic name. They are everywhere in program output and log files and if those things are your daily work then you recognize this whether you want to or not. It's like if you have touched computer code in any language then you probably know…

> Signals 9 and 15 and much more well known by their respective value than their symbolic name. They are everywhere in program output and log files

I have never written a program that outputs a signal number to stderr or a log file. And grepping the logs on a server with nearly 800 days of uptime, I can find only five references to signal 15, from months ago.

> It's like if you have touched computer code in any language then you probably know that 65 is A. [..] a programmer who never stumbled on ascii codes must have lived in an unusually insular bubble.

20 years of programming and doing things like making custom fonts. I couldn't remember the ascii code of 'A'.

Re: Google's interview system: it's not about solving the problem

#349

Post by UncleMeat »

seanmcdirmid wrote: post #269
babesh wrote: post #83

Earlier quoted context omitted.

Asking a question well takes skill. It is possible that an interviewer screwed up asking the question rather than that the candidate screwed up. Most interview systems don't have a systematic, ongoing way for accounting for this especially given that interviewers are self reporting. In my opinion, most interviewers are undertrained/underskilled at asking specific questions and at interviewing in general. They don't i…

It’s almost as if interviewers need to be tested as well. An interviewing contest where a faux candidate rates interviewers and suggests area for improvement. Of course, that would be rediculously expensive, so at best some canned training is used instead. Still, it might make sense for higher value teams.

At Google, responses are calibrated against other interviews that interviewer has done. If they have some consistent skew then this can be adjusted for. If the interviewer sucks and the committee can tell then they can give that score less weight.

Re: Google's interview system: it's not about solving the problem

#350

Post by Kephael »

This is ridiculous, you will be given a no hire recommendation by the interviewer at a FAANG company if you do not provide an optimal solution. This is very well documented on sites/apps like Blind and accurate from my personal experience. It's corporate double speak to state otherwise.

Can't give an O(N) solution but come up with a correct O(N^2) solution? Too bad - go do more Leetcode.

Post reply on HN