[howling]

> Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off. — Max Howell (@mxcl)

If inverting a binary tree means swapping the left and right subtrees of every node, I wouldn't want to work with someone who can't do that either and Google is definitely right to reject him.

[ronia]

The actual work for which you are hiring an engineer is building a software product/service, and the Homebrew developer has a track record of delivering great results.

Rejecting the guy because he cannot do a whiteboard brain teaser is like rejecting LeBron James because he did not make a shot at the arcade basketball game.

I'm not saying the guy would be perfect. Comparing him to LeBron James might not be a great example. Google might have other reasons to reject him.

What I'm trying to say is the current coding interview is a really poor mechanism to gauge a software engineer, especially when it comes to hiring one with real-world engineering experience.

[zeroonetwothree]

Maybe he would have been a poor fit at Google. Just because you wrote some popular open source software doesn't mean you will succeed in a corporate environment. The dynamics and skills required are quite different.

Now does being able to reverse a binary tree mean that you would fail at Google? I have no idea. But we don't really know if that was the reason he was rejected, it's just his own guess. There could have been other reasons.

[hn_throwaway_99]

> What I'm trying to say is the current coding interview is a really poor mechanism to gauge a software engineer.

People like to say this, but in my experience this is not true. It's just that people misunderstand the goal of technical interviews and they often are poor at evaluating their own skills.

First off, these giant tech companies have enormous economic incentives to improve their interview processes as much as possible. They also do a pretty rigorous assessment of the effectiveness of their interview process (Google, for example, has publicized some of their data). I'm not saying these tech companies interview processes are perfect, but I also have a problem believing they're so fundamentally flawed that these companies can't figure out how to fix them given the giant economic returns they get for optimizing their hiring processes.

Moreover, as some other comments mentioned, many companies (and individuals, myself included) believe it is much worse to hire someone who ends up not cutting it, than missing out on a potentially good hire. I can list out all the reasons why, but Joel Spoelsky has a pretty famous essay from a couple decades ago on the topic that explains it well [1].

Thus, it's not surprising hearing a lot people complain that they can do the job, but they aren't good at interviews. Because, from Google's/Microsoft's/etc. perspective, they're fine with a bit higher false negative rate if they can greatly reduce their false positive rate. And my experience matches that: I have never seen a candidate who did awesome in "whiteboard-style programming questions" who couldn't cut it programming-wise (they may have had other issues, but "coding productivity" wasn't one of them). Now, I certainly believe and have seen that there are some people who aren't good at these questions who can do a job well, but there are also a ton more people who can't do the job if they can't pass a technical screen, so hiring any of these folks means much more risk.

I also think that whiteboard-style coding questions help show a quality that is very important to businesses, even if those questions don't represent "real world" work. There are basically 2 types of people that do well at these questions: people who are just naturally smart and have a ton of experience to the point that they wouldn't even need to study to do well, and people who are of more "normal" intelligence/ability, but who can do well if they study a ton. Either of those two groups would likely do well in a programming role. So often I hear the complaint "I'm a busy person, I've got outside responsibilities, you can't expect me to spend all this time studying". And that may be true, but you'll be competing against people who are willing to study, so I don't think you can fault Google et al for favoring people who show a willingness to do more preparation.

1. https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... "And in the middle, you have a large number of “maybes” who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don’t want to hire any of the maybes. Ever."

[nitwit005]

> First off, these giant tech companies have enormous economic incentives to improve their interview processes as much as possible.

But we have examples where the companies themselves have admitted that their past interview practices turned out not to work: https://business.time.com/2012/10/23/no-brainer-brainteaser-...

> They also do a pretty rigorous assessment of the effectiveness of their interview process

Companies do review their hiring processes, but actual experiments and data seem fairly rare. It's harder than you think. What experiment would you run? Hire a group of people entirely randomly, and compare their performance reviews after 2 years?

[hn_throwaway_99]

> But we have examples where the companies themselves have admitted that their past interview practices turned out not to work: https://business.time.com/2012/10/23/no-brainer-brainteaser-...

That's pretty much exactly my point. In the 90s, wide-scale hiring for software engineers was a relatively new thing - many companies were just figuring it out. And so they did some shit pretty early on that didn't make sense. But for all the times I hear folks pulling out the "Why are manhole covers round?" and "How many cars are there in Manhattan?" examples, I haven't heard these types of brainteaser questions being used for nearly 2 decades.

I'm not arguing that the FAANGs have some perfect, unassailable interview process that can never be improved, but I am arguing that so often I hear grumbling discontent from people who don't like the interview process, but rarely do I see much examination around why those particular hiring processes appear to work fairly well for the likes of Google, Apple, etc.

[nitwit005]

Those puzzle questions weren't just used to hire software engineers. Hiring fads sweep corporate America, despite no evidence of effectiveness, and despite economic incentives to hire well.

Yes, they did move away from it, but that doesn't mean we aren't now in the grip of equally bad fads.

> but rarely do I see much examination around why those particular hiring processes appear to work fairly well for the likes of Google, Apple, etc.

You assume they work well, but you don't have any data to support that. That's sort of assumption is basically where these hiring fads come from.

[regularjack]

Not knowing how to do something from the top of your head is not the same thing as not being able to do it.

[deathanatos]

… but that's an interview. If you cannot, within the time, demonstrate any ability, why should you be hired?

The question above, as clarified, is not complicated, nor does it rely on memorization or some "trick": anyone purporting to be a SWE should be able to write an essentially de novo solution to it.

(And in my own technical interviews, there are multiple questions, to specifically hedge against any one being "that one question a good candidate is going to miss because it's just not their day". It doesn't happen: it's either all or nothing.)

[bobleeswagger]

> If you cannot, within the time, demonstrate any ability, why should you be hired?

It is more likely that the interview process is broken and missing the right candidates, than it is that the interviewees are all mediocre. Most interviews are very non-inclusive the same way that the main track of school is becoming less and less inclusive. Different people need different methods to bring out the best in them.

[hn_throwaway_99]

> It is more likely that the interview process is broken and missing the right candidates, than it is that the interviewees are all mediocre.

Here's a thought experiment for you: if the interview process is so broken, why hasn't some tech company succeeded and become famous for an improved interview process, e.g. "Moneyball style"? My guess is because the process is not actually that broken, at least from the employer's perspective. I'm sure the interview process could be changed to be less regimented and more "inclusive", but that's also likely to reduce it's predictive power (i.e. you're more likely to make bad hires, and from a company's perspective that's almost always worse than missing out on a great hire).

[bobleeswagger]

> if the interview process is so broken

Hiring is guessing. Firing is knowing. If the hiring process worked, we wouldn't have layoffs like we do.

[deathanatos]

The layoffs that I have seen reported have been reported as being random. I've been involved now in 3 layoffs directly in my career, and 100% of them, the laid off individuals were laid off without regards to skill. The reporting in the media on layoffs happening elsewhere largely matches my experience.

Sure, an argument exists around "you shouldn't've hired that many people", but that is different from an argument of "the hiring process can't discern good hires". The former is a management & long-term planning issue, the latter is how interviews are conducted.

[jmd42]

I'm on the same page.

Sure, your day-to-day work may not involve manipulating binary trees. But presumably it does involve working with variables, objects, references, manipulating data of some kind... And if you're comfortable with the fundamentals of those, then this is something you should be able to figure out even if you've never heard of a "binary tree" before, once somebody has sketched it or shown you the definition of their TreeNode class, right?

It honestly baffles me how people consider this something which needs to be drilled or memorized.

There are absolutely algorithmic questions which would fall into that category. But if somebody considers this to be one of them - or something like "find the smallest number in an array" - then I have to question whether they have an understanding of the most fundamental concepts in programming...

Or if they get through each day solely using things they've memorized by rote, or looked up, and they don't really have any idea how any of the foundations they're building on actually operate.

[sophonX]

So hire a baby ? That'll eventually do in 20 years ..... works, right ?

[lubujackson]

That is a fine and common opinion, but just one question: how often have you inverted a binary tree at your job? Because after nearly 20 years it hasn't come up once for me. I am sure for some roles it is a necessary skill but my issue is that most of these questions are more or less toy problems that come from academia and not business. They are a great test of your retention of a data structure class but not super relevant beyond that.

I would rather hire an engineer with a strong business or user sense - reading between the lines of requests and anticipating future issues or uses adds so much more value in a real sense.

To me, these are great entry level questions because it is a good baseline for new grads when you have little work experience to judge. Past that, it is like making a lawyer take a mini bar exam for every new job - a waste of effort if you want to hire for specific skills and experience.

[sophonX]

Just because you haven't worked in a team that requires those skills doesn't mean they aren't valuable.

In my old team, I had to come up with a coupon distribution logic based on count, percentage, time, then generating reproducable random values that required to deep dive (algorithm) into library code & explicitly storing state in redis, then an application of dynamic programming in building as custom platform, atomic token validation, custom rate limiter algo, state machine, scheduler, distributed circuit breaker, etc.

In my current team, I had to read raft paper, zab paper, look into their implementation, make a poc with raft protocol, then autoscaling algorithms, scheduler algo's, different data structures, heck even the oss engine itself is DAG, heavy threads + concurrency stuff. Even now I come across new data structures and algorithms.

Clearly you don't know the entire industry, just because you haven't worked in such teams, doesn't mean these aren't important.

You are experienced in a bubble. The hiring bar for our team is higher than other teams and heck even for SDE3 - the requirement is higher. You would be very much surprised to know that even the senior members have research publications and deal with complex stuff.

Core teams like in AWS or GCP or Azure solve these sort of problems.

Who do you think will solve autoscaling (that's what I'm doing now) or managed scaling or network or security or any infra problems in these cloud platforms ?

As experience increases, we expect more knowledge & insights - doesn't mean to ignore basic coding stuff like arrays or linked lists or trees or graphs or simple message queues or etc.

If companies are paying competitive TC and there are multiple candidates, why not hire a smart person ? What's so special about doing regular normal stuff ? That's just a normal dev right ?

[howling]

None, but I have written code that requires more data structure and algorithm knowledge than inverting a binary tree (at my job).

[skybrian]

Sure, but job isn't to write Homebrew either, so it just seems like a bad example all around.

(I'm not sure Homebrew is all that well engineered, actually. Hard to tell, but I've had trouble with it and avoid it.)

I think what it comes down to is that nobody really knows what to interview for.

[zeroonetwothree]

Just last week I had to implement a common graph algorithm from scratch to solve a business problem (basically topological sort, with a minor variation). It's certainly much harder than reversing a binary tree (which is one of the easiest possible interview questions you could imagine).

Generally it wouldn't really make sense to reverse a tree in practice (why not just build it the other way initially?) but it has a similar structure to other tree traversal things that could actually come up so it's reasonable to ask.

[neon_electro]

For every one of you, do you think there are more engineers doing things just like you or do you think there are more engineers who never have to do a binary sort and can still lead a perfectly satisfying, fulfilling career?

[sophonX]

So if you are just doing normal stuff, then why should anyone pay competitive TC ? That's just a normal dev, right ? What's so special or talented about you ?

Companies that pay huge TC want to hire smart people not just an average joe. Sure, you can live satisfying career and that's your pov.

What about a company's pov ? Did you ever think about it ?

[dekhn]

Wouldn't that be a "mirror" operation, while inversion would be (I dunno) swapping the direction of the edges?

I went out of my way to avoid homebrew (still do) when I worked at google because it would reliably fail to complete some key operations in a dag, hence the interest in ensuring developers know how to do CS things.

[howling]

Yeah it's not clear what he was asked. Swapping the direction of every edge of a binary tree would result in a DAG that is likely no longer a binary tree though.

[gifnamething]

Are you confusing a binary tree with something else?

Here's an example:

https://leetcode.com/problems/invert-binary-tree/

It's an 'easy' question. The solution is <10 lines.

[zeroonetwothree]

Yeah it's really easy. I wrote a correct solution in about 30 seconds on my first try. And I haven't actually practiced these problems for 10+ years.

[virtuous_signal]

"Mirror" is what this question is generally understood to be asking. I don't think swapping the direction of the edges produces a tree in general although it would produce a DAG. I think "invert" could mean "mirror" or turn upside-down depending on the context.

[dekhn]

Personally, if I were asked this, I would just say "convert the graph to a matrix, invert the matrix, and then convert the resulting inverted matrix back to a graph", and let them try to figure out if that would work for a bit before joking "oh come on, preorder traversal with a temp var, do you have a more interesting question?"

[karmakaze]

It would be more leetcode to be given an ordered binary tree and asked to reverse it O(N). It's a lot more fair to the interviewee to be given the explicit task without knowing 'the trick' unless one considers knowing recursive functions to be a trick.

[sophonX]

There you go ! This comment should be highlighted.

[devnullbrain]

It doesn't matter, the candidate should ask for clarification if the question is ambiguous.

[sophonX]

I was referring to second para or statement. (-_-)

[photonbeam]

Most of us havent touched a tree structure since college, because there are other, real, problems out there. Trying to remember, or rederive it from scratch is slower and error-prone and bad for interviews

[sophonX]

You are just ignorant and naive.

Tree structure ? json, xml, protobuf, classes, functional programming, databases with foreign key, database internals, etc ?

Oh I forgot you also serialize and deserialize data - did you forget how that works ? Tree traversal again.

Do you know how organizationl hierarchy is structure ? It's a tree.

Do you know various maps and their usages ? We use them daily - it's very very important to know their internals. Hashing vs Trees vs Linked hash vs etc.

Google maps ? n-d trees ? Comparing data - merkel trees ? etc.

Every dev out there has common work with mine. But you won't be able to solve the problems that I face on a daily basis without thinking hard & without this dsa + concurrency knowledge.

Now, is it reasonable to ask these questions ? Heck yes.

[yks]

JSON is also a tree structure. Granted one rarely inverts it, but “no trees in the real world” is not true.

[devnullbrain]

Then most of us aren't suitable for jobs where this stuff is important. Google does have 'real' problems involving trees.

[GeneralMayhem]

Also, I don't believe that 90% of Google engineers use Homebrew. I'm not sure I'd believe 9%. Google is a Linux shop with its own internal package repo. Even if you're using a Macbook to work remotely, you're using it as a fancy terminal wrapper to connect to a Debian-based system to do your real work.

[sophonX]

Yeah it's such a basic structure we use in-directly - in classes & sub-classes, intellij dependency list on left side, using google maps, etc.

How complex is homebrew ? Can no one else replicate it ? Why should a company hire for something you did that's simple ?

What are the skills he posses that no one else has ?

Learn your basica dsa stuff for gods sake people.

[onion2k]

Judging by Google's track record, hiring some people who have demonstrated an ability to launch and maintain a piece of software would bring a skillset they desparately need. Google engineers are incapable of keeping much going for the long term.

[Jensson]

It is managers who decides what project dies or lives, not engineers.

[sophonX]

That's a problem in every company ? How do you know they don't need smart people ? Do you've any public stats or reasonable justification ?