> Interviewing has always been a big can of worms in the software industry. For years, big tech has gone with the LeetCode style questions mixed with a few behavioural and system design rounds. Before that, it was brainteasers.
Before Google, AFAIK, it was ad hoc, among good programmers. I only ever saw people talking with people about what they'd worked on, and about the company.
(And I heard that Microsoft sometimes did massive-ego interviews early on, but fortunately most smart people didn't mimic that.)
Keep in mind, though, that was was before programming was a big-money career. So you had people who were really enthusiastic, and people for whom it was just a decent office job. People who wanted to make lots of money went into medicine, law, or financial.
As soon as the big-money careers were on for software, and word got out about how Google (founded by people with no prior industry experience) interviewed... we got undergrads prepping for interviews. Which was a new thing, and my impression is that the only people who would need to prep for interviews either weren't good, or were some kind of scammer. But then eventually those students, who had no awareness of anything else, thought that that this was normal, and now so many companies just blindly do it.
If we could just make some other profession be easier big money, maybe only people who are genuinely enthusiastic would be interviewing. And we could interview like adults, instead of like teenagers pledging a frat.
Prepping for interviews has been a big deal forever in most other industries though. It's considered normal to read extensively about a company, understand their business, sales strategies, finances, things like that, for any sort of business role.
I think tech is and was an exception here.
What you're describing sounds to me like just caring for the place we'll be spending half a decade or more and will have the most impact on our health, financial and social life.
I'd advise anyone to read the available financial reports on any company they're intending to join, execpt if it's an internship. You'll spend hours interviewing and years dealing with these people, you could as well take an hour or two to understand if the company is sinking or a scam in the first place.
Why should anyone do that in a world where fundamentals don't make sense? Yes, knowing how the company makes money is important (though that often is incomplete or unclear from what's publicly available), but knowing their 10-K or earnings reports? Too much.
kinda silly given the ability of most people to infer anything substantial through finances and marketing copy
really company reviews is all that matters and even that has limited value since your life is determined by your manger
best you can do is sus out how your interviewers are fairing
are they happy? are they stressed, everything else has so much noise to be worse than worthless
"Is the company consistently profitable or not?" and "Are revenue and profits growing over time, stable, or declining?" are very important questions to answer, particularly if stock grants are part of the compensation package.
For developers who work on products, getting a sense of whether the product of the team you'd be joining is a core part of the business versus speculative (i.e. stable vs likely to have layoffs) and how successful the product is in the marketplace (teams for products that are failing also are likely to be victims of layoffs) are also very important to understand.
So many ways to juice those numbers though.
And if your team is far from the money, what often matters much much more is how much political capital your skip level manager has and to what extent it can be deployed when the company needs to re-org or cut. Shoot, this can matter even if you're close to the money (if you're joining a team that's in the critical path of the profit center vs a capex moonshot project funded by said profit center).
This is one thing I really like about sales engineering. Sales orgs carry (relatively) very low-BS politically.
It matters a lot whether the organization is growing. If you get assigned to a toxic manager in a static organization then you're likely to be stuck there indefinitely. In a growing organization there will be opportunities to move up and out to other internal teams.
I remember being told this during my interview prep classes in college in 2008. Interviewing was so much more formal even then (in the NYC area): business casual attire, (p)leather-bound resume folios, expectations of knowing the company, etc. I definitely don't miss any of that nonsense.
I recently showed up to a new startup interview, with a similar folio (with printed copies of my resume, and a tablet of graph paper), and it paid off.
I was in a small conference room with the two co-founders, and of them hadn't seen my resume, and was trying to read it on his phone while we were talking.
Bam. I whipped out printed copies for both of them, from my interview folio.
It was good standard advice even for programmers to know at least a little about the company going in. And you should avoid typos and spellos on your resume.
But no "prep" like months of LeetCode grinding, memorizing the "design interview" recital, practicing all the tips for disingenuous "behavioral" passing, etc.
I’m glad civil engineers can’t vibe build a dam.
I'm not glad people here can't avoid injecting casual AI-hate soundbites everywhere. Is there any particular objection you have, or just "AI bad"?
IIRC Google had an even higher bar in their early days: candidates had to submit a transcript showing a very high GPA and they usually hired people only from universities with elite CS programs. No way to prep for that.
They only gave it up years later when it became clear even to them it wasn't benefiting them.
> IIRC Google had an even higher bar in their early days: candidates had to submit a transcript showing a very high GPA and they usually hired people only from universities with elite CS programs.
Which sounds like a classic misconception of people with no experience outside of a fancy university echo chamber (many students and professors).
Much like Google's "how much do you remember from first-year CS 101 classes" interviews that coincidentally looked like maybe (among my theories) they were trying to make a metric that matches... (surprise!) a student with a high GPA at a fancy university.
Which is not very objective, nor very relevant. Even before the entire field shifted its basic education to help job-seekers game this company's metric.
> many companies just blindly do it.
Yes. A while ago a company contacted me to interview, and after the first "casual" round they told me their standard process was going full leetcode on the second round and I'm advised to prepare for those if I'm interested in going further.
While that's the only company that was so upfront about it, most accept that leetcodes are dumb (need to be prepped even for a working engineer) and still base the core of their technical interview on them.
> And we could interview like adults, instead of like teenagers pledging a frat.
I think you're viewing the "good old days" of interviewing through the lens of nostalgia. Old school interviewing from decades ago or even more recently was significantly more similar to pledging to a frat than modern interviews.
> people who are genuinely enthusiastic
This seems absurdly difficult to measure well and gameable in its own way.
The flip side of "ad hoc" interviewing as you put it was an enormous amount of capriciousness. Being personable could count for a lot (being personable in front of programmers is definitely a different flavor of personable in front of frat bros, but it's just a different flavor is all). Pressure interviews were fairly common, where you would intentionally put the candidate in a stressful situation. Interview rubrics could be nonexistent. For all the cognitive biases present in today's interview process, older interviews were rife with much more.
If you try to systematize the interview process and make it more rigorous you inevitably make a system that is amenable to pre-interview preparation. If you forgo that you end up with a wildly capricious interview system.
If course you rarely have absolutes. Even the most rigorous modern interview systems often still have capriciousness in them and there was still some measure of rigor to old interview styles.
But let's not forget all the pain and problems of the old style of interviews.
> I think you're viewing the "good old days" of interviewing through the lens of nostalgia. Old school interviewing from decades ago or even more recently was significantly more similar to pledging to a frat than modern interviews.
Yeah, no, not at all. Interviewing in the 90s was just a cool chat between hackers. What interesting stuff have you built, let's talk about it. None of the confrontational leetcode nonsense of later years.
I still refuse to participate in that nonsense, so I'll never make people go through such interviews. I've only hired two awesome people this year, so less than a drop in the bucket, but I'll continue to do what I can to keep some sanity in the interviewing in this industry.
> > people who are genuinely enthusiastic
> This seems absurdly difficult to measure well and gameable in its own way.
True, and it is gamed currently (some prep books tell you to feign enthusiasm).
But let's whimsically say that the hypothetical of software development no longer being the go-to easy lots-of-money career meant that the gaming people would go to some other field instead, leaving you with only the people who really want to do this job.
Absolutely.
The amount of times I’ve seen a “do you want to have a beer with them?” test in lieu of a simple programming exam is horrifying. (And it showed in the level of talent they hired.)
Fortunately, most of those have been left by the wayside, roadkill of history.
Because that is really the alternative if we don’t have rigorous, systematic technical interviews: cognitive bias and gut-feel decisions. Both of which are antithetical to high performing environments.
False choice.
The reality of these "rigorous, systematic technical interviews" is that we have a ton of companies doing nonsense theatre that isn't actually about "fundamentals", is also easily biased (as even some purported Google interviewers have admitted on HN), and have almost nothing to do with how effective a software engineer will be (as even Google's own stats show).
There is no alternative.
So you may not think they’re predictive of success, but you should see how much less predictive everything else is.
Hiring is always a risk. It will never be a perfect science.
That’s why it’s important to have a quick off-ramp for those who aren’t working out.
Edit: BTW, where did you see Google saying their interview process doesn’t work? Other than some a few anonymous devs venting on HN, the company still uses coding interviews as critical to their process. You will always find a few complainers, but the fact that one of the world’s top software shops still uses it says what needs to be said.
I've been doing this awhile, and I've seen hiring work really well without the LeetCode grilling.
And I've almost always seen the LeetCode grilling be administered by someone who doesn't know what they're doing (and often also tainted with ego, despite the strange claim of some that a LeetCode grilling is objective).
That said, if you're sourcing random people, good luck, it's a flood of LeetCode gamers to wade through, and too much of your staff interviewing them might also be LeetCode gamers with no experience doing non-LeetCode interviews.
> Edit: BTW, where did you see Google saying their interview process doesn’t work?
I have a bunch of notes on Google hiring I'd have to dig through, but the first link quick at hand is this retrospective by a hiring committee person who left (and I have a note about 8m50s being a funny story of the hiring committee realizing that they would've rejected their own packets): https://www.youtube.com/watch?v=r8RxkpUvxK0 (IIRC, I don't agree with all the beliefs he still holds, but he calls out a lot of problems they found.)
Being personable does count for a lot in any role that involves teamwork. Certain teams can maybe accommodate one member whose technical skills make up for bad interpersonal skills as a special exception, but one is the limit.
Casual interviews definitely still exist, though the companies those jobs are attached to are typically not tech and pay less.
Consulting positions also don't have much leetcode BS. These have always focused much more on practical experience. They also pay less than Staff+ roles at FAANGs.
Most of the consulting positions I’m aware of also hire a far lower talent caliber than FAANG, so they need bodies, not top talent.
I have worked at a company who had a casual, experienced-based, conversational interview. The engineering there was atrocious, and I left as soon as I could.
If you can talk your way into a position, that says a lot about the level of talent there. Top talent wants to work at a place that has a transparent and merit based performance bar, and you can’t smooth-talk your way into a job.
If you’re referring to body shop consulting agencies this may be true, but IME as an IC consultant in DS/ML, my rates are well above Staff+ at FAANG, and nobody has ever tried to leetcode interview me. Yes, I have to do a lot of smooth talking, but performance is extremely transparent: if I don’t deliver, I don’t get paid. Honestly I doubt I could pass a leetcode style interview, and I’m glad I don’t have to do that anymore.