Hacker News Reader

Comment by rademacher | Hacker News Reader

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 that this person is willing to commit to performing well at something that is reasonably challenging. The end result is that they are trying to hire worker bees. This makes sense as the bulk of work at any large company is largely mundane and relatively routine. I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense, although at that point the candidate is already well known in the industry most likely.

View on HN

It is true that you will almost never work with somebody who interviewed you.

In some ways, this is absolutely terribly for hiring. I worked in a part of Google where domain specific knowledge was key, and it was next to impossible to hire people because nobody on our team could interview them "officially". So we'd pre-screen people with the knowledge we needed, and then pass them off to others to officially interview. They would almost invariably fail, because their non domain-specific knowledge was not in the top 1% or whatever it takes to pass a generic interview. So we were left with the choice between hiring contractors, or training somebody internal who could leave at any time. We hired contractors.

EDIT: See the sibling comment regarding the homebrew author. This situation was exactly like that. Imagine wanting to hire somebody to make an internal package manager, and not being allowed to hire the author of one of the most popular package managers because his whiteboarding skills were lackluster, so he got a poor interview score from people that have no idea (or concern) what he does or what he's being hired to do.

I work in a startup, with a team of 8, and you will 100% work with those that interview you :)

> I worked in a part of Google where domain specific knowledge was key, and it was next to impossible to hire people because nobody on our team could interview them "officially".

When a company policy is so obviously broken in this way and there is no way to route around it then something is very broken.

Here's how it should work. You explain the issue above to someone above you and they either have the authority to get round it or they pass it on to someone who does.

If a policy is failing in such a profound way and nobody can change it this implies a level of organisational dysfunction that must be affecting multiple aspects of the company.

One way to route around it is to acquire a company with the needed expertise. However, it needs to be a large-ish company. There is some cutoff beyond which engineers from acquired companies do not need to re-interview for their jobs. It is somewhere between 10 person startup and Motorola, but I have no idea where.

I don't think a way to route around it for an individual position or candidate exists.

You should see if there's way to circumvent HR or even have them work with you on hiring candidates. At my company, all engineers are VERY involved in the hiring process when it comes to new additions to the team.

My experience confirms this as well. I’ve interviewed at most FAANGs and many others, and made multiple attempts at some. Brute-force practice (e.g. leetcode problems) and memorization is the only thing that ultimately worked.

It would be nice if interviews really were a “collaborative” experience to see “how you think” where finding the optimal answer “doesn’t matter”. But it 100% does.

Years ago, I had the rare experience of being told why I didn't get an offer from a big Valley tech company. (Not FAANG, but perceived similarly.) It was for an internship, and I suspect they wanted to keep candidates interested for full time applications.

The relevant interview was a "find the palindrome" question for which the desired answer was Rabin-Karp. The rejection was explicitly "your solution to the whiteboard algorithm question worked but wasn't optimal, so study your algorithms harder and try again in the future".

At the time, I thought it was pretty stupid that they tried to judge skill by requiring candidates to either have one random thing memorized or reinvent a publication-worthy algorithm in 30 minutes. But given the advice I got, it seems like the core motivation was "we want people who are willing to devote a bunch of free time solely to impressing us". And for that, asking impractical questions and demanding optimal answers works perfectly.

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.

I wasn't implying that the interview was easier for candidates with recognizable track records. Perhaps two sigma was not restrictive enough. I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk.

Do you really want to remove bias for experienced candidates with a track record of substantial and nontrivial contributions?

> I was merely suggesting that if a candidate has domain expertise and it is well known, that they may not subjected to the same leetcode hoop jumping as the bulk.

To put in bluntly, if you are such a candidate you are expected to know your algorithms cold and be expected to field your domain specific questions. So if you're a well-known compiler designer you would still need to know how to wield algorithms/datastructures for parts of the interview loop and then get into detail about compilers in the domain-specific parts of the loop.

That being said, it totally depends on the position you're interviewing for. If you're interviewing for Director/VP role in an engineering ladder, then some of the interview will need to be repurposed to getting signals about leadership and impact. That doesn't mean that you don't code at all though, it just means that the focus/weightage will be moved towards other dimensions (in addition to evaluating your system design and coding skills).

> you are expected to know your algorithms cold and be expected to field your domain specific questions

...why?

You're holding candidates to high standards, fine, that's great. Compiler designers even need some deep algorithms and datastructures knowledge; you can't ensure your hashes are thread-safe unless you know exactly what they are, how they handle collisions, and so on. All that's totally fair to ask as part of their domain knowledge.

But the criticism of this sort of interviewing (and Google in particular) overwhelmingly describes interviewers judging domain experts on whatever algorithms puzzle they give every candidate from every domain. Why do we care whether a compiler design expert remembers how to implement Ford–Fulkerson on a whiteboard? Is there any reason to think that's predictive of talent? Might it even be anti-predictive because it favors generalists?

Google (and FAANG, and everyone else in that league) hires great people. I don't doubt that. But it was also hiring great people back when it posed random brainteasers and emphasized GPA, and Google has publicly said those things turned out to be totally uninformative. If you filter down to a list with more highly-qualified candidates than you can hire, I think there's a tendency to come up with random extra hurdles to avoid resorting to a coinflip that might work just as well.

Without getting too pedantic, it can be difficult to define what encompasses "expertise". You could have worked on some backend payment system for years and conclude that you're a payment "expert". But that means different things to different people.

Not all current "experts" are necessarily hired into corresponding roles needing the same expertise. To put it more concretely with an example, it's entirely possible for you to be a payment system expert but have a recruiter reach out to you for a general SWE role (you're welcome to decline). The slate of roles that do require said expertise are limited. If there's 10 qualified candidates, they could all technically pass the hiring bar. But if there's only 7 positions that require that exact expertise, then what happens to the other 3? Well, they're broadcast to "matching" teams that have available headcount. This "match" could be approximate, but it underscores why getting a signal beyond just the domain expertise is important.

We could of course debate whether something "advanced" should be asked, but that would require us to agree on what constitutes "advanced". In general, it's difficult to pin point some threshold and unanimously agree that that's the level of difficulty of generalist SWE questions that a domain expert should get asked. For what it's worth, there's additional intervention by committee(s) that look at this on a case-by-case basis to make sure that everything's on an even keel. Concretely, if you're an ML expert interviewing for a role that specifically demands ML-expertise and you were asked some advanced question about data structures (ex: something needing the Hungarian algorithm) and you're upset that you bombed it, the don't be; the committee(s) would weigh that interview's score less if they expect something alone the lines of Maps/Queues to be asked instead. These are all made up examples, but I hope that it conveys why there's a need to extract signal beyond just core-expertise. Google doesn't just artificially create hurdles for sadistic pleasure ¯\_(ツ)_/¯

Disclaimer: I haven't read the article, but I work at Google.

Most interviewers will ask the same question to multiple candidates. They will compare how you the candidate is doing compared to other candidates on the same question. Most interviewers will provide hints.

I'm pretty sure that all candidates go though the same interview process.

There is really not much that is unique to Google's interviews. The only thing that is unique about the process is that your interview feedback is reviewed by a committee of peers.

> There is really not much that is unique to Google's interviews

Having just gone through 10 days of on-site interviews (including two at Google), there are some things that are peculiar Google's process:

- No talk about software engineering,

- No talk about software design,

- No talk about project management, working on a team, culture of any kind, caring about customers etc etc...,

- No debugging,

- No using unfamiliar APIs, no reading documentation,

- No actually running any code.

In particular, Google was the only place I didn't actually test and run my code. It was the only place where I was given the option of doing all of my work on the whiteboard, too.

At least one time I had convinced my interviewer I had a working solution and then realised it didn't work and had to convince them of that...

> It was the only place where I was given the option of doing all of my work on the whiteboard, too.

I just interviewed at Facebook, and I was only given the option of doing all my work on a whiteboard. I hate that medium for writing code (or any dense text, really).

Hmm. I programmed on my own laptop (and ran the code) at Instacart, Apple, Airbnb, Dropbox, Stripe, Cruise, Flexport and Benchling. Late September/October this year.

At Google I wasn't allowed to bring my laptop, but they let me "program" in a text editor with syntax highlighting and automatic indentation. Most of the interviewers hadn't seen that before though.

I interviewed at Facebook, Snapchat, Apple, Pinterest, LinkedIn and startups. The coding interviews were exactly the same. This was less than 3 years ago.

The first two depend on the level you are interviewing for. If you're going for senior positions, you will have system design interviews.

The others, ehh, practically every interview I've conducted has had some debugging when people encounter issues in the code they wrote. Sure you're not spelunking logs or stack traces, but reasoning about what causes an issue on a smaller scale is still useful signal.

>The only thing that is unique about the process is that your interview feedback is reviewed by a committee of peers.

I wouldn't even say that sounds unique, as I was at multiple companies 20+ years ago that did the same.

'I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense'

Can testify to this, interviewed via referral, was still asked some algo-trivia, didn't do too well on that but still got a decent offer, mainly because referee vouched for me based on their experience working with me.

Either (a) they want you or (b) they want someone like you. If (a), they find any reason for hiring you, if (b) they find any reason for not hiring you. This explains most of the interview dynamics, especially at large companies.

Actually you just have to say "Hashtable" three times and they have to give you a job.

Actually the spell is „hashtable hashtable stack pop pop push”.

Didnt the creator of home-brew not end up getting a job at google?

That 2015 tweet (https://twitter.com/mxcl/status/608682016205344768?s=21) helped popularize the Google Interview memes, but things like Cracking the Code Interview still existed long before then.

One of the reply tweets linked an allegorical article about the pitfalls of whiteboard interviewing that I enjoyed quite a bit: http://www.unlimitednovelty.com/2011/12/can-you-solve-this-p...

It’s totally fair to slag on whiteboard interviews, I hate them too. But it’s worth pointing out that there aren’t any great options out there.

The traditional sit and have a chat interview is insanely biased towards people like the interviewer and doesn’t at all guarantee technical competence. The take home project feels like a big imposition to a lot of people, especially those that are currently employed, and raises concerns about cheating. The whiteboard interview except on a laptop has some advantages but has problems of comfort with the environment.

I think a whiteboard or laptop interview with a cleaned up realistic problem, not a thinly disguised implement Dijkstra’s, is the least bad option around.

Strongly prefer the take-home project as long as it is confined to less than 4 hours. The gun-to-head aspect of the other choices significantly dominates other concerns in my experience.

That creme brulee article was delicious, thanks for sharing!!

I always see this trotted out as proof of how bad Google’s interview process is, and I always wonder: what makes people think creating homebrew was particularly difficult or impressive? Package managers are a dime a dozen.

It has also never been conclusively explained what “invert a binary tree” means (see the tweet a sibling comment linked to — that’s what the Homebrew guy claimed he wasn’t hired for not being able to do).

There are more people in the world using homebrew than what most of Google engineers single handedly wrangled or produced -- excluding google products that came out of Google Labs that we now use. So if you want someone who can take shitty lemons and create a tasty lemonade out of it he is definitely your guy.

Here's the thing - outside some special projects for which people are hired without going through the standard interview process Google does not want those who can take shitty lemons and convert them to tasty lemonade. Google wants specific kinds of butts that fit into a specific kind of seat. It wants the most homogeneous high output monkeys that would do what they are told, such as spitting out a code to invert a binary tree.

Package management is a task filled with subtle pitfalls that is much, much harder than it looks on the surface.

It's a lot like syncing files - e.g. how Dropbox looked similarly deceptively easy to build but really wasnt.

IMHO the fact that the homebrew guy didn't get hired and that golang package management was a dumpster fire for years isn't coincidental. Both were part and parcel of a systemic bias that plagues Google's culture that they're blissfully unaware of.

Google doesn’t do package management well because they don’t do package management at all; they have a monorepo. If anything, the systematic bias is that Google built their way around an entire class of problems that others still face.

This has something to do with why the Go team waited so long to solve package management. Having little experience with it, they tried leaving it to the community.

But I don't think you can generalize to the whole company. For example, the Dart package manager is pretty nice.

I agree, to some extent. It's not terribly difficult to make a package manager. But it's a strong positive signal: it's hard for someone who is really bad at software to design a popular system like that. Also, it's unlikely for someone who is a really bad employee to take the initiative to even execute a task like that.

Regardless, I don't think qualifications like this should bypass the interview. The author almost sounded a little entitled when describing the rejection. That said, I don't think his achievements got sufficient weight while evaluating him as a candidate.

See my comment [1] regarding what these interviews are selecting for -- it might be a bad process, but it might come closer to the intended goals than other processes do.

[1] https://news.ycombinator.com/item?id=18382384

Why shouldn't major accomplishments bypass the "random algo from a hat" that Software Engineering interviews have devolved into? If someone is a core contributor to a large, highly successful open source project, you have concrete proof of practical experience that you can discuss with the candidate. I'd put 100x more weight on that versus his ability to invert a binary tree on the spot.

I realize you asked about people in general and not Howell himself, but he said[1] almost exactly that about his product:

Well, no I didn't [write something worthy of Google]. I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly.

But he goes on:

On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user. When things go wrong with Homebrew it tries as hard as it can to tell you why, it searches GitHub for similar issues and points you to them. It cares about you.

1. https://www.quora.com/Whats-the-logic-behind-Google-rejectin... (Quora link, sorry)

Definitely a bad fit for Google, they aren't especially well known for caring about user experience or the user these days... (/s)

That sounds like he would make a mediocre software engineer but an excellent product manager.

I think the fact that he was able to recognize all the faults (and can therefore correct) in his package manager shows a great level of competency. The fact that he was able to productize his learning experience in the form of homebrew makes him all the more impressive.

You can also set up cloud storage quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. Yet, the Homebrew guy went out and made a package manager actually getting used but still couldn't get past Google's abysmal interviewing process.

I love how you belittle one of the most successful package manager systems out there..

We can apply the same logic to almost anything.. Because nothing is truly original and "difficult/impressive" are pretty broad metrics. Feel free to give us your definition.

Software engineering is about building functional systems for humans. Quite frankly, Google needs to hire more people that are able to deliver products that actually work.. From the looks of it, hiring people that can solve "impressive" and "difficult" sorting algo puzzles yield to the Sluggish Gmail mess we have at the moment.

Maybe google needs to start hiring competent people instead of anyone that can recite the corporate gospel.

Just my 2c.

so much this!

in my job i've dealt with dozens of Google engineers across a few teams... 95%+ of the time I don't get useful answers, and sometimes no answer at all. We have found many bugs in their systems, as well as broken API endpoints that did not work as advertised. Dealing with one issue right now that no one at google has been able to assist with in over 12 months. Of course with all the turn around on some teams, the issues just keep getting passed to the next guy.

they are by far the worst of the FAANG-level engineering teams we deal with, competency is severely lacking.

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.

That sucks. Remember, you're interviewing them as much as they're interviewing you.

For what it's worth, all my Google interviewers were nice.

Interesting. Two of the interviews in my onsite loop at Google felt test; one of them was incredibly disinterested and unhelpful - by far the worst interviewer I've ever had.

I haven't bothered with Google this time around - combine the risk of jerk interviewers with the glacial pace of their interview process and it's not really something I'm interested in doing. And that's not even considering any personal reservations regarding the Damore firing or the massive payout to Rubin.

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

This guy’s response to not being offered a job validated the decision.

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.

> I'm willing to bet that when a company wants to hire a two sigma candidate they don't go through all this nonsense

As a commenter mentioned in a different thread, two sigmas get acqui-hired. I remember reading about FB acquisition of Instagram/WhatsApp, there was a requirement that they had some understanding of cs concepts.

Reply on news.ycombinator.com