I’m not suggesting OP is dumb, but if someone is setting hiring criteria and thinks they need X skillset judged by Y, I think there’s a good chance they’re directionally correct.
I get it, I’ve bombed interviews I was excited about and rationalized it anywhere and everywhere. Once I started hiring folks, my opinions evolved significantly.
How else do you hire someone out of a pool of people that are all knowledgeable and likable? A bad hire, even if they’re super smart and just the wrong fit, is worse than not hiring anyone at all.
If you climb the management ladder, you’ll likely be graded on your org’s hiring outcomes. If 10 people all seemed qualified, I’m going to burn down the risk as much as possible. If I’m wrong 1 time for this, but it not obviously wrong 9 others, I’ll call it a win.
For context: this is coming from tiny startups to billion dollar companies and different things in between.
That's for after you get the job though. During the interview you'll need to be a bit smarter and more practiced with algorithms.
So I asked "is a naive implementation fine"? The answer was a quizzical "... well I guess we could start there? But we're probably going to need at least <insert Big O notation for time> and preferably get to <Big O notation for time and space>", so I wrote out a completely naive implementation and switched to questions.
-
But you're right, I can't program. Not memorizing elaborate cache-unfriendly vectorization-unfriendly algorithms has made me unhirable.
There was a reason they were excited to talk to me, and I thought it was an impressive career of programming to solve hard problems that started from writing assembly games for calculators in middle school... but who knows, maybe it was my charming smile?
Luckily my smile got me hired by a company that's paying me a FAANG salary but hasn't had to lay off thousands (knock on wood)
I hold myself to the standard of knowing enough the problem space before I interview people that I can open an editor and come up with domain specific problems that anyone who's doing what they claim they're doing daily can work through (crazy bar I know...)
> Outside of FAANGs I've routinely interacted with fairly senior engineers who just could not code, period, full stop
My first thought was "You must be joking if you think there are no L5s in FAANG who can't write code",but then I realized you actually think of writing code as literally being able to write statements in a given order... but that's such an insanely low bar that people regularly meet it by repeating problems over and over for a few months.
My bar for writing code at past a junior level is to be able to solve a problem with production grade code. LC almost precludes that between the time constraints and rigid solution set so people settle for "they wrote a guard statement against an empty list".
I just want to know that a new hire isn't going to ignore things like cache locality or not know what a memory mapped file is and try to load gigabytes of data into memory and parse the whole thing just to run their O(N) solution across 4kb of data.