To bastardize a quote - ‘it’s a terrible system of government, but it’s the least terrible one we’ve been able to find’
Seriously, what are the alternatives?
Seriously, what are the alternatives?
- Simple, practical coding questions related to your company need (so not algos/leetcode for 90% SaaS CRUD app companies)
- Engineer or manager talk to candidate about past work and projects.
If you are giant FAANG okay fine that won't scale. But most companies smaller than this will do just fine without the assumption of "everyone's a faker! Gotta prove you wanna work here!". This has worked fine for me in hiring past 20 years.
Take the leetcode tests once every 5 years or so. Mentor for a few years with an experienced, and already licensed, engineer and get their approval. Then the interviews can skip the drudgery and can be higher level and higher quality.
In physical engineering, things are very much limited by physical laws, which don't change (and even if our understanding on them might, that happens rarely enough to adapt). In software engineering, the foundational principles can and do change many times in an average engineer's career.
I'd like to hear more.
Assembly (for 6800 series Macs) -> C (PC on windows) -> Java (hosted on prem) -> Cloud hosted Java + JS/React.
Depending on your definition of ‘foundational principles’ either nothing has changed, or everything has. But one thing is clear, the day to day is completely different.
The licence you value wouldn't be the licence I value.
Flip a coin whether I'll ace or fail a random leetcode question but after the one and only time my little monkey dance successfully got me into a "desireable" company, I started confidently rejecting other proposals to whiteboard me.
Theoretically, I agree these are a great way of generating some signal where there's not enough to be found by other methods. But, in practice, what I've found is that most of these types of exercises are way overscoped, and even those which are not put a hugely disproportionate time burden on the candidate with minimal return for most of them. In other words, nobody wants to take the time to properly review these things.
I've had much better experiences when people give me code and ask me to review it rather than when they give me a "spec" and ask me to write code based on it. One big red flag for the latter type of assignment is the phrase "production ready," as that can mean so many different things it's a borderline meaningless criterion.
I could really go on and on about this, but I'm going to stop here.
And yes the interviewer has to review that stuff and ask good questions but nobody said this was easy. But for me it showed better outcomes than the usual live leet code interviews.. (I did them too).