- Don't let the hr 20-something non-engineers be your first filter - the hiring eng manager reviews resumes. Let HR review the work history, references, and W2 stuff later.
- 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.
Standardized licenses, per language / domain / etc, that expire and / or something analogous to professional engineering licensure in harder engineering disciplines.
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.
Standardised on what exactly? There are so many methodologies and/or tools, with endless possible combinations, each of which can reach the desired result in terms of functionality and even quality. And enforcing just one means no possibility of progress.
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.
Not the poster, but I personally know folks who have gone
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.
I'm talking about things like 8/16/32/64-bit processors, CISC vs RISC, from mainframes to personal computers, from isolated machines to ubiquity of modern Internet, quantum computing etc. Note that I'm talking about the fundamentals of software engineering, not software science.
Passing one significant whiteboard interview once is all you need, that's your "licensure."
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.
I've talked with applicants about their private projects. It gave me great insights. Also take home tasks with a discussion afterwards are a good thing and can be an alternative if candidates don't have private projects to talk about.
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.
I absolutely agree with you. There are many take home tasks that are way overblown and expect too much. But I am convinced that you can scope it for say 1-2 hours and I think that's a reasonable time investment for an application.
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).
Seriously, what are the alternatives?