Hacker News Reader

Comment by bulatb | Hacker News Reader

The article explains in detail how a pressure difference can create a force, and how the process generates these differences and how the force is felt as suction, but still argues that the process doesn't suck.

A process good at testing applicants should 1) identify the good ones and 2) identify the bad ones. The standard whiteboard interview makes no attempt at (1) and works by throwing almost everyone in bucket (2) regardless of potential.

This is plainly, in general, a process that sucks. It just happens that the way it sucks is not a problem if you're FAANG.

View on HN

You're exactly correct, and the complete lack of attempt to do (1) means that if you're a perfectly qualified candidate, then getting an offer is very much a crapshoot. It's actually quite easy to get into a FAANG company overall, it's just difficult to get into a single specific FAANG company on a single try. The interviewers are mostly not good at interviewing and they'll just let you in as long as you can solve their little toy problems the way they would solve it. Sometimes it's easy enough, and other times your luck runs out.

>means that if you're a perfectly qualified candidate, then getting an offer is very much a crapshoot

This is the most annoying thing. I've got a code test on Friday. This life changing pivotal moment comes down to little more than whether or not I've seen the problem before. If I have, great I nail it and get the job. If not, well, I don't. So arbitrary.

As an interviewer at one of these companies, I try really hard to only ask questions that people will not have seen before. I agree that if you're asking a question which some of your audience has heard and some hasn't, that's terrible for the interviewee, but it's also terrible for the company.

But you can't really. There's what? Hundreds or thousands of these tests happen everyday. It's impossible for each one of them to be unique. They're all just variations on maybe a few dozen to a couple hundred core questions.

All design-algorithms-code questions are variations on a few dozen to a couple hundred core questions? In a way that regular programming is not?

For most programming very little time is spent on actually implementing algorithms. It's more about designing and organizing your code and data. Few people are sitting down for 8 hours a day and banging out leet code style algorithms.

The fetishization of Google (specifically their interview process) has really hurt the industry and caused a lot of unnecessary stress for a lot of engineers.

Agreed, lots of companies have Google style interviews when they are clearly not Google.

You better have quality work to do and equivalent perks as Google to put candidates through their style of interviews.

Otherwise those companies are delusional and I have the world's smallest violin for their recruiting woes.

If you interview like Google, you better pay like Google.

> pay like Google.

So notoriously low that the CEO had to approve a company wide raise of 10 percent one year?

To "pay like Google" compared to industry in general and to "pay like Google" compared to the places Google is competing for hires with are very different things.

https://levels.fyi is great for understanding what statements like "pay like Google" etc mean.

(I've entered my comp there)

I guess people didn't quite get the reference: https://www.cnet.com/news/google-gives-employees-10-percent-...

From 10 years ago?

I think one of the main points of the article that the discussion here misses is that whiteboard interviews can be seen two ways: as an 'exam' where there's a 'right' way to behave/solve the problem and as a 'simulation' where the point is to simulate a situation of working/problem solving with the candidate.

If the interview is explicitly run as a simulation, where the hiring team looks for good behaviors (both in attitude and in problem-solving) and not necessarily good outcomes, whiteboard interviews work well, because: a) they scale and, b) they can actually be good simulations of a high-stress environment. The downsides are that they become subjective, unless the hiring team is experienced/has been trained well.

I want to be clear that by "the standard whiteboard interview" I mean a certain format that's been roughly standardized at FAANG and copied out-of-context by a major chunk of the industry. It's a starter question, then a harder question, then another if there's time; each is answered with an algorithm written on the board in mostly-valid code. Your on-site loop (pre-2020) is four to six 1-hour sessions back to back, plus a lunch break.

The only work environment it simulates is one where every feature is developed in a 15 minute sprint that's literally overseen (like over your shoulder) by a boss who's put you on a PIP; there's no collaboration and no google; nothing is expected or allowed from you except a working output; and you're fired if there's any issue raised in code review.

It's more like an exam, but it's not even that: exams are meant to see what you know. The whiteboard interview just offers you as many ways to fail as possible and sees if you make it.

I wouldn't really say it's either one. I hesitate to call it hazing, but... as a trial to prove your dedication to the group by doing arbitrary and unpleasant things, for some it feels similar.

Maybe we need to shift focus to lowering the cost of False positive? The industry is willing to skip ton of great candidates that fail the "audition", just to avoid false positives. Otherwise great people and employees are ruled out, just because they can't reflect their true value at work in a stressed 1-2 hours interview. Cheaper false positive hiring may ease the pressure on the companies side to let them in. Having said that, because of stress, questions on interview should be 50%-60% difficult since the interviewee is not at 100%.

> Maybe we need to shift focus to lowering the cost of False positive?

Other things being equal, I would rather more stress in a handful of days of interviewing than more stress about whether I keep a job I "have".

Reply on news.ycombinator.com