Have you actually every talked about code and architecture to another peer? If levels are cca same it quickly becomes an effortless exercise where ideas flow quickly and topics are immediately picked up. Lets call it brainstorming.
Why can't we repeat that in interview? I don't care if some dev can code some method names or detailed algorithms from his head, when it takes 3 seconds to find exact solution. In other words, there is little real added value from such a skill. You get much better peek into somebody's head with above - but it requires significantly more effort on interviewee's side, heck maybe even some preparation.
You can to certain extent hack leetcode process by just doing leetcode. Its much harder to be verbally fluent about designs, concepts and libraries that you never used. And for the rest, there is a trial period, you can't skip that 3 months experience and cram it into interviews.
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.
leetcode style interviews do not test the skills you need for what you describe, those skills come with experience, not by practicing leetcode until you can produce solutions in under a minute.
I agree. I don't think Leetcode is a good reflection of programming interviews. In programming interviews, you're supposed to have a sound thought process, write clean code, and don't need to pass hundreds of test cases. Leetcode is just a programming environment that, imo, is not the same as a programming interview.
I'd rather learn interview algorithms from books. And by getting feedback from trusted peers.
the problem with leetcode interviews is that it favors people who have the time to memorize optimal solutions to a large set of problems which they can reproduce in under 5 minutes. but those people have zero creativity and are not necessarily good engineers. they just mastered memorizing stuff.
I used to interview like this, until I hired the wrong person. They talked elequently about how to program, but just weren't very good at digging in to technical details of an existing codebase and understanding what was actually going on.
So I added an hour's pair programming on either toy problems or our existing codebase, depending what was suitable at the time. No leetcode, no months of prep for candidates, and our interview outcomes were much better.
There's a massive gulf between toxic leetcode hoop-jumping and a friendly chat.
Yup, leetcode at least is fairly easy to make interviewers competent enough at giving especially if you restrict the problems they can give. Although worst one me and my friends have gotten were system design. Friend got interrupted with questions every 30 seconds, told to just answer them directly and then failed for not elaborating deeply enough on things.
System design problems are much better and more realistic than leetcode style IMO. Let's be real, most developers don't need to have leetcode T9 solutions memorized because it with either never come up, or they can do some research when it does.
Knowing more about an entire system and architecting it requires a lot of variety of experience and it's just a more fun interview for everyone involved.
When I interview people, I also hope I'm assigned to conduct our architecture one because it really makes you learn a lot about an engineer.
At some of my past jobs and the current one, this kind of algorithmic knowledge was important to build features that were differentiators in the market. As much as people love to pretend, not every single possible solution is in a library. Sometimes you're the one building the library.
It doesn't have to be leetcode, but candidates should at least be able to produce some code that doesn't come from the README of their favourite framework.
Also, talking for 30/45 mins can be enough, but it produces false positives when you have people coaching candidates. I've had people completely acing interviews that it felt like the perfect candidate. Well, it was rehearsed. When I asked for a fizz-buzz type question they completely messed it up.
I find Leetcode discussions strange. I recently changed jobs so I was preparing by doing some Leetcode problems. The actual problems I was asked during the interview process were very simple compared to what I expected. Interviewers even explicitly stated that they wanted to see how I think, and the solution didn't even have to compile. So in my experience the whole idea that «Leetcode is harmful» is overblown a little bit.
To me the value of coding interviews are knowing enough algorithms/data structures to apply and adapt them to problems, being able to quickly sketch out your idea, and explain trade-ffs.
I fucking hate leetcode. It takes me about a month or two of practicing to get caught up and proficient with leetcode, but there's 2 issues with that. The first is that that is a lot of personal time and effort to invest to prepare for interviews. And second, my professional skill does not increase at all from practicing leetcode. Leetcode beyond the concepts of easy/medium questions is programming trivia and reflects rote memorization more than anything else. And worst of all, leetcode distracts from far more valuable skills like design patterns and how to properly architect and design software.
In the end, the only companies that should be doing leetcode beyond the easier level questions are companies with an insane number of applicants where they can afford to turn away a lot of good talent.
They need to come up with something better than leetcode. Build a project and explain it is a much better way to get a sense of skill. It's the sort of skill that won't be made extinct by ChatGPT. Your creativity and ability to architect and build a project and then explain it should be the standard. Leetcode also penalizes good engineers who have anxiety during interviews.
Yes, I am interviewing, but I'm offering a real world problem to solve for candidates, not an exercise picked from Leetcode. I actually enjoy Leetcoding type problems, so I'd love to grind those, so I as a candidate don't have problems with those - although still I'd rather be building stuff.
The real world problem most of the time resembles understanding instructions, navigating in an existing codebase, implementing some feature. This gives really good insight into how much they've built, how much they know or how much potential they have - for example if they are unfamiliar with some things, they are always allowed to Google and if they do it efficiently, that's very telling about their potential.
With Leetcode you won't know whether the person has actual skill or experience to build something or they just practiced Leetcoding for 6 months straight.
Interviews are only partially about testing your body of experience. They're also supposed to test your aptitude and ability to grow in the future.
If you were capable of studying Leetcode so hard that you mastered the interview process at one of the most selective software companies in the world in only a few months, it's not much of a stretch to imagine that you could apply that same aptitude, ambition, and ability to learn quickly toward picking up the basics of git, dev ops, and so on.
Arguably, this is one of the benefits of Leetcode-style interviews. They focus on core software engineering aptitude, while not arbitrarily excluding people because they didn't use the right VCS at their last job.
Yes. Communication is the biggest hurdle in any collaboration. I have not been part of multi stage interview process, so I don't know all problems there.
But my point was more that if you find leetcode hard-to-impossible on difficulty scale, it probably means you are self taught and didn't bother with data structures and algorithms lecture/book/video/course.
Again probably bad communication on my part.
Our interviews is slightly modified fizz buzz. What we are looking for is basic programming skills and ability to test your code. For take home also basic git usage.
Grind on leetcode until you can do any problem quickly. It's all that matters for interviewing and you'll get a job making more than people with 15 years of experience that can't leetcode but can create beautifully architected apps and systems.
> So why not give a simple coding test? Talk through peoples thought processes
What do you mean? That's pretty much what leetcode-style problems are during interviews. You get a problem with some theme, like "here is a list of airplane flights in an array composed of tuples, with the first member being origin, and the second being destination. Write code that would create full-blown routes out of those flight entries."
You ask questions, clarify constraints, come up with a few approaches, discuss with the interviewer pros and cons of each, decide to go with one, implement it while walking the interviewer through your thought process. And then you discuss limitations and edge cases, scalability concerns, how you would test it if it was a problem you were solving at an actual workplace, etc.
Leetcode-style interviewing doesn't typically refer to "we just pulled a random problem from leetcode, go ahead and solve it while I am standing over your shoulder, and we will check how correct the solution is afterwards." In fact, interviewers care way more about the thought process and your approach, as opposed to caring about your solution matching theirs. In fact, there were many cases where people ended up not solving the problem and passed the interview anyway, as well as cases where people solved the problem and ended up not passing. Because the process of arriving at the solution and the reasoning you took to get there matters way more when hiring (even if you didn't get there all the way to the correct solution), as opposed to just getting the correct answer. The fastest way to fail a leetcode-style interview is to sit down and write down the correct solution as fast as possible, without explaining your reasoning process or even anything at all.
Some people say that Leetcode is nothing more than rote learning. Some disagree and I disagree. There's a minimal amount of rote learning that helps but you need more than that. On the other hand "system design" interviews are...strange? You, someone who never built something at the scale of these giant tech companies, are being asked to come up on the spot with a design for a system that'd scale to billions of users. There's a 100% chance that if you were to attempt building such systems and you'd never done it before, you'd discover holes in your original design left and right. Leetcode tests your logic, how you think, your IQ maybe. But system design interviews consists in regurgitating knowledge that you've crammed in your head by studying books/articles/videos on system design. It's closer to reciting poetry than problem solving. In my experience it could be replaced with multiple choice questions and you'd get the same result.
As an interviewer I can tell you are absolutely missing the point.
Why would I ever want to hire a developer without seeing them perform? And since being able to program a small piece of code to specification is such a basic, important part of development, why would it be bad for me to verify if you can do it?
If your friends are so good developers, why would they have a problem reasoning around a relatively simple, toy problem? Is it possible that your evaluation of your friends' prowess is biased?
Why do you think dealing with problems under pressure is not a valuable skill?
Why do you think leetcode questions are supposed to tell about quality of code that the candidate will produce? Is it possible that you just don't understand what leetcode is for?
It all seems to me like students complaining that the exam was hard. IT DOES NOT MATTER if the exam was hard. What matters is if you were better than other students. (And even that does not matter, because in the long run it only matters if you have learned something useful.)
So what is the point here? I think people just complain too much rather than focus on figuring out how to succeed.
Leetcode questions are supposed to tell me:
- Can the candidate understand the question? Can they think about the problem analytically? (Somehow there are a lot of people that can have nice conversation but they fail when they are supposed to apply hygiene to their thinking.)
- Can they follow instruction? (I explain the rules of the task and am interested in seeing if the person is able to follow basic instruction)
- Can they program? (I met a lot of people over the years who are able to fake their way through the process EXCEPT for when they have to actually write some code. For example they learned standard library by rote but do not have ability to use those functions when needed.)
- Can they plan? Are they organised? (A lot of people just do stuff at random that might work for very small change but will utterly fail for any larger task. Good developer inevitably have some kind of plan and organisation.)
- Can they work with somebody else on the problem? (Some people don't know how to work with others even when offered help.)
- Do they understand what the program they wrote is doing? (MOST people do not know if their program works or not or what it does. They need to run the program to be able to tell. All best developers I ever worked with can tell what the program will do before they run it. Any person that can't do this is destined to be creating huge number of bugs as they mindlessly retry code until it works in the process leaving every bug that did not stop it from working in their test environment.)
- Are they intelligent (enough)? (Leetcode is sort of intelligence test. You typically need to be at least at some intelligence level to solve the problem.)
The problem with leetcode is all those interviewers that do not understand how to use it as a tool to learn things about the interviewee. And that frequently is because they want to get information that you can't easily from leetcode.
So what you can't learn from leetcode question?
- Will they write nice code? You can't learn this because writing nice code is ability to adhere to the body of code you are already working with. Everybody's programming style is different and even best style might still be incomprehensible to a person that is not used to it.
- Knowledge. Do not ask stupid questions like how to transform a binary tree in a certain way because they only thing you are testing for is whether the candidate is lucky to know the answer to your problem.
- Can they solve complex problems? Do not give complex problems on interview. It is just too noisy and luck-driven. Perfect question is just complex enough to be novel and present some (but not too much) challenge to the candidate but not complex enough to run the risk of running out of time for a reasonable candidate.
Why can't we repeat that in interview? I don't care if some dev can code some method names or detailed algorithms from his head, when it takes 3 seconds to find exact solution. In other words, there is little real added value from such a skill. You get much better peek into somebody's head with above - but it requires significantly more effort on interviewee's side, heck maybe even some preparation.
You can to certain extent hack leetcode process by just doing leetcode. Its much harder to be verbally fluent about designs, concepts and libraries that you never used. And for the rest, there is a trial period, you can't skip that 3 months experience and cram it into interviews.
reply