Ask HN: Anyone just say "no" to leetcode interviews at this point?
53 comments
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.
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.
Going to the CEO makes no sense unless you're interviewing for a CTO position.
100% agree. A few in-house questions can save a lot of time by weeding out some true incompetents. There are way more of these than one might expect.
Long reply but last October I had pretty enjoyable interview experience during a front-end screening at Google, for which I absolutely grinded LeetCode.
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.
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.
Yes, I'm incompetent and consistently fail code screens.
Can you give one sample of your questions? (Go ahead and change it up a bit first, of course.)
I have several questions that I ask. Each one is structured as python class, with unit tests that are failing. Your job is to make the unit tests pass by fixing the missing implementation/bug. You can add any debugging code, and run the interpreter as many times as you like (I use coderbyte, which isn't great, but it has an editor and an interpreter).
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.
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.
I usually ask for some basic knowledge and some more sophisticated stuff. The questions are open instead of yes/no. The answers tell me a lot about the level of skill of someone.
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.
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.
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.
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've frozen up and been unable to solve a problem I had breezed through only a few hours before.
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/
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/
> In fact, McDowell's blurb for his book says...
Gayle Laakmann McDowell is a woman by the way.
https://www.crackingthecodinginterview.com/author.html
Gayle Laakmann McDowell is a woman by the way.
https://www.crackingthecodinginterview.com/author.html
So I am at a big tech company right now so I did the riddle thing at one point, but I'm out of the game so to speak and don't have the time for it anymore.
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.
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 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.
No, this isn't on recruiters. Blame the hiring committees and the standards for hiring set from technical leadership.
> 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
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
They should but I am in the same situation with IP and code to show and FAANGs insisted on it. Eventually I gave up and consulting now.
[deleted]
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.)
(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...
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.
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.
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.
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.
>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.
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.
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.
My parents used to put me in after school education programs where they crammed memorization and "finding the trick" type problems. I'm not knocking that sort of thing, because it gave me a pretty solid problem solving kit, but most of this stuff is not at all relevant to any SWE job I've held. However, most people who are in tech companies are like me and are familiar with trick questions and memorization. So, that's how they test other people.
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.
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.
> 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.
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".
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".
> many - a sickeningly large amount
How many are we talking about here? How many years of experience did they have?
How many are we talking about here? How many years of experience did they have?
I'm getting to be a greybeard myself, I can't keep count of the awful people I've interviewed or worked with. I'm talking about people who are now in their 60s, with resumes that would make your eyes pop out. ex-SGI, ex-NASA, earlyish (late 80s) Apple/Microsoft guys.
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.
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.
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.
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.
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 think on hacker news you’re preaching to the converted - everyone here likes intellectual challenges, puzzles and technical mysteries.
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!
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!
The problem is that within an interview context, many times one is expected to just come up with a perfect solution within a short timeframe.
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.
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 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?
[deleted]
Just say - “no thank you”
And walk away
Could you give an example of what you consider a “leet code” interview?
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.
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.
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.
The problem (other than your casual insults) is that leetcode does not demonstrate the ability to conceive, plan, structure, or write code. The whole method behind it is nothing but rote memorization of trivia questions, almost all of which are pulled from one or two websites. There are piles of books made specifically to help people memorize the solutions to these puzzles. This has nothing to do with actual software engineering work which very rarely involves rote memorization.
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. 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.
When the OP gives any kind of examples of interviews gone bad, maybe we can discuss something meaningful. But the moment someone says they object to programming challenges that aren't "practical", that raises huge red flags. Too too too many people call simple programming demonstrations "irrelevant" and "impractical" and "not realistic" and "leetcode" and then proceed to show that their brains are mush, that they lack the talent for understanding code and what it's doing and why it was written and how to write it themselves. It's a meme at this point for people who call themselves software engineers to complain about being asked to write code because they're above it while simultaneously being terrible at it.
> 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.
> 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.
"design of a system"
The open-ended system design interview comes after the initial leetcode interview now.
The open-ended system design interview comes after the initial leetcode interview now.
And how does memorizing leetcode patterns demonstrate that?
I think it says bad things about the industry that so many people think you need to have seen them before to do them. Do you also memorize solutions to the advent problems before completing them?
I don't have to complete advent solutions in 20 mins while someone waits for me to demonstrate any reason to cut me from the 10 others they are interviewing that week. The problem is psychosocial, not technical. I'm not necessarily going to lose out to a better engineer, but a better leetcoder - I'm objectively terrible in leetcode interviews, unable to put two sentences together.
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.
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.
Is anyone else turning down riddle interviews? Or am I being unreasonable?