Anyone just say "no" to leetcode interviews at this point?

I'm not opposed to leetcode questions, but if a junior engineer asks me a question literally from leetcode without changing the test details (IE, they just copy/pasted from the site instead of coming up with something slightly different), I exit the interview and email the CEO with an explanation (I'm very senior, so it makes sense to go straight the CEO).

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.

I absolutely turn down (or end and leave) interviews where this sort of thing is involved. I think that the willingness of companies to engage in these practices is a good indicator that I'll be a poor fit in them.

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.

I totally freeze up and my brain can't solve problems during these things. And it is the only time that happens.

I suffered through two or three to get a feel for them, bought a copy of McDowell's Cracking the Coding Interview and did a few exercises, reviewed some basic algorithms, and decided no more leetcode.

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.

1 https://www.crackingthecodinginterview.com/

I'd love to be getting interviews to turn down, at this point.

I'm also 40 with 20+ years in software. 4 interviews out of 5 recently tried to do come leetcoding, but after a brief conversation about it 2 of them were reasonable and we worked with existing code instead. 2 did not and I walked out, both were somewhat larger companies.

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.

It is the recruiters who are being unreasonable.

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.

> 20 years of software engineering experience

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

recently laid off late-40s senior engineer here; not the biggest fan of leetcode style questions and i do not ask them when i'm on the other side of the desk, but also i figured it was not a windmill i could afford to tilt at. i paid for a month of actual leetcode, spent 2-3 weeks intensively going through problems, and considered it time and money well spent for getting me back in practice.

(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.)

riddles and puzzles are pointless flexing by the interviewer

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...

This is my personal experience and opinion of being on their end of companies that use leetcode and that don't.

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 was in London on a wet dark winters evening on my way to such an interview as it was 20 years ago. I rang the recruiter who had fixed it up and said I am not going. The company had stayed late to do it, he was furious and probably they were too. I just couldn't face the banality of it all any more. I felt like a performing animal and didn't want to do it any more.

I found work through people I knew. I never did one again.

Do you have grey hair? If so, you are screwed. Recruiters and hiring managers will not interpret you as taking a principled stance against leet coding. They will simply conclude you are too old to be able to do leet coding.

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.

LeetCode emphasizes the wrong thing. I can appreciate that you need some basic questions to see if people can code at all, but you can achieve this with questions that don’t require leetcode prep and studying up on algorithms.

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.

You're not alone. I detest these interviews, refuse to participate in them on either side. Of course, that's from the privileged position of currently being employed so it doesn't carry a lot of moral weight since it's currently causing me no pain.

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.

Yes, I don't do leetcode and refuse to anytime I'm asked to do it. I won't practice that just to please people that probably never shipped a profitable piece of software by themselves

I did and it turned out fine. Big corp might not like it, but startups are usually fine with skipping and perhaps doing a take-home assignment instead, which I am fine with.

Yes. I simply tell them I don't think we are likely a good fit. There are plenty enough companies that respect me enough not to put me through that nonsense.

I love leetcode type puzzles. I still do an occasional puzzle even though I’m not looking for work. I like the feeling of intellectual satisfaction when I come up with a solution to an interesting problem.

I don't personally mind LC, but I always asked questions related to our company and based on specific problems we had in the past, or some imagined scenarios that would help our customers.

I suck at brain teaser puzzles and always have. I can wrestle great quivering mounds of legacy code into functional abstractions with full tests and auditing with a tenth of the code and a hundred times the scale, but I can’t tell you how to get your goat, chupacabra, and peanut butter sandwich across the river in N trips. Can’t solve a Rubix Cube either, some nerd I am huh?

Just say - “no thank you” And walk away

Could you give an example of what you consider a “leet code” interview?

It is a turn off, but TBH I'd do it if I were keen enough on the position.

I'm 39 and I own a competitional geometry automation company, working with reverse engineering smooth NURBS curves from roughly scanned point clouds captured in the field from customer yachts. The result is a beautiful pattern for a new deck of flooring costing between 5 and 15 grand. We charge between $50 to $300 for this design process. My clients are the flooring manufacturers that outsource their design reverse engineering to me because that work is often very hard, and my algorithmic tooling and equality controls are the best in the industry. Eventually I'd like to launch our product as a software system, but for now I operate as a design outsourcing service. I develope our algorithmic tools and also do the design work.

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.

When I see someone complain about how programming in interviews isn't practical, most of the time that tells me that they haven't spent any time thinking about the difference between programming talent and programming knowledge, and have been coasting by in a world that elevates mediocrity.

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.