Is anyone else turning down riddle interviews? Or am I being unreasonable?
Because of this, I have instead written my own interview questions that I administer. You won't find them in leetcode, and they're not particularly challenging- and it still filters out many terrible candidates.
To my surprise, it was an actual front-end task. I told him jokingly "What, no leetcode?" to which he laughed saying "I have my ways". To my even bigger surprise, it was also a DSA question in disguise.
After writing a component to render out a filesystem tree view, the interviewer asked me which algorithm I was applying for this task. I never really think of algorithms when doing front-end, only in terms of design patterns, but the answer was immediately clear that I was using DFS. Sadly I didn't get a follow-up, I thought I just didn't pass. Then a few days after one of their massive layoff rounds, got an e-mail saying I did great but weren't hiring anymore, lol.
But I liked this approach so much that I've used variations of this question when interviewing candidates at my job. The task itself is incredibly simple, but a surprisingly amount of people can't solve it or complicate it unnecessarily without or before asking for clarification. I also tell them it's not necessary to write executable code. This somehow confuses people a lot? I've found a lot of candidates not comfortable writing code without an IDE, even with an "open-book" and when told it doesn't have to run.
Basics:
What is https and how does it work?
What is a charset?
How would you describe SQL?
Advanced:
Parse the following file... (CSV or a made up txt Format)
Show the results in a table like view.
but typically it starts with: you have a list of 10K strings, containing duplicates. produce a counts table (IE, string -> number of times that string occurred). What python data type or class does this efficiently? What is the underlying data structure? What is the time complexity of that data structure?
Next are a few questions about a python Node class used to build a tree, where I have either a bug that breaks a recursive indented print routine, or you need to detect a cycle (IE, is the tree you handed me really a graph?)
Finally, for senior engineers or people who are going to be working with low-level code, I have a bit-packing question using DNA sequences (A, T, G, C). I work for a biotech so it makes sense to have at least one question about DNA.
I've had to refine the questions over time based on what I've seen so that nothing is rushed, the important parts are obvious, and the interviewee doesn't feel like I'm asking them to find an approximate solution to an NP-hard problem in 30 minutes.
Fortunately, I rarely encounter riddle interviews, and have never encountered leetcode in interviews. This is likely because the companies that do this sort of thing are also companies that I already know I'd be unhappy at, so I don't apply to them in the first place.
Having done all that, I figured out that the answers to leetcode questions always involve knowing the trick or hidden clue, then kind of laboriously grinding out the code.
It's a kind of gatekeeping while appearing to be merit-based, because knowing the tricks is like being in the right club. In fact, McDowell's blurb for his book says it right out: "Learn how to uncover the hints and hidden details in a question" [1]. Getting the answer doesn't depend on knowing how to do software development, it depends on being in the right circles to know and share the tricks.
Gayle Laakmann McDowell is a woman by the way.
I think if you're not in an urgent need of a job, it's ok to be selective. Leetcoding jobs will probably have a lot of rigidity in their work processes as well, and it's up to you to be willing to accept that or find something else.
20 years of experience only serves to indicate that you are probably not up to date with the frameworks and languages of the day. For some unfathomable reason "good engineering" seems to be conflated with using the latest and most buzzword-riddled tech possible.
They should probably exempt you from stuff like leetcode interviews then. I think leetcode is more for junior positions who might not necessarily have a well traceable trail of experience to ensure they’re legitimate
(i do find the algorithms interesting in their own right too; it's just annoying to have prospective jobs gated behind finding and coding them up in 45 minutes. the older you get the more your focus at actual work emphasises depth over speed.)
algorithm-optimization problems are relevant if and only if the company operates at significant scale; the "tricks" employed are not mysterious/tricky secrets, they're standard approaches (like dynamic programming == caching previous computations) for software engineering
Cracking the Coding Interview is a good book; the Stanford algorithms course on Coursera is excellent
the ideal interview would be to hire you for a day/week to do something real with the team...
From the companies perspective, leetcode won't help you determine if someone is good at their job coding wise, however it is an indicator of basic talent. If you are the type of person to sit down and grind out stuff for the interview, or you have an innate understanding of algorithms to where you don't really even have to study for leetcode, you show that you have the capability to take on new projects and understand the context, and/or the willingness to sit down and figure stuff out. When I worked for Amazon versus a smaller company that didn't use leetcode style questions, the rate of new hires who couldn't do work without handholding was higher in the smaller company.
From the candidate perspective, I personally think that as you get older and more experience, you should be able to program with people (i.e manager) versus programming with a keyboard - if you are just as good at that, its a much easier job IMO. I move to a technical manager role, and the last to jobs I have had overarching system architecture problems in interviews rather than coding challenges. If however, you do want to stick with coding and development, its not unreasonable to expect that you should be intimately familiar with basic algorithms for leetcode. Grinding out and memorizing solutions is fine for junior devs, but as you get older, you should realize that every solution is basically pointer manipulation in some form and way, and not have a hard time in the interviews. Most leetcode interviews don't even expect you to know how to do it off the bat, most of the time if you demonstrate good reasoning skills, the interviewer will course correct and provide small hints and you will still get a fairly high score if you can solve the problem.
I found work through people I knew. I never did one again.
As far as having two kids goes---yeah, that's exactly the point of leet coding tests. If you don't have the time or energy to waste on mastering pointless exercises, you won't have time and energy to work 60-80 hour weeks. They want to filter out people with adult responsibilities, and adult problems.
Basically, are they going to hire one of you--experienced enough that you can recognize bullshit and so you will be continually pushing back--or two new college grads, single, no social life, and eager to do whatever it takes to make their mark on the world?
Alas, if you want a job coding at a company like facebook, google, bloomberg, etc etc you simply are going to have to be crackerjack at puzzle solving and leet-coding. Think of it more like hazing week at a college fraternity rather than as a test for how good of a coder you are.
Personally, I think it's ridiculous. If somebody has been programming since the Reagan administration at companies like Microsoft and AMD and Facebook, they will do fine wherever they are hired. But it is what it is.
One thing I have been suspicious of with these tests is exactly this... it is effectively an age discrimination loophole. Having free time to practice riddles is a decent proxy for how young you are.
I think its useful to find the rare candidate who is both strong at algorithms and problem solving in general while being able to explain and talk like a professional.
Most of the time you get some "rock-wall" type who can crank out LeetCode but is awful to actually work with, or you get someone who is "toxic positive" and also awful to work with because they suck at the actual work.
So again, just gotta optimize for the sort of team you want to build. And most jobs where they ask these type of questions are offering high TC, so its not exactly unfair.
Like I mentioned elsewhere, I've worked at a company where people asked LC type questions and I chose to ask more domain related questions where I mixed in the algorithmic challenges. One thing I noticed is that we'd usually ask 2 questions each round so when ppl asked LC questions usually either the candidate failed quickly by getting KO'd at the 1st question, or they answered both flawlessly. Isn't that kind of concerning? So I'd start with the LC and then ask my domain focused algorithmic question, and notice that usually I'd get the KO/nerd on 1st question, but people might struggle on 2nd question I asked.
So idk. Long story short I prefer to work with people who can think and aren't rock-wall types.
Not true in my experience. I've worked with many seasoned greybeards who were incredibly mediocre, horrifically bad even. Guys with very impressive resumes, too.
I don't know if it's all fields, or if programming is special, but you really can't trust YoE or a resume. You have to ask people to in some way demonstrate - leetcode or otherwise - that they can actually do the thing.
And again, in my experience, many - a sickeningly large amount - simply cannot do the thing. Even when the thing is something like "reverse a string".
How many are we talking about here? How many years of experience did they have?
Point being, people get hired and hang around in the industry for all kinds of weird reasons, you never know what someone can really do until you test them.
What’s far more important is candidates ability to learn, grow and adapt to new challenges. Their personality and how they work on teams is also important.
LLMs are changing things too. I consider myself more of a backend developer. However, I am currently building a front end application using react. Using a LLM has really helped me with setting up my project and getting used to syntax and concepts more quickly. I could have learned this on my own, but AI helped me pick up this task quickly. What specific skills you have currently is less important than your ability to learn and adapt.
I think they're terrible at what they claim to be doing (determining if a candidate is good at software engineering) because never in my life have I had to do a leetcode style thing under time pressure in my 15 years of professional software work.
I have a pet theory to explain them - I think it's simply a form of hazing. Many engineers have the mindset of "I had to go through this, you will too". It also allows the interviewer to intellectually flex on the interviewee which staves off impostor syndrome in the interviewee if only for a moment.
They also remove people like you and me, older and further into our careers with less stomach for make-work and less free time to practice for it.
It's possible to solve these on the fly, but you're at a disadvantage compared to people who have done hundreds of these problems, pattern match to the closest leetcode problem, then immediately write the optimal solution on the board.
I think the problem is that it’s not a great measure of real world ability on many dimensions - often you don’t have the same tools at your disposal, your body is full of adrenaline from the stress of being in an interview (which enables fight or flight and disables high level cortical thought) and lastly many of the leetcode problems are - at best - only tangentially related to the work.
I think they are not a good measure of performance at a programming job - I do however think they are a good way of measuring a candidates tolerance for stupid B.S., which I think is what some poor organisations are actually subconsciously measuring for!
Could you give an example of what you consider a “leet code” interview?
I'm currently a single person startup without enough revenue to hire a dev helper. But there are two kinds of developer I would hire: business automation experts and computational geometry experts.
And if I interviewed a compgeo person, guess what algorithms I'd ask about?
That's right, I'd ask them to derive the Bernstein basis functions, implement Decasteljau's algorithm using LERPs, prove this gives us the same result as numerically evaluating Bernstein, calculate the algorithmic speedup, and remark on the numerical stability.
This is either very easy - the person cares about reticulating splines! Or it's impossible, signalling lack of domain knowledge.
That's why in this case I don't feel it's a riddle at all. It's one of the basic mathematical pillars our entire product line is being built on. Knowing I don't have to mentor you in that is going to be a big deal for me. Likewise knowing that I do have to mentor you might not be a deal-breaker, but requires accommodations, like putting you in a more Junior role, specifying the algorithmic portion of tasks much more stringently, and taking responsibility for our numerical or mathematical analysis.
That second scenario might indeed happen if I make enough money to hire a Dev assistant, but can't afford one trained in comp geo. I in that case I would still pop the Bernstein/Decasteljau question but not expect them to go in depth. Instead I would ask them to pledge to learn, and provide paid training sessions, both to enrich them with useful domain knowledge, and to eventually benefit our team.
Do whatever makes you happy, but as an interviewer I see far too many "experienced" candidates who show themselves to be absolutely garbage at conceiving, planning, structuring, and writing code all while complaining about how impractical it is to be asked to show me that they aren't bullshitting their supposed proficiency.
You can get all the brownie points you want for having 20 years of experience when I start seeing that years of experience make more of a difference than they currently do in this godforsaken industry.
I can code fine. I've practiced enough leetcode problems to be fine with them too. Just not in interviews.
But, you didn't answer my question. It says bad things about the industry that so many people still lack the insight to see the disconnect between performing well during social evaluation and effective software engineering. It's been decades now.
A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it. Strike up a conversation with the person. I find it extremely easy to tell if a person knows what they're talking about and enjoys the subject _on subjects I am familiar with_, which is quite common in the situation where I am interviewing someone to join my team.
> A far better approach is to talk through the design of a system - conceptual or previously worked on and ask questions about it.
Hard disagree. It's far too easy for people to talk about concepts without having a brain that understands code well. That's the difference between knowledge and talent. A talking approach may find knowledge. I'm looking for talent.
The open-ended system design interview comes after the initial leetcode interview now.