This resonates.

I'm terrible at big tech company interviews--kind of a generalist, read Cicero rather than Knuth in college, tend to start out problems kind of muddled, etc. After a while I concluded the only way to get into large SV companies was to sell a company to them. It's easier to go through due diligence than the corporate interview process in a lot of places.

(That's how I got my current job.)

I spent most of my college evening getting drunk with philosophy majors and pretending my math degree meant more than my CS fallback -- but I haven't found the corporate interview system to be that terrible.

I do however think it's a game that conflicts with certain personality types, including myself early in my career.

I'm always curious what you (or anyone else!) think could be done better.

In my experience SV corporate interview processes are biased in a couple of ways that lead to more homogeneneous and potentially weaker teams.

1.) They select using criteria that are easy to test, such as writing quicksort on the fly. That's a small part of engineering --you also want people who can recognize big-picture patterns and communicate them clearly. This is a lot harder to evaluate so many interviewers simply don't.

2.) They select for people who are already in similar positions. For instance, white-boarding kubernetes application design is pretty easy if you are already doing it. As an interviewer it does not really tell me much about your ability to think originally or whether you can adapt.

Getting around these biases is hard. One way I test people now is to ask them to show me their favorite design or code and explain exactly how it works. That starts them off on comfortable ground. Then I start to tweak the boundary conditions to see if they can adjust creatively. It removes the stress factor and is a lot more illuminating than coding up something totally new from scratch, especially if you only have 45 minutes to extract as much information as possible about somebody's thought processes.

Very interested in other thoughts on this topic. It's a hard problem.

The all day interview process selects for a kind of person who is confortable with arduous processes. With poor scalability.

IMO any team with an SLA should be avoiding these people like the plague, because they will tolerate bullshit manual processes that take all day. They have no motivation to make foolproof automated processes with good visibility and repeatability. The smartest of them will fight attempts to change the status quo because the status quo makes them look good and everybody else look like idiots.

Three of my favorite bosses were from the Fire All Heroes school of management. Two actually gave a speech to that effect in front of the entire engineering dept. They helped me get out of the hero racket.

It’s great to be needed. But it sucks being the bottleneck.

My problem is that it's all cargo cult, and none of it is rationally thought through to pursue desirable qualities in an engineer.

Even within Google, Facebook, Amazon, and Microsoft, you're usually being interviewed by a fresh-out-of-school 20-something who has no idea how to do much of anything, let alone evaluate candidates fairly. And yes, they "train" these kids -- but you basically can't train someone to do something that relies heavily on intuition. That requires experience, but 20-somethings don't have experience. So instead, they're "trained" to do the one thing you can do repeatably: ask coding puzzle questions from a book, and reject anyone who doesn't regurgitate answers with 100% fidelity. It's the McDonald's food of interviewing: not the best (or even good), but consistent across a large organization. Sort of.

So while big companies need people who can work on a team, exercise good judgment, communicate clearly, write clean code and not be racist/sexist/evil jerks, they get...people who can memorize questions from a big book of programming questions. I can easily come up with tests that get to each of those properties...but they rely on interviewers having good judgment, and most do not.

I get itchy when I get asked to write code that I would veto in a code review.

My internal dialog when asked things like a linked list or a hash table is "Oh god, does this mean they like code like this? I bet some 'clever person' at this company wrote their own hash table/event queue/template engine* and forces everybody else to use it."

* Unfortunately my current employer is just like this but I didn't pick up on that in the interview process.

You and me both. And it feeds itself, too, because every line of code is an opportunity to reinvent the wheel or do something clever (it sometimes seems like they want to see that, or else this class of question wouldn’t be asked??).

The downsides of avoiding the algorithmic interview process is that you will end up hiring people who talk a very good game, but cannot write code to get out of a paper bag.

One of the most painful interviews I have ever seen was a guy who had a resume listing a number of interesting projects. He could talk energetically and in detail about them. Then we asked him to write some code to solve a simple problem. He said he didn't know our primary language, but was very familiar with Python. I know Python, I was good with that.

He didn't know Python. I tried to help him, but he didn't get much farther. I eventually called the interview, with a complete 180 of my hiring opinion. Nice guy, but he couldn't be what we needed.

This is a real problem. If you are hiring coders you have to have a couple people in the team go deep on coding chops to ferret out the charlatans. Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better. Some teams I work with also give 'homework' exercises, which I believe is fairer than trying to do it in front of somebody else. (Unless that's how you actually write code on a day to day basis.)

Good interview processes reflect complementary broad and deep concerns. It's kind of analogous to the way a strong team is better than the sum its parts.

> Personally I like to show people a piece of code from a big system they've never seen and let them walk me through what it does and what they would change to make it work better.

This could be the first coding interview style that actually makes sense to me

You can easily do programming problems without algorithm questions.

I don’t think I’m against the algorithm part as strenuously as I am against the gauntlet part. You shouldn’t be locking someone in a room for 6-7 hours and then judging them on how they keep their cool, for many reasons, including those I mentioned above.

As I mentioned elsewhere I think you can ask questions that look like work but aren’t (go too far the other way and you’re into IP problems)

Can you please elaborate more on the Fire All Heroes philosophy? I looked into it and couldn't find anything describing it in depth

I’ve only met a couple people who say “fire”. That’s a little overwrought. The less dramatic version is “we are too big for heroes” which unpacks into something like this:

You don’t want an organization that relies on one or two or three people to swoop in and save the company every time there’s an emergency. A production issue should look like disaster preparedness. Document, train, drill, prevent.

More concretely, make the important parts as obvious as you can, as similar to production as you can, so anyone can set up a system and try to repro the problem. Config, build, and deploy should be push button (very robust scripts with every cheap sanity and safety check you can manage). No flakiness is okay. Nor obscurity. Everybody should understand how it works.

Document everywhere diagnostic data comes from and goes to. Don’t let your most senior people solve production issues; assign them to people one step down (and throw in some promising mid-level team members for diversity and longevity). Five why’s every outage and be sure your resolutions always involve making the problem easier to detect next time, not just prevent.

Thank you! That was a great explanation. I like it wrapped up in such a memorable phrase

On the other hand, if Facebook had hired him, it's unlikely he would have had enough freedom to create Whatsapp or anything like it. Even if Facebook knew what was going to happen, Facebook still made the right choice when they rejected him and later bought his company. Rejection can be a good thing for everyone.

Maybe.. but maybe he would have been on the Messenger team and made that What's App.

I doubt that. In most companies the Managerial chain kill bottom up innovation.

There’s less than 1% chance Facebook messenger would be able to live to the philosophy of “no ads, no gimmicks, secure messaging”

That’s why startups can disrupt. It really does reward bottom up innovation.

We are talking about a startup that sold to Facebook for $19 billion dollars whose founder was rejected by Facebook when he interviewed for a job there before he started what's app. I know this is make believe world but had Facebook hired him and had he worked on messaging I bet he would have beget a similar product (in make believe land). The problem most of us Americans didn't understand was that SMS cost money (in the rest of the world) and not in the USA. Most American text plans were free and unlimited in the beginning... that was until the US mobile networks caught on to the Europeans and realized they could charge per text. So that what made what's app. And FB could have saved themselves $19B.. still.. if you are right then he probably would have left FB and started What's app on his own.

There’s a reason why the founders quit even after Facebook bought them.

Facebook is a growth at any cost kind of company. They really wouldn’t have listened to him even if he joined Facebook in the first place.

The messenger on Android sends all your text messages and phone logs to Facebook. Mark approved that in the name of growth.

There’s absolute no way Whatsapp would have been invented at Facebook. Facebook only bought it because it could have been a serious threat to their dominance.

FB would not have allowed him to make Whatsapp. It was built with a philosophy of correctness ("We can never drop a message") and privacy. Contrast that to FB's "move fast and break things" and disregard for privacy to the point that they stole users' call logs right off their phones.

So there's no way they would have listened to Acton and let him build Messenger the way he wanted.

Add to that the fact that Acton's ideas didn't yet have any market validation. Once WhatsApp was a proven success, FB was willing to pay for it, but even so they are now destroying what made it good - https://www.theverge.com/2018/4/30/17304792/whatsapp-jan-kou...

That's assuming that some other app wouldn't have filled the messaging space.

...and Twitter

https://twitter.com/brianacton/status/1895942068

It could mean though, that he's a very good tech entrepreneur, but Facebook was hiring him for software engineering, and he didn't meet the standards.

There's something that I learned too about entrepreneur, once their company is bought, they usually don't stay long, often they only stay the length required by the contract. Sure money is a factor, but usually, an entrepreneur wants/needs more than a simple job.

Brian Acton himself left 3 after later, months before all his options vested. In his case it was about Whatsapp monetization, but it's in the same vein (lost of control of the company).

But isn't that the optimal outcome because $19B dollars indicates it was clearly very valuable to Facebook and it's not likely he would have created it if he was working full time at Facebook.

That there is a stunning amount of randomness in hiring is, I think, by design.