Perhaps there wasn't any actionable advice, but it's a sad indictment of the current state of tech hiring. Based on the article you can assume that Recursive Cactus is already in Big-Tech ("well known tech company") so "(a lot) higher pay" is a moot point and quite frankly it's unlikely that the daily tasks involved in the next job will bear a strong resemblance to the kind of synthetic tasks or problems you are asked about in an interview setting.
The article did raise more questions than answers, but that was by design. A lot of the assumptions that go into most tech interview processes don't withstand scrutiny. Interviewing is a hard problem to solve, but we shouldn't be satisfied with the status quo.
no its not. I know ppl who quit MS and reapply later to get placed into a higher tier after they interviewed there again. Jumping jobs into a higher tier is easier way to get a raise than grinding at the same job.
Just adding I had to do this at a large non-faang corp. Just curious how common this is, it seems like the only work around to strict HR caps on raises.
Extremely common. Interviewing is a tiring and arduous process and companies have all the power. They make the bet that the majority of people are not willing to leave (esp. once they have families).
Varies by industry and sector, but there's typically no "technical". It goes:
1) Resume + cover letter + cumbersome online job app,
2) phone screen,
3) On-site, and
4) Reference check.
Typically the interviews are more conversational, with an emphasis on behavioral questions, job history, and relevant skills. Academia and government have their own formats.
> and quite frankly it's unlikely that the daily tasks involved in the next job will bear a strong resemblance to the kind of synthetic tasks or problems you are asked about in an interview setting.
The blog post mentions in passing that their interview.io site gives users a choice between practicing traditional "synthetic"/algorithmic questions and a different approach focused on "systems design". I'm not entirely sure what the latter involves, but it seems like it could strike quite a bit closer to the generalist knowledge that would be required in "day to day work", while preserving a desirable problem-solving component.
One might even imagine using both approaches in combination, e.g. using algorithmic puzzles as a sort of tie-breaker to choose among candidates who seem about equally strong in the 'systems design' domain.
Algorithmic coding tasks and system design questions are the two types of things you get asked in SWE interviews. They just have practice interviews for both. It's not novel.
The article did raise more questions than answers, but that was by design. A lot of the assumptions that go into most tech interview processes don't withstand scrutiny. Interviewing is a hard problem to solve, but we shouldn't be satisfied with the status quo.