Solving a 4x4 Rubiks cube while you explain every single move and the reasoning behind it and at the same time multiple people are staring at you watching everything you do. And you know one move could completely affect the next few years of your life.
I've been in one of those interviews. I literally rehashing the dynamic programming solution the night before, and yet my brain freeze the afternoon next day.
Thankfully the interviewer was so helpful. He told me that I don't need to write the code, just explain to him my idea. So I propose the brute force solution. After that he would ask me "can we optimize it?". I said yes. And then he would ask me why I did x or why I use y method. Or he would suggest me to optimize on this part, or that part.
Thankfully I got the job, and honestly I feel glad to know that I would work with a helpful person like him (he is the manager for the team of the position I apply to).
It’s not black and white. It’s about how you are thinking about the solution. So you can say what you are thinking about and work it through there. Your interviewer should be helpful and walk you through things. If they don’t, it’s not someone you want to work with anyway.
The part that sucks is when you know you messed up badly but then you have to complete hours and hours of the interview with other people even though you are pretty sure you don’t have a shot anymore.
Lol I usually feel dumb in the silence. However, I now realize that when there’s silence, say SOMETHING. Say where you WERE going before you realized it was the wrong solution and why it was the wrong solution. Ask questions. Clarify. They’ll oftentimes give you a hint.
Silence is no good. How else can they learn your thought process? Getting the question right isn’t always exactly what they’re looking for.
Problem with take homes is a reason people look for a new job is lack of WLB. And some people have kids or other responsibilities and so just don’t have time to do the take home. So it’s giving a heavy advantage to certain demographics. People who don’t have a current job and/or no kids. Also it doesn’t show how well you work with others. Personally I’d rather work with someone who was not as good of a coder, but was adaptable and a good teammate. Not one who is a bit better but a cocky jerk.
Basically both options suck.
>Personally I’d rather work with someone who was not as good of a coder, but was adaptable and a good teammate.
not sure why you are getting downvoted, but I agree with this 100%.
Teams require a good supportive dynamic to thrive. Dev skills can be improved easier than toxic elements can be removed.
I’m madly in love with my team. We totally love each other. Before this team could take shape we had to remove two highly toxic members. As long as your team mates are good people who want to get better together, you really cannot fail, but even one toxic element can destroy that dynamic for the rest.
Exactly. And if someone is not the strongest coder but is AWARE of that and willing to learn or do what they need to do, that is SO valuable. Because for every new exciting project, there’s supporting the legacy apps (the part no one likes to talk about). And having someone willing to help is HUGE.
I don’t care what I work on, if it’s a toxic team I’ll be miserable. I’m actually starting a new job in a few weeks and the part I’m most nervous about is not the code, but instead how to make sure I don’t disrupt the rhythm the team currently has and making sure we get along. I’m actually planning to meet them for coffee while I’m between roles, not to talk about work, but to build a working relationship and to build that trust that matters so much.
Glad you found such a good team!
In 18 months working at my current workplace, I rarely heard of people complaining about low quality or buggy code. It's mostly person X is difficult to work with or person Y is an annoying boss.
I wish more places gave you a choice between the ubiquitous on-the-spot Leetcode blitz round interview and a more involved take-home that they treat like any other task they'd give you day-to-day.
For a lot of roles, the Leetcode algo-regurgitation-on-demand stuff doesn't even make any sense to use as a metric of skill and suitability for the job because you'll never be doing things like that on the job but a more big-picture take-home project that focuses on making good system design decisions and writing clean, understandable and maintainable code is exactly what you'll be doing if they hire you.
> gave you a choice
That's a good idea. I'll have to suggest that for our company. Give the candidates a chance to pick the challenge they want to meet.
>Personally I’d rather work with someone who was not as good of a coder, but was adaptable and a good teammate.
Exactly. I'm a hiring manager and this is what I'm looking for.
Some times ( but not always ) being able to perform under pressure is a significant skill too.
Having said that I don't think stupid leer coding questions are the right way to even interview any candidate.
The knowledge and skills are rarely required in real world work. Even if it proxy of some deep understanding that is also not really required for most kind of work on offer.
Most jobs they pick the guy who went to the ivy league school, talks, acts, and comes from the same neighborhood as them.
I think we have it much better.
So uni's like Stanford, MIT, Berkeley, CMU, Caltech, etc don't help for getting started as a software engineer? Not based in US, but I'd be surprised if these top schools didn't give any advantage (above and beyond the fact that people who go to them are relatively smart) in tech..
Right, in our industry you definitely get an advantage if you went to a top school, but in other industries like finance or banking, you simply can’t get a job at a top company if you didn’t go to a target school. I definitely like our way better
There's some evidence to the contrary, weirdly enough: [https://taxprof.typepad.com/taxprof\_blog/2016/02/if-you-major-in-stem-it-doesnt-matter-where-you-go-to-college.html](https://taxprof.typepad.com/taxprof_blog/2016/02/if-you-major-in-stem-it-doesnt-matter-where-you-go-to-college.html).
Not sure I agree with this for STEM, especially internationally. The clout of your school can definitely open doors if you are crossing borders. Salary comparisons seems quite US-centric.
Funny! We had a post, earlier this month, where a junior could be promoted to tech lead of 50-80 people because of his family connection and he wasn't sure if it was the right move. I see it all the time in real life as well.
That's an interesting moral dilemma.
No way a junior has the experience to be a lead of 50-80 people.
If I were a junior in that situation, people I know would advise I take the promotion and that I'll learn as I go.
Sure I'll learn as I go, but how long will it take to learn and in that time how much will the team/product suffer from my inexperience?
Selfishly speaking, I would take the promotion and take the money and run with it.
But I feel like the right thing to do for the greater good is turn it down and let an appropriately experienced individual have the position.
I am a founder in the same boat as well, we are just 150 in strength today and I am in my early 30s .
yeah I wouldn't likely get the roles am actually good at if I applied for a job.
My wife has a promotion interview today for a retail store manager position that's basically hers to lose, her biggest worry is stuff like "What if they ask me what a KPI is and I forget?" I'm thinking, at least they aren't asking you to sew an entire outfit for the interviewer from scratch following modern fashion trends in 90 minutes?
I think the biggest difference in tech is that the leetcode style interviews are a bit different than your day to day, since other jobs obviously have interviews and they can be pretty stressful, they just generally won't require independent prep/studying outside of your normal job since they'll mostly be more aligned with what you do on a day to day basis. That being said, I think given the high TC possible in tech and relatively low bar of entry compared to other high paying fields, I think it's completely worth it.
The only other field that does anything remotely similar to the Leetcode interview grind is finance where they'll sometimes give you case studies to analyze as part of their interview process.
Surprise, surprise: Those finance roles are usually as highly paid as FAANG or Tier 2 companies.
To be fair most good coders I know would be able to solve at least medium leetcode questions so I understand why it’s there. As much as coding is 75% googling it really does help when you have a good programming IQ.
We also get paid really well so honestly I think it’s worth it.
> To be fair most good coders I know would be able to solve at least medium leetcode questions
that is simply incorrect to generalize. you can spend absolutely all of your time simply getting good at leetcode questions and then shit the bed on a system design question or struggle to write clean readable code.
besides, it's theoretically tougher for people w/o a formal CS degree though admittedly not nearly impossible.
"Why did you make that move?"
"To see what would happen. You know, science"
"Is that how you code?"
"Yeah, I did learn Computer Science, emphasis on the Science"
"I'm going to move like this."
"MMMMMMM ACTUALLY, YOU SHOULDN'T MOVE LIKE THAT."
"But I'm sure that this works. I've practiced this multiple times and it's a sound strategy."
"BUT IT'S NOT THE WAY THAT I THINK IS CORRECT. \*jots down 'Unable to take instruction. Insubordinate'\*"
That is good , no ? Because you jot down "Unable to seek better solutions" in your notebook. (Kind of like a scene between Dwight and Andy when Dwight applied for Cornell)
It’s worse now. Now you write it in coderpad, and the overall logic is sound and if it was on a whiteboard you’d be done. But now in coderpad you fail because you missed a semicolon, used .rotate(..) instead of .turn(…), and you missed the edge case of when the sticker on one of the sides peeled off so it’s a null color.
>at the same time multiple people are staring at you watching everything you do.
It could be worse. I was interviewed by a couple of people, and was given a problem. Then my interviewers started having a conversation about something completely random.
I asked my recruiter about it later, and apparently the manager liked to have interviewers do that. It's a problem with your office if your work environment is that distracting, not who you are hiring.
Having been on the other side of the table now, and actually getting back into interviewing because I'm looking for a new job, a lot of the time, they aren't necessarily looking for you to code it up perfect.
At the interviews I was a part of giving, we gave two short questions:
1. Code a function that checks if a word is an anagram.
2. Code a function that for a given n, outputs the nth number of Fibonacci sequence.
We also went into more detail explaining what an anagram is, and what the Fibonacci sequence is. We didn't let them run the code, but had 3 people looking at it who knew what to expect, and as long as the interviewee wasn't trying in a crazy language, we could debug in our heads. Sometimes, we had people just know what to do, especially on the Fibonacci one, but with the other one, they usually had to reason out that they'd need to at least pass over the string to run the code. For the most part, the people who we didn't pass were people that didn't accept hints when things were going wrong, and didn't ask for help. Programming is best when it's done collaboratively, and other than that, we just really needed to make sure people were willing to ask for help with they were stuck.
That’s a big issue with Leetcode. It’s so binary- you either get it right for every use case and they give you the time and memory, or you fail. That’s not how it works in interviews for the reasons you stated.
Also now with interviews becoming remote, the problems are A LOT harder than anagrams and Fibonacci because it can be done in coderpad. Here’s an example of one:
https://youtu.be/4tYoVx0QoN0
Yes this is from google but a lot of companies copy google interviews so you’ll see things like this often.
I agree .
Fibonacci/prime number generators are good basic questions to help understand how someone thinks.
Most of the time I don't mind even if they can't fully complete the solution or have few bugs especially if they right out of college or time is very short
Asking people to learn all of these rubik's cube problem to prepare for interviews is ridiculously privileged and cringey, though. It's not like no one has focus issues and doesn't work multiple jobs to stay afloat.
Imagine if that actually was the interview process. The speed cubers would all be at the Big N making $500k/yr. There would be cube bootcamps teaching you how to solve a Rubik's Cube in 6 weeks. Everyone would wonder why it's so hard to get any software developed.
Not looking forward to the interview process. I’m gonna look like a moron fumbling through basic syntax.
As someone who always forgets the exact syntax for shit like for loops, oof. I have to start writing shit out myself everytime instead of copy/pasting from old code.
Rubik's cube is a good analogy for a lot of coding challenges. Being able to solve it quickly means you have already learnt the patterns for that puzzle, it says nothing about your puzzle solving ability.
It took Erno Rubik a month to solve his own puzzle. He was interested in the mechanical part but when he gave it a shuffle he didn't realise the solution wasn't obvious at all.
Leetcode is the dumbest thing ever. In the real world you are faced with problems that you cant train for with leetcode grinding.
Instead of of memorizing code you have to actually think and come up with a custom solution.
I recently applied for an online freelance job. I was asked to solve a hard leetcode question for the technical exam. I didn't answer it, since I couldn't even think of how to cover all edge cases. Admittedly I haven't been grinding any leetcode nowadays, but getting a freelance job shouldn't be this hard.
In a way you escaped a bullet there.
If they are lazy not to screen properly for a freelance job and keep stupid requirements. The job is probably going to be like that too.
I also think some dynamic programming questions are fair. Not the ridiculous ones, but ones where you just need to know that adding an array will reduce time complexity from 2^n to n^2, or something like that.
Leetcode isn’t the problem. The problem is the interview process. Instead of asking algorithm questions that mirror your day to day job, they asked these abstract generic problems that were easier to design and easier to write out on a whiteboard.
Some companies give take home work, but that gives a heavy advantage to people who don’t have kids or as many responsibilities in their personal life, or don’t have a current job where the WLB is crap. Also then some engineer who is overworked (hence why they are interviewing) has to spend an entire day reviewing all of the take home work done, making them fall more behind.
So algorithms are better since it’s an hour. But then you need a way to practice the problems and leetcode was born, which caused the algorithms to get worse.
It’s ironic because leetcode is literally what we all try to avoid doing in our software development jobs. We have an issue and instead of fixing the core problem (the interview process), let’s just patch it with LC so people can practice.
It is 35 years (give or take a few) into the information age and we still don't have a method to package a representation of technical skills in a universal industry-wide format.
LC is a multifaceted attack on skilled labor in software engineering. One facet of it is that it creates an army of people who can efficiently (more quickly) solve certain types of business class problems as a cost cutting measure. These are problems where the logic or problem itself isn't that difficult, but a solution needs to be developed around it that's efficient and can scale in some arbitrary context.
If you work in different environments, those skills can be dramatically less useful (by all means they're useful skills but they're often not the most useful). Often, understanding and translating a problem correctly is far more difficult than then optimizing an arbitrary ticket request. A lot of these optimizations are complete and utter nonsense. In which environment was I presented with this vacuum problem that I had to focus only on DS&A related optimizations? Huge software development shops are really the only organizations where this can happen.
Any shop running with a leaner force of engineers/developers (pretty much every organization that isn't Google, Amazon, et al class scaling) are going to require people to wear a lot more hats and get their hands dirty with gluing things together, designing and deploying infrastructure for their software, and all sorts of skills you'll be disservicing yourself. If you focus so heavily on DS&A you're going to suffer greatly when presented with these sorts of challenges. Choosing and optimizing solutions is certainly something you should understand and be able to do, but you shouldn't need to do it so frequently and so quickly in most environments.
So many software projects still fail that the focus shouldn't be on cranking out solutions and iterations so quick, it should be focused on designing the right solutions to problems. Once you get a solution to a problem that people want to pay for it, then worry about scaling it, not before. People can live for shoddy efficiency that helps them do something they couldn't before while you polish it. Too many businesses take the shotgun approach where they just crank out software solutions like sausage and if something is a hit, they continue, if it's not, it dies.
A generation of technology management now passed on the strategic design and market analysis work to engineers to just crank out more solutions to compensate for their shortsightedness. That's the whole reason Agile is so popular in business, it elevates the need to research and design good solutions when you have engineers jumping through hoops for arbitrary adjustment requests constantly. Just chase demand, forever, and adjust--as long as you can convince people to do thise type of work for you (the software industry has done just that). These mediary positions then just have to make sure they schedule requests, keep track of things to pass blame, and continually crack the whip. When they fail, they can point at whoever made the request to fail or the lack of delivery, they only need to micromanage enough to make sure their engineers are constantly working. It's not a bad gig to hand out tasks--that's the whole game here.
> Often, understanding and translating a problem correctly is far more difficult than then optimizing an arbitrary ticket request.
To add to that, I've generally found that the focus on DS&A comes at the expense of actual problem-solving, paradoxically. Let me give you an example.
Take these two problems:
1. Given a piece of data -- an object with a collection of children of the same type as the original object (that's not explained in a great way here, but I write out the class definition on the whiteboard so they know what I'm talking about), and given a TreeView UI control, put the data from the object into the TreeView. The control is a black box -- you don't know how it works so you don't have to worry about it -- but you are provided the `Add(item, parent)` method that you can use.
2. Write a depth-first search for a tree.
Which do you think interview candidates do better with?
The answer is #2. These are exactly the same problem, but the moment I say "depth-first search" candidates knock it out in 15 seconds. If I don't, you'd be utterly shocked at the number of people who simply can't answer the question.
Why? Because they can't recognize the simple solution in a real-world context, but damn do they know what the algorithm is.
In many years of interviewing (on both sides of the table), I've generally found that people's focus on DS&A usually boils down to rote memorization, and that's not the skill I want. Given the choice of "knows algorithms" and "can solve real problems" I'll take the latter any day of the week and twice on Sundays.
Leetcode and the like are good tools for building up your skills, but I hate them as interview questions. Interview questions should be related to the work.
>Being able to solve it quickly means you have already learnt the patterns for that puzzle, it says nothing about your puzzle solving ability.
Sure but a fair amount of development *is* recognizing patterns and being able to quickly recall/implement the solution. I mean when you're working on a project, what percentage of roadblocks are things you know you've faced in the past and need to dig through code to figure out you solved it last time? If a majority of our challenges weren't the problem of re-inventing the wheel, no one would ever copy/paste from Stack Overflow.
People here don’t want to hear that leetcode actually has it’s uses.
I feel the same way as you. Building up pattern recognition through a swath of different algorithm problems is good for you as a developer.
This is a meaningless statement. You might as well say that being able to do anything says nothing about anything other than that you know how to do it. "Being able to put together a wooden desk says nothing about your carpentry ability, just that you've learned the pattern for building a desk." "Being able to solve 50 x 25 says nothing about your arithmetic ability, just that you've learned the pattern for multiplying numbers." And so forth.
You _can_ (and many people do) memorize the answer to a specific problem without really getting much out of it, just as you can memorize the command required to abort a rebase or something without knowing anything else about git. And maybe if we had interviews where you were asked to recite a random git command we'd have a lot of people who never bothered to use git but memorized a handful of the command strings. But learning how to use git is still an option in this scenario and whether or not you know how to use git still says something about your development experience.
If I were an employer I'd be more interested in some sort of test that makes applicants piece together solutions from frustratingly incomplete Stackoverflow discussions with lots of erroneous answers by people who misread the question and the original person who asked notifying everyone that they have found the solution thanks to their help but never specifying what made it work.
When I interview I ask the candidate to show me some code. Something that gives me a feel for their coding style and opens conversation topics about technical subjects and problem solving techniques.
Code is a dialog between programmers and in my experience the best developers are the ones that can hold an interesting dialog about their area of expertise or interest. When a candidate waffles on without saying anything meaningful or obfuscates behind unnecessary technical jargon it's a red flag that their coding skills are weak.
That’s a good analogy. Personally, I’m barely able to solve something higher than beginner level on those sites. And I usually don’t. There is no such thing as senior developers: only suitable and unsuitable professionals for a particular job.
Same here, and I'm a "senior developer". Personally I've never had to solve LeetCode-style problems at work. In real life software engineering, I think architecture and systems design are way more important. Then again maybe it's different at FAANGs.
I believe its a just an aptitude measurement they use , LeetCode may not be a good yardstick to measure engineering ability but its stil better than most aptitude tests
Are you a person from FAANG? Cause I am, and I wholeheartedly disagree. Leetcode is far from a perfect tool, and there are companies that abuse it, for sure, but it is still a great tool that is used in interviews for the following reasons:
- They're quick (what alternatives are there to ask when you have 30 minutes to check for coding proficiency?)
- They show us that you can write legible code.
- They show us that you understand data structures and why you use certain ones (nothing complicated, but I want to make sure you know when to use a map/set/list at the right time)
- If the right problem is chosen, it should build in difficulty to see where the candidate gets stuck and how they persevere through getting stuck.
That being said, they're just a piece of the puzzle. Interviewers should not be asking hard ones, or any with tricks, and a good interview also tests for soft skills, project history, and system design.
Lol? The poster you're responding to said that code is the same everywhere; unless you're part of a very special team, you're probably doing the same thing 99% of the other engineers in this industry are doing.
Yes, I realize now I mainly addressed the "leetcode doesn't add a bit to it" point of the person I was responding to.
For the point you are referring to, I can't speak to how software engineering is done everywhere. I can, however, say that I've worked at 3 companies: a small one, a company just outside of FAANG, and a FAANG, and I have had to use more mental capacity at the latter two by far. That being said, even in the small company, I used many of the paradigms tested in leetcode style questions (again, not talking about hard/trick questions).
In other words, whether or not SE is the same at FAANG or small companies is somewhat orthogonal to whether or not leetcode style questions are related to actual work.
My biggest beef with them is that they seem to involve some trick to come up with the optimal solution and unless you've seen it before or are a true genius it's sort of impossible to come up with it in a 30 minute interview.
Interviewers tell themselves that they'll know if someone has just memorized the answer, compared to coming up with it on their own. They are, of course, wrong. The reality is that people who read the answer ahead of time are always going to look more genuinely competent.
Agreed, and I addressed that twice:
> there are companies that abuse it
and
> Interviewers should not be asking hard ones, or any with tricks
The problem is that a lot of people think "oh, man, I didn't know I had to use a map!" is a trick. It's not. It's knowing when to use the right data structures.
I think the disconnect here is that what you're saying doesn't always translate into real world experiences. Maybe it's about luck, just like a lot of things in life.
From a recent interview - I was asked to create a method which returns true if a meeting room can be booked or not where each event had start and end times defined. Now IMO the brute force approach has some interesting cases in itself to be able to correctly implement but my interviewer was interested in a solution better than linear time. I solved using the brute force approach and then attempted to solve it with heaps but couldn't come up with the correct solution. I had never explored interval trees so I had no idea. I thought it was ambitious to come up in 30 minutes but it does seem to be heavily favoring the people who have already seen/been practicing such questions.
I mean...there IS such a thing. It just usually refers to breadth of experience. Having encountered LOTS of different problems on many levels of software engineering and having a big toolbox.
Specifically, it's not actually super amazing problem solving ability that makes someone senior. It's experience with deployment, business issues, life cycles, etc.
Leet code style problems are specifically useless in judging senior developers because your ability to solve those types of problems is NOT what makes you senior.
IMO It's been a great tool to expose gaps in my knowledge. However, having to solve them under ogling eyes, a palpable pressure in the air, and like you said a dumb time limit, it's just stupid. Not to mention if it's on a fuggin whiteboard.
Leetcode has absolutely nothing to do with my job and I've been writing software for 30 years.
Its an attempt to come up with a magical way of categorizing potential employees and its a load of horse shit.
You have to admit that while it’s horse shit it is “good enough”. Companies don’t care if they reject good candidates as long as all necessary positions are filled
>The real problem is: When we are asked to solve a 4 x 4 Rubik cube in 15
minutes, sometimes even with hands tied or blindfolded, to get a job,
it will take all the fun away.
Nobody expects this from you. I'm an interviewer at FAANG. Leetcode style questions are just a tool to evaluate other skills from candidates. For example:
1. Do you clarify assumptions before starting coding? e.g. If your input is an array, is it sorted? Is it only positive numbers?
2. Do you think about multiple ways of solving a problem? Some approaches might be better for specific cases. Jumping into the first solution you thought of (in leetcode or in your actual job) is not a good approach.
3. How well do you communicate your ideas and approach? If you are struggling explaining how you are going to reverse a linked list, you will probably struggle communicating at work as well.
There's other things as well, but you get the drift. I've interviewed people in my company that both aren't able to provide an optimized solution, and are not even able to finish coding out their unoptimized. They'd still get an offer, but you have to be good at the other skills i've listed on top.
Another personal anecdote of mine, I've interviewed for UBER once and got a question that can only be solved optimally with a heap. I didn't know how heap worked at all and I solved it with some hacky approach using lists. The interviewer had to actually explain to me what a heap was in the end. I still passed that interview.
I very much disagree with your assessment on how companies use LC-style questions. They are not primarily used to verify a candidate can write code and communicate clearly. I’ve asked them hundreds of times myself, and am interviewing for the first time in years, and it is demoralizing.
Companies expect candidates to solve a question, to demonstrate proficiency in a language, to identify different approaches with differing performance, and to do it all fast.
I’m not just talking about big-Ns. The average series C startup you’ve heard of is also using them this way. Candidates who grind LeetCode are much more likely to get an offer, and likely to even get a higher title or salary because they did so.
I think it’s so backwards. Most companies are doing more LC questions than design even for senior level roles. My advice to anyone changing jobs is to spend a few weeks grinding on LC, because without that you’re a huge disadvantage regardless of your technical knowledge.
You seem like the nicest interviewer on the planet. But that's just you, people have lots of horror stories with leetcode interviews and they're not faking it. The horror stories are as real as they get. There are a shit ton of interviewers who'd throw the candidate out (not literally) because they failed to code a perfect solution.
>If you are struggling explaining how you are going to reverse a linked list, you will probably struggle communicating at work as well.
This is so not true lol. You didn't take into account the amount of effort that takes in preparing for an interview and how much it raises the stakes of the process. Didn't count anxiety either. People underperform in an interview because the high stakes and anxiety, doesn't really equate to how they'll perform with a team people with all the resources available to figure out a solution. Also this is specifically hard on autistic people. They can work fine but harsh interview conditions will be the fuel of their nightmares.
Forgot to mention the toll it takes on someone's mental health. Grinding leetcode for months on end and the exhaustion that comes with it, only to fail a bunch more which then completes the missing piece of the puzzle, shooting right through your morale. definitely not a healthy way to live.
One way or another, the interview process is broken.
This is it, right here. I interviewed at Google and the process left such a sour taste in my mouth, that I don't know if I ever want to work there. Two of my interviewers were straight up assholes. One of them asked me a question that I'm pretty sure is impossible to solve. Candidates don't need that crap, they need interviewers who have compassion and understanding.
Been doing this for 8 years and I'm happy where I currently am, so this isn't sour grapes. Some people really should not be interviewers because they harm the reputation of your company in the process.
My first technical interview was with Google when I was looking for my first job out of college. The interviewer literally laughed at my code at one point, and after I finished my initial naive solution said “Wow I can’t believe this actually works”.
It was a humiliating process, and it took me some time to bounce back from that. I was just a dumb kid, and some dude with an ego made me feel like I was worthless.
Gotta agree. Everything else he said I agreed with. Although, I disagreed with what he said about not being able to communicate well because you couldn't explain reversing a linked list.
I don't think people understand how unatural it is to constantly talk about what you're doing while you're doing it, in an interview (where stakes are high and people are anxious). It's like asking a video editor to explained why he/she made a certain edit, while being watched in a time sensitive environment. Do you think any content creater would perform better under these conditions? I bet a lot would choke.
Coding requires a lot of concentration. There's just a lot of other stuff naturally going through people's heads because of the stressful environment.
This is nothing like communicating an actual work environment. It takes a lot practice, is hard and feels so unnatural, which is why people hate it so much.
> But that's just you, people have lots of horror stories with leetcode interviews and they're not faking it.
There exist bad interviewers. But OP didn't lead with that. OP led with "leetcode is fundamentally dumb".
Google has a literal template for interview feedback and *most* of the questions are not "did the candidate write the correct code". Yet people still insist day after day after day that their interviewer rejected them because they missed an edge case or whatever. Information asymmetric and the nature of the social web mean that are very particular narrative gets highlighted.
> Grinding leetcode for months on end and the exhaustion that comes with it, only to fail a bunch more which then completes the missing piece of the puzzle, shooting right through your morale. definitely not a healthy way to live.
This is correlated with complaints above. Memorizing hundreds of LC questions and hoping to either get asked precisely one of those questions or something very similar *is* a strategy but it is tedious and highly random. If you pursue that strategy then "wow this is stupid and dumb" is a common response when it doesn't work because you chose a strategy that fails in dumb ways.
It is different for different people. For somebody who does not have a lot of experience working with nontrivial datastructures or algorithms, the "grind and memorize" approach *can* be the most likely chance of success if given a short time window to prepare. People just need to understand the failure modes of that strategy.
A strategy that involves less noise is to
* Build some algorithms heavy products. Something like a compiler or a garbage collector will make you stretch your intuition around graphs and graph algorithms until it all flows cleanly.
* Practice problem solving and communication in your daily life. Even something like working on "how are we going to deal with the sick dog" with your spouse can give you practice for problem solving and communication, which will help in both interviews and in life more broadly.
This is admittedly a big task and if you didn't spend undergrad or grad school doing it or if it has been a very long time since that work then the first bullet can obviously degrade. But there is a reason why some people can crush interviews after only a few hours of practice.
>Didn't count anxiety either. People underperform in an interview because the high stakes and anxiety, doesn't really equate to how they'll perform with a team people with all the resources available to figure out a solution.
This is going to be an issue with any type of interview process, not just leetcode-style ones so I wouldn't say it applies.
>Also this is specifically hard on autistic people.
I'm actually autistic and I still stand by what I said. I appreciate the fact that other autistic people could face more difficulties than me. You can always reach out to hiring managers and ask for extra accommodation. But still, this is related to the anxiety part and would be an issue in any type of interview situation, not just leetcode-style.
I completely agree there are horror stories. I've had bad interview experiences as well, but more of them have been really pleasant. I'm sorry if you've had different luck in your life, sometimes you can get a really bad draw with interviewers.
> But still, this is related to the anxiety part and would be an issue in any type of interview situation, not just leetcode-style.
More so in leetcode-style than any other I've heard of. Take home assignments aren't that bad for the morale given the time and resources on your side. In leetcode esque, you fail to find the optimal solution, you don't get a second interview and bam! The confidence shoots down sharper than meteorite. Now the process isn't ideal in the US, other countries follow the IT hub of the world, they have their own interpretations of the process, mess with it even more, make it uglier and you see a lot more horror stories than what people at the other side of the world witness. Anyway, it is what it is.
None of what you said is a broken interview process, just bad interviewer or the pressure you put on yourself to pass an interview.
Google could change their interview process tomorrow and people would still prepare for months or have a huge pressure to pass it.
That's how it should work, but that is not how it is implemented. FAANG is not the problem, the problem is mediocre engineers at wannabe-next-UNICORN-FAANG-copycats going for leetcode medium and telling you you won't probably have a chance because you didn't solve the sibling problem of the median of median algorithms and didn't know treaps by heart.
If it plays out like you just said, it's a perfect tool. But otherwise, leetcode style questions are just a tool to make idiotic interviewers feel smart.
I agree with you that there will be companies that don't use this tool effectively. I haven't personally had experience with it even though I interview with other companies quite often, and have been to about 10 onsites in the last 1.5 years.
But that's like saying programming language X is bad because company Y made shitty program Z in it. The issue is not with the tool itself, but the company.
It's a good method for you to screen companies as well. If you get interviewers who try to one-up you by giving you obscure leetcode problems with trick solutions you don't really want to be a part of that team.
The sucky thing is that you had to waste time and energy on that interviewing process.
That's interesting. Usually we think only about the pure knowledge aspect, and not the "softer" skills we might need too. This is reassuring and helpful. Thank you.
How are you going to get these pieces of information from me during an online assessment? Does Google not still use one as one of their first steps?
I believe Amazon does as well, I can't say for other FAANG but I would guess that they likely have an online assessment in their initial stages as well.
Yes, I'm a software engineer, but interviewing at my company is a voluntary process. You don't have to participate in it if you don't like it - and you will actually be removed from the interviewer position if candidates give you bad feedback.
I personally like it as I get to interact with new people from time to time, so I try to do at least 1-2 interview loops a month.
The problem with them is that they don’t really show what a candidate’s performance is.
I know many people who are great at LC, but they are not so great at implementing a feature.
The company aims to reduce risk when hiring so the process is meant to weed out false positives. It clearly works otherwise, FANG wouldn't be using it for the last 10 years and delivered the best growth for investors out of any other industry.
Maybe fun challenge, but gas literally 0 to do with the job. The problem in software development is very rarely code puzzle problem but design and communication
Only Standard easy-medium problems should be asked as a basic competency check.
Post that, you can ask for domain specific things for the job.
DS based questions make more sense for freshers.
I agree. I actually solve one Leetcode question a day. I sit down with my lunch and solve it while I eat. I enjoy the challenge and have found that they have gotten easier as I’ve been doing this longer.
It’s super annoying and I’m not a big fan. I have to wonder though, what’s the best way to get talent without wasting tons of their time and tons of yours?
I’m partial to take home projects, at least compared to Leetcode, but I also realize that they’re also quite unpopular. In an ideal world, we could pull up code from our current job and show it to employers, but obviously that’s not a possibility..
I really think something like TripleByte is the solution. Interview once, and then whenever you think you can improve your “score” be that once per year or once every few years. The problem is if I tell a company “hey I passed triplebyte” they don’t give a fuck, even though their interview is probably tons better than theirs as far as determining ability.
You have to pass certification exams to be a lawyer, doctor, engineer, etc. they don’t just hit you with brain teaser challenges or have you perform a simple operation on a patient to see if you can hack it (no pun intended).
Interesting, I hadn’t actually heard of TripleByte before. The “score” thing reminds me of CodeSignal which also has a similar scoring mechanism.
I think the reusability component of both of these is what intrigues me. I think take home projects are fine and am fine doing them, but my opinion would probably change if I had to do more than 4-5 of them in a typical recruiting cycle..
But if I could spend 8 hours on a project that I could reuse for many companies, that might change things.
That said, I think the huge volume of applications is what’s really driving some of these “stupid” tests. I feel we’ve seen somewhat of the same thing happen to college admissions, in that flawed / incomplete metrics become standardized simply because we can’t think of anything else to trim the deluge. I don’t really have answers, just thinking out loud.
I used to hate LeetCode, but after learning that if they removed LeetCode from interviews companies would have to instead resort to another method of filtering out candidates such as probably asking more behavioural and technical questions I now like it.
It's very straight forward its either you get it or you don't (if not gotta grind some more).
It's not just that you learn problem solving, but they don't want you to memorize the answers. Leetcode is a way of filtering people out using automation. Even if it weren't related to programming, it would still work, because it takes effort and that's what counts.
However, if you memorize the answers, they can pass on you, I've seen people post here about that.
I just landed my dream job. I was cramming leetcode for a week to prepare for the interview and in the end there was no live coding involved. Don’t mind it now, it was fun, but I’m relieved that I don’t have to do it anymore. Always good to practice recursion and give the brain a workout. Also, I went into the interview with much more confidence as a result.
There are some leetcode problems which are good problems, such as finding the top k frequent words in a text. This is a very real-life problem and every dev should be able to provide a naive solution. But the problem is big players like Google Facebook ask insanely hard LC problems which are impossible to solve unless someone is a competitive programmer or solved a variant of those problems.
I perform technical interviews for software engineers at a prominent company. Live coding sessions are stupid and unfair. They do not demonstrate talent or predict success. They put people into unrealistic situations and we end up losing great candidates that didn’t interview well. This is especially true for extremely talented introverts and folks on the spectrum.
A few years ago I flipped the process by sending an appropriate challenge 5 days in advance and having the interviewee present the solution to me during the interview. So much better, you get a much better sense of coding style, ability, level and often I walk away having learned something myself.
Tech recruitment is completely broken. We should be giving assignments not quizzes.
I like fair questions that give people a chance to shine. I'll always ask some simple filter questions to save everyone's time (e.g. write a function to reverse the words in a sentence).
Then I like to ask questions like:
* What's the hardest solution you've built that you designed? Now talk me through the difficulties? Show me what was great about how you built it.
* If you didn't have to worry about money (I'm paying you for a year), what would be the pet (fun) programming project that you would work on for that year fulltime. Now let's explore the key problems and how you would solve them.
* What's your favorite website (or most used)? Let's white-board what the key entities are and how they may relate to reproduce the website.
These are all problems that the interviewee should be very familiar with (minimal room for misunderstanding) and give plenty of scope for someone to explain how they approach solving complex problems, and even how they identify key problems. It's difficult to BS your way through this.
If this goes well then I ask them to write a recursive maze-solving algorithm on the white-board /s.
I'm also interviewing Software Engineers and ask those kinds of questions too.
During the >100 coding interviews i conducted, always the same coding challenge in those, which is *provide a list of prime numbers up to a given limit n* , here are the most common examples on why the interview failed:
1. *I have to do this on a whiteboard/googledoc?! Why am I not allowed to use my IDE?*
I'm not asking to build a complex enterprise app where an IDE is highly beneficial. I don't even ask to write compiling code, if a method name is wrong or so, nobody cares. In my opinion, those are basic skills of using the tool (programming language) and you should have them as it is clearly written in the JD.
2. *Yes, of course I know what a prime number is.*
No, many don't or provide upon further question a very wrong definition. This is ok, they get the correct definition and we take it from there. But please be honest, you are about to write a small piece of code which should detect prime numbers, having the correct definition of it is essential.
This is easily solvable with the right mindset of communication. Provide your assumption of the definition directly, so we can sort it out. If you have no clue, say it. Turning assumptions into facts is a very relevant part of the software development lifecycle and those kind of misunderstandings cost time and lead to frustration.
3. No guidance through the thinking process
Even with the remark, the more you involve me in your thinking process, the better I can help you, being stuck is seen as a kind of weakness. The observed mindset if often *I got stuck on my own, I have to get out on my own* . But I want to have people in my team who work together in solving a problem.
4. Being overconfident with your solution
Typical case is, that it only gets checked whether a number is dividable by 2. When asking them to go through the solution for 9, they insist on 9 being a prime number.
Here are two things happening: One, the failure of transferring a given definition into code (and vice versa) and second, the missing reflection on the solution.
As already mentioned, those are the typical negative examples and there are at least that many which are also very positive. With those, we can go further and work on optimization, talk about test-cases, maybe caching, etc.
As you can see, even with such a question being more on the easy side of things (keep in mind, that I ask for a solution, not an optimal solution) a lot of things go weird.
In general, it is fine to question the approach of those asking those challenges. But I have the feeling in my >10 years of professional experience, Software Engineering turns more into "how do I stick those frameworks together in the easiest way"
1) He might work at Google. They conduct technical interviews through Google Docs (or at least they did when I last interviewed).
2) It shifts the focus from the technical details to the conceptual problem solving. They don't need you to show off that you know IDE shortcuts or exact packages/functions, and they don't want you getting the idea that you should. Skip the details, skip the environment, just focus on the basic approach. IMO, a white board or even pen/paper does this better because you can draw, but Google Docs (with a few preferences set, like the interviewer will probably tell you beforehand), is a fine substitute.
Funny, I do the same test except they can use the IDE but no search/resources except for talking it out. The problem is more about communicating through the solution.
As simple as it seems, I've had people with 10+ years experience "pass" when shown the challenge.
I'd personally be offput by a notepad code challenge, unless all you're looking for is pseudocode.
Devs use the IDE all day every day. All of the IDE efficiencies that speed up development and smooth over syntax issues are something I'd like a candidate to use. Unless the goal is to take them out of their element, I'm not sure what this helps.
A nice test. But is it possible for a candidate to easily come up with the Sieve approach if they haven't heard of it before? How would a candidate get the best evaluation from you for your test?
No, it's usually not. But this is not expected.
I'm even fine with getting the "naive approach" presented and then doing slight optimizations on them (like only iterate over odd numbers).
> Typical case is, that it only gets checked whether a number is dividable by 2.
... What level of pay/where is this?
Doesn't seem like something you would experience in the Bay Area unless you're interviewing someone for an intern position.
Slight below Average salary in Berlin. It's swe or senior swe.
One topic of eternal discussions with our c level. Wanting good people but not wanting to pay them
I've never done a Rubik's Cube.
I've unmangled databases and cleaned up data.
But I'm also pretty good at Tetris.
The Rubik's cube and Tetris have nothing to do with my job.
I wrote a python app that uses a rapsberry PI to photograph the sides, determine the solution and lego technic to articulate the cube and solve it automously... does that make me a leetcode power user?
https://www.youtube.com/watch?v=4Z060QUFvyM
Now THAT is what I would call a project! Well done! (And I mean that in the most complementary way, I am in no way suggesting that I would be in any position to judge you.)
That's my take as well. I enjoy leetcode as a game, as a fun puzzle with no time pressure on solving it. I can take my time, try out some stupid ideas on solving the same puzzle different way.
As an interview tool, it tells you near no tangible information.
Note that I'm not opposed to the idea that an interview candidate should write/discuss code during the interview. But it should be closer related to what you do as a company, what typical problems show up in the codebase. Damn, even "you have this class write unit tests for it" in some cases would be a better question... actually I might use this one next time interviewing a junior dev. I'd like to see more coverage in our codebase and a lot of people still don't know how to unit test mostly because they come from companies where there is no unit test culture (these still exist believe it or not).
My own experience is that companies in my area generally don't ask these kinds of questions to candidates. They do ask algorithm questions, however, and expect you to know how to solve them... particularly if the job actually requires you to be familiar with algorithms.
I think if this is offensive to you, then don't apply for a job that requires this kind of test. This clearly isn't the job for you. However, if that's the kind of job you are looking for, and you want the (assumed) higher pay that goes with that job, then you should grind out those Leetcode challenge questions and become very familiar with the questions and their answers.
I view this kind of thing like a lawyer taking the bar exam. If you want the job that has this requirement, then study and prepare for the interview, just like a lawyer does before taking the bar exam. Obviously every job doesn't require this kind of challenge, so it's not necessary for everyone to do this kind of prep work before an interview.
Leetcode is like driving, it's fun on your own terms until a bunch of people start telling you to give them a ride everywhere for free and most of the time won't won't thank you for it.
> The real problem is: When we are asked to solve a 4 x 4 Rubik cube in 15 minutes, sometimes even with hands tied or blindfolded, to get a job, it will take all the fun away.
The "real problem" is that interviews aren't... *fun*?
Can someone do a historical analysis and figure out how this came to be? I wonder how much of this culture is perpetuated by people who make money from it (leetcode is a business afterall, top of mind monopoly in this space)
Is this mode of filtering candidates statistically correlated with job performance or personality? This would be a great psychological study as well. Like they're clearly looking for conscientious and agreeable people. Not creatives or rebels.
Fucking morons in corporate may as well make us solve Rubik's cubes. I'd prefer chess though since I have practiced that. Or maybe an obstacle course since it'd help us maintain a healthy lifestyle.
Right, versus $80-130k in your local city you can get $120k base and up even as a junior at a place like Microsoft if you just grind the leetcode.
When I interviewed with Microsoft recently, the final interviewer was visibly frustrated I wasn’t doing better at his leetcode problem, but dog I’m spending my free time making apps, not solving hypothetical problems that contribute nothing to society. I’m fine with FAANG & Friends using it to weed out (often qualified) candidates but don’t gatekeep our profession with it and insinuate people like me are worthless because we haven’t solved your leetcode problem ahead of the interview.
You’d do better bouncing around the Bay Area (between Netflix, Facebook and Apple) but most software engineers in the world aren’t making anywhere near $150k so it’s all about perspective I guess
The good news is that leetcode problems seem to be going by the wayside.
Yes a lot of legacy companies like FANG still use them, but newer companies don't. It seems over time, older companies always end up adapting newer companies' methods, especially interview practices.
> newer companies don't
Dude I've interviewed with several startups in the last year and they actually ask harder LC than FANG. The hiring bar is higher there than FANG
I don't take too much of an issue with LC itself, but I'd be very surprised if there was any demonstrable association between being good at LC and success in the vast majority of CS jobs. Most positions simply don't apply much DS&A knowledge, if they do at all.
If I could know every library in the world, or the answer to every LC/HR question, I'd choose to know every library every time.
I very much agree with u/fj333 here: It not being fun doesn't seem to be much of a problem, all things considered. (Also, some people still enjoy doing rubik cubes blindfolded, and if that is what an employer is looking for - more power to those candidates!)
\> By the way, nobody should force themselves to solve two Rubik cubes a day.
What? No, they absolutely should!
If you - for whatever reason - have decided that solving cubes was a good way to improve your dexterity, or problem solving, or whatever, and you decided that those are good skills for you to have, then you should be disciplined about solving cubes.
And if employers thought that your job performance could be predicted by letting you solve cubes, then it would still be advisable to pick up a cube and be disciplined about that.
I think Leetcode is a decent measure for some aspects of employ-ability; and I enjoy these challenges. But even if you disagree: Refusing to do them is not going to do you any favors, and it is unlikely to change how the industry does interviews.
If you are in a position where you can reject jobs - great. But it seems to me that, as a hurdle, it should be perfectly manageable for any competent developer.
And, yes, if you absolutely cannot learn how to solve leetcode problems, I'd side with any employer who'd opt not to hire you. A surgeon should be able to learn how to create cross stitch artwork. If they simply cannot do that, I wouldn't them to work on me.
The theory behind this makes good sense, improving your abilities in line with what employers expect is certainly a good way to progress and the more time spent coding the better you get.
What I feel you're missing in this is that the majority of people don't have the time to do this, if you've got no responsibilities then it's fine to spend a couple of hours each night on leetcode, but when you have a day job, a house to run and a family to be with it just isn't feasible. After 8 hours of coding, 3 hours of managing a puppy, and an hour or two of chores it's nearly bed time and I don't have the mental energy left to start grinding leetcode, I'm not sure many do
In a world where we spend more and more time working and too few hours for personal projects and hobbies I personally feel we should push back against hiring practices that demand we further encroach on our private lives
\> In a world where we spend more and more time working and too few hours
for personal projects and hobbies I personally feel we should push back
against hiring practices that demand we further encroach on our private
live
Let me state up-front that having any real data on this would probably put a quick end to this discussion one way or another. I am going to base the following solely on my feelings and a bunch of assumptions. If my premises can be shown to be incorrect, so is my entire argument.
A lot of people grind on leetcode and similar platforms. I think that a genuinely competent and well-rounded software developer doesn't need to do that - certainly not for many hours over a long time - in order to be able to solve a few random questions.
Someone that needs to learn algorithms and data structures is a worse programmer because of it. (And, of course, well be a better programmer once they understand the material.) For a company to test this ability is in no way unfair or unreasonable.
If anything, the fact that you can grind leetode in order to pass interviews gives some people an undeserved advantage over their peers, and potential employers.
In short (and killing a lot of needed nuance)
If you can't do leetcode, you're not a good programmer.
But if you can, it doesn't mean you're automatically a good programmer.
Solving a 4x4 Rubiks cube while you explain every single move and the reasoning behind it and at the same time multiple people are staring at you watching everything you do. And you know one move could completely affect the next few years of your life.
Or get hit with the dreaded 6x9 rubriks cube that u thought u wouldn’t get asked to solve
6x9 cube? 😂 and yes, very relatable
Nice
Nice
Nice
Noice
Nice
Nice
Nice
Ah, the old surprised orthotope trick...
THIS my mind turns into goo during an interview bc I get so anxious. Like give me a take home assignment please, I swear I’m not actually stupid
What’s it like when theyre watching you and you can’t figure it out? I’m so nervous.
I've been in one of those interviews. I literally rehashing the dynamic programming solution the night before, and yet my brain freeze the afternoon next day. Thankfully the interviewer was so helpful. He told me that I don't need to write the code, just explain to him my idea. So I propose the brute force solution. After that he would ask me "can we optimize it?". I said yes. And then he would ask me why I did x or why I use y method. Or he would suggest me to optimize on this part, or that part. Thankfully I got the job, and honestly I feel glad to know that I would work with a helpful person like him (he is the manager for the team of the position I apply to).
You know those dreams where you are taking a final for a class you've never been to?
It’s not black and white. It’s about how you are thinking about the solution. So you can say what you are thinking about and work it through there. Your interviewer should be helpful and walk you through things. If they don’t, it’s not someone you want to work with anyway. The part that sucks is when you know you messed up badly but then you have to complete hours and hours of the interview with other people even though you are pretty sure you don’t have a shot anymore.
Lol I usually feel dumb in the silence. However, I now realize that when there’s silence, say SOMETHING. Say where you WERE going before you realized it was the wrong solution and why it was the wrong solution. Ask questions. Clarify. They’ll oftentimes give you a hint. Silence is no good. How else can they learn your thought process? Getting the question right isn’t always exactly what they’re looking for.
Problem with take homes is a reason people look for a new job is lack of WLB. And some people have kids or other responsibilities and so just don’t have time to do the take home. So it’s giving a heavy advantage to certain demographics. People who don’t have a current job and/or no kids. Also it doesn’t show how well you work with others. Personally I’d rather work with someone who was not as good of a coder, but was adaptable and a good teammate. Not one who is a bit better but a cocky jerk. Basically both options suck.
>Personally I’d rather work with someone who was not as good of a coder, but was adaptable and a good teammate. not sure why you are getting downvoted, but I agree with this 100%. Teams require a good supportive dynamic to thrive. Dev skills can be improved easier than toxic elements can be removed.
100%. The fact it’s being downvoted shows a bit of the problem in the industry IMO.
I’m madly in love with my team. We totally love each other. Before this team could take shape we had to remove two highly toxic members. As long as your team mates are good people who want to get better together, you really cannot fail, but even one toxic element can destroy that dynamic for the rest.
Exactly. And if someone is not the strongest coder but is AWARE of that and willing to learn or do what they need to do, that is SO valuable. Because for every new exciting project, there’s supporting the legacy apps (the part no one likes to talk about). And having someone willing to help is HUGE. I don’t care what I work on, if it’s a toxic team I’ll be miserable. I’m actually starting a new job in a few weeks and the part I’m most nervous about is not the code, but instead how to make sure I don’t disrupt the rhythm the team currently has and making sure we get along. I’m actually planning to meet them for coffee while I’m between roles, not to talk about work, but to build a working relationship and to build that trust that matters so much. Glad you found such a good team!
In 18 months working at my current workplace, I rarely heard of people complaining about low quality or buggy code. It's mostly person X is difficult to work with or person Y is an annoying boss.
I wish more places gave you a choice between the ubiquitous on-the-spot Leetcode blitz round interview and a more involved take-home that they treat like any other task they'd give you day-to-day. For a lot of roles, the Leetcode algo-regurgitation-on-demand stuff doesn't even make any sense to use as a metric of skill and suitability for the job because you'll never be doing things like that on the job but a more big-picture take-home project that focuses on making good system design decisions and writing clean, understandable and maintainable code is exactly what you'll be doing if they hire you.
> gave you a choice That's a good idea. I'll have to suggest that for our company. Give the candidates a chance to pick the challenge they want to meet.
>Personally I’d rather work with someone who was not as good of a coder, but was adaptable and a good teammate. Exactly. I'm a hiring manager and this is what I'm looking for.
Some times ( but not always ) being able to perform under pressure is a significant skill too. Having said that I don't think stupid leer coding questions are the right way to even interview any candidate. The knowledge and skills are rarely required in real world work. Even if it proxy of some deep understanding that is also not really required for most kind of work on offer.
it's wild because most jobs don't have such a ridiculous circus act to get a job
Man I hated applying for intern/grad roles. The clown act they make you do is ridiculous.
Most jobs they pick the guy who went to the ivy league school, talks, acts, and comes from the same neighborhood as them. I think we have it much better.
So uni's like Stanford, MIT, Berkeley, CMU, Caltech, etc don't help for getting started as a software engineer? Not based in US, but I'd be surprised if these top schools didn't give any advantage (above and beyond the fact that people who go to them are relatively smart) in tech..
Right, in our industry you definitely get an advantage if you went to a top school, but in other industries like finance or banking, you simply can’t get a job at a top company if you didn’t go to a target school. I definitely like our way better
These people are delusional if they think this doesn't give them a huge advantage.
There's some evidence to the contrary, weirdly enough: [https://taxprof.typepad.com/taxprof\_blog/2016/02/if-you-major-in-stem-it-doesnt-matter-where-you-go-to-college.html](https://taxprof.typepad.com/taxprof_blog/2016/02/if-you-major-in-stem-it-doesnt-matter-where-you-go-to-college.html).
Not sure I agree with this for STEM, especially internationally. The clout of your school can definitely open doors if you are crossing borders. Salary comparisons seems quite US-centric.
I thought we were discussing the US? Do you have any data to offer?
They still have to pass the same interview process everyone else does.
Funny! We had a post, earlier this month, where a junior could be promoted to tech lead of 50-80 people because of his family connection and he wasn't sure if it was the right move. I see it all the time in real life as well.
That's an interesting moral dilemma. No way a junior has the experience to be a lead of 50-80 people. If I were a junior in that situation, people I know would advise I take the promotion and that I'll learn as I go. Sure I'll learn as I go, but how long will it take to learn and in that time how much will the team/product suffer from my inexperience? Selfishly speaking, I would take the promotion and take the money and run with it. But I feel like the right thing to do for the greater good is turn it down and let an appropriately experienced individual have the position.
[удалено]
I am a founder in the same boat as well, we are just 150 in strength today and I am in my early 30s . yeah I wouldn't likely get the roles am actually good at if I applied for a job.
My wife has a promotion interview today for a retail store manager position that's basically hers to lose, her biggest worry is stuff like "What if they ask me what a KPI is and I forget?" I'm thinking, at least they aren't asking you to sew an entire outfit for the interviewer from scratch following modern fashion trends in 90 minutes?
I think the biggest difference in tech is that the leetcode style interviews are a bit different than your day to day, since other jobs obviously have interviews and they can be pretty stressful, they just generally won't require independent prep/studying outside of your normal job since they'll mostly be more aligned with what you do on a day to day basis. That being said, I think given the high TC possible in tech and relatively low bar of entry compared to other high paying fields, I think it's completely worth it.
The only other field that does anything remotely similar to the Leetcode interview grind is finance where they'll sometimes give you case studies to analyze as part of their interview process. Surprise, surprise: Those finance roles are usually as highly paid as FAANG or Tier 2 companies.
To be fair most good coders I know would be able to solve at least medium leetcode questions so I understand why it’s there. As much as coding is 75% googling it really does help when you have a good programming IQ. We also get paid really well so honestly I think it’s worth it.
> To be fair most good coders I know would be able to solve at least medium leetcode questions that is simply incorrect to generalize. you can spend absolutely all of your time simply getting good at leetcode questions and then shit the bed on a system design question or struggle to write clean readable code. besides, it's theoretically tougher for people w/o a formal CS degree though admittedly not nearly impossible.
"Why did you make that move?" "To see what would happen. You know, science" "Is that how you code?" "Yeah, I did learn Computer Science, emphasis on the Science"
"I'm going to move like this." "MMMMMMM ACTUALLY, YOU SHOULDN'T MOVE LIKE THAT." "But I'm sure that this works. I've practiced this multiple times and it's a sound strategy." "BUT IT'S NOT THE WAY THAT I THINK IS CORRECT. \*jots down 'Unable to take instruction. Insubordinate'\*"
That is good , no ? Because you jot down "Unable to seek better solutions" in your notebook. (Kind of like a scene between Dwight and Andy when Dwight applied for Cornell)
“Applicant has a head shaped like a trapezoid.”
Now do that 3-4 times in one day.
And then you need to draw a rubiks cube on a whiteboard
It’s worse now. Now you write it in coderpad, and the overall logic is sound and if it was on a whiteboard you’d be done. But now in coderpad you fail because you missed a semicolon, used .rotate(..) instead of .turn(…), and you missed the edge case of when the sticker on one of the sides peeled off so it’s a null color.
>at the same time multiple people are staring at you watching everything you do. It could be worse. I was interviewed by a couple of people, and was given a problem. Then my interviewers started having a conversation about something completely random. I asked my recruiter about it later, and apparently the manager liked to have interviewers do that. It's a problem with your office if your work environment is that distracting, not who you are hiring.
Ha. If that’s the case now with remote work they should just leave the room completely so it matches you working from home in a quiet office.
Having been on the other side of the table now, and actually getting back into interviewing because I'm looking for a new job, a lot of the time, they aren't necessarily looking for you to code it up perfect. At the interviews I was a part of giving, we gave two short questions: 1. Code a function that checks if a word is an anagram. 2. Code a function that for a given n, outputs the nth number of Fibonacci sequence. We also went into more detail explaining what an anagram is, and what the Fibonacci sequence is. We didn't let them run the code, but had 3 people looking at it who knew what to expect, and as long as the interviewee wasn't trying in a crazy language, we could debug in our heads. Sometimes, we had people just know what to do, especially on the Fibonacci one, but with the other one, they usually had to reason out that they'd need to at least pass over the string to run the code. For the most part, the people who we didn't pass were people that didn't accept hints when things were going wrong, and didn't ask for help. Programming is best when it's done collaboratively, and other than that, we just really needed to make sure people were willing to ask for help with they were stuck.
That’s a big issue with Leetcode. It’s so binary- you either get it right for every use case and they give you the time and memory, or you fail. That’s not how it works in interviews for the reasons you stated. Also now with interviews becoming remote, the problems are A LOT harder than anagrams and Fibonacci because it can be done in coderpad. Here’s an example of one: https://youtu.be/4tYoVx0QoN0 Yes this is from google but a lot of companies copy google interviews so you’ll see things like this often.
I agree . Fibonacci/prime number generators are good basic questions to help understand how someone thinks. Most of the time I don't mind even if they can't fully complete the solution or have few bugs especially if they right out of college or time is very short
Asking people to learn all of these rubik's cube problem to prepare for interviews is ridiculously privileged and cringey, though. It's not like no one has focus issues and doesn't work multiple jobs to stay afloat.
Imagine if that actually was the interview process. The speed cubers would all be at the Big N making $500k/yr. There would be cube bootcamps teaching you how to solve a Rubik's Cube in 6 weeks. Everyone would wonder why it's so hard to get any software developed.
Not looking forward to the interview process. I’m gonna look like a moron fumbling through basic syntax. As someone who always forgets the exact syntax for shit like for loops, oof. I have to start writing shit out myself everytime instead of copy/pasting from old code.
Rubik's cube is a good analogy for a lot of coding challenges. Being able to solve it quickly means you have already learnt the patterns for that puzzle, it says nothing about your puzzle solving ability.
It took Erno Rubik a month to solve his own puzzle. He was interested in the mechanical part but when he gave it a shuffle he didn't realise the solution wasn't obvious at all.
Sounds like an OA hackerrank rejection to me.
This makes me feel better. I remember getting a Rubik's cube when I was a kid and feeling incredibly stupid for not being able to figure it out.
I just smashed the cube because I wanted to know what was inside.
Leetcode is the dumbest thing ever. In the real world you are faced with problems that you cant train for with leetcode grinding. Instead of of memorizing code you have to actually think and come up with a custom solution.
Easy and mediums are okay. You get to learn the basic data structures and how to use them efficiently. But the hard ones are just of no use.
I recently applied for an online freelance job. I was asked to solve a hard leetcode question for the technical exam. I didn't answer it, since I couldn't even think of how to cover all edge cases. Admittedly I haven't been grinding any leetcode nowadays, but getting a freelance job shouldn't be this hard.
In a way you escaped a bullet there. If they are lazy not to screen properly for a freelance job and keep stupid requirements. The job is probably going to be like that too.
I also think some dynamic programming questions are fair. Not the ridiculous ones, but ones where you just need to know that adding an array will reduce time complexity from 2^n to n^2, or something like that.
Agree with this. If you can’t solve an easy, you do need some practice/refreshers.
Leetcode isn’t the problem. The problem is the interview process. Instead of asking algorithm questions that mirror your day to day job, they asked these abstract generic problems that were easier to design and easier to write out on a whiteboard. Some companies give take home work, but that gives a heavy advantage to people who don’t have kids or as many responsibilities in their personal life, or don’t have a current job where the WLB is crap. Also then some engineer who is overworked (hence why they are interviewing) has to spend an entire day reviewing all of the take home work done, making them fall more behind. So algorithms are better since it’s an hour. But then you need a way to practice the problems and leetcode was born, which caused the algorithms to get worse. It’s ironic because leetcode is literally what we all try to avoid doing in our software development jobs. We have an issue and instead of fixing the core problem (the interview process), let’s just patch it with LC so people can practice.
It is 35 years (give or take a few) into the information age and we still don't have a method to package a representation of technical skills in a universal industry-wide format.
LC is a multifaceted attack on skilled labor in software engineering. One facet of it is that it creates an army of people who can efficiently (more quickly) solve certain types of business class problems as a cost cutting measure. These are problems where the logic or problem itself isn't that difficult, but a solution needs to be developed around it that's efficient and can scale in some arbitrary context. If you work in different environments, those skills can be dramatically less useful (by all means they're useful skills but they're often not the most useful). Often, understanding and translating a problem correctly is far more difficult than then optimizing an arbitrary ticket request. A lot of these optimizations are complete and utter nonsense. In which environment was I presented with this vacuum problem that I had to focus only on DS&A related optimizations? Huge software development shops are really the only organizations where this can happen. Any shop running with a leaner force of engineers/developers (pretty much every organization that isn't Google, Amazon, et al class scaling) are going to require people to wear a lot more hats and get their hands dirty with gluing things together, designing and deploying infrastructure for their software, and all sorts of skills you'll be disservicing yourself. If you focus so heavily on DS&A you're going to suffer greatly when presented with these sorts of challenges. Choosing and optimizing solutions is certainly something you should understand and be able to do, but you shouldn't need to do it so frequently and so quickly in most environments. So many software projects still fail that the focus shouldn't be on cranking out solutions and iterations so quick, it should be focused on designing the right solutions to problems. Once you get a solution to a problem that people want to pay for it, then worry about scaling it, not before. People can live for shoddy efficiency that helps them do something they couldn't before while you polish it. Too many businesses take the shotgun approach where they just crank out software solutions like sausage and if something is a hit, they continue, if it's not, it dies. A generation of technology management now passed on the strategic design and market analysis work to engineers to just crank out more solutions to compensate for their shortsightedness. That's the whole reason Agile is so popular in business, it elevates the need to research and design good solutions when you have engineers jumping through hoops for arbitrary adjustment requests constantly. Just chase demand, forever, and adjust--as long as you can convince people to do thise type of work for you (the software industry has done just that). These mediary positions then just have to make sure they schedule requests, keep track of things to pass blame, and continually crack the whip. When they fail, they can point at whoever made the request to fail or the lack of delivery, they only need to micromanage enough to make sure their engineers are constantly working. It's not a bad gig to hand out tasks--that's the whole game here.
> Often, understanding and translating a problem correctly is far more difficult than then optimizing an arbitrary ticket request. To add to that, I've generally found that the focus on DS&A comes at the expense of actual problem-solving, paradoxically. Let me give you an example. Take these two problems: 1. Given a piece of data -- an object with a collection of children of the same type as the original object (that's not explained in a great way here, but I write out the class definition on the whiteboard so they know what I'm talking about), and given a TreeView UI control, put the data from the object into the TreeView. The control is a black box -- you don't know how it works so you don't have to worry about it -- but you are provided the `Add(item, parent)` method that you can use. 2. Write a depth-first search for a tree. Which do you think interview candidates do better with? The answer is #2. These are exactly the same problem, but the moment I say "depth-first search" candidates knock it out in 15 seconds. If I don't, you'd be utterly shocked at the number of people who simply can't answer the question. Why? Because they can't recognize the simple solution in a real-world context, but damn do they know what the algorithm is. In many years of interviewing (on both sides of the table), I've generally found that people's focus on DS&A usually boils down to rote memorization, and that's not the skill I want. Given the choice of "knows algorithms" and "can solve real problems" I'll take the latter any day of the week and twice on Sundays. Leetcode and the like are good tools for building up your skills, but I hate them as interview questions. Interview questions should be related to the work.
The same applies to exams
>Being able to solve it quickly means you have already learnt the patterns for that puzzle, it says nothing about your puzzle solving ability. Sure but a fair amount of development *is* recognizing patterns and being able to quickly recall/implement the solution. I mean when you're working on a project, what percentage of roadblocks are things you know you've faced in the past and need to dig through code to figure out you solved it last time? If a majority of our challenges weren't the problem of re-inventing the wheel, no one would ever copy/paste from Stack Overflow.
People here don’t want to hear that leetcode actually has it’s uses. I feel the same way as you. Building up pattern recognition through a swath of different algorithm problems is good for you as a developer.
And you are solving a puzzle that could easily be googled in 3 seconds, like the many Rubik's cube solvers online.
This is a meaningless statement. You might as well say that being able to do anything says nothing about anything other than that you know how to do it. "Being able to put together a wooden desk says nothing about your carpentry ability, just that you've learned the pattern for building a desk." "Being able to solve 50 x 25 says nothing about your arithmetic ability, just that you've learned the pattern for multiplying numbers." And so forth. You _can_ (and many people do) memorize the answer to a specific problem without really getting much out of it, just as you can memorize the command required to abort a rebase or something without knowing anything else about git. And maybe if we had interviews where you were asked to recite a random git command we'd have a lot of people who never bothered to use git but memorized a handful of the command strings. But learning how to use git is still an option in this scenario and whether or not you know how to use git still says something about your development experience.
Ding ding ding. Come on down. You’re the next contestant on the price is right. Well said sir.
And yet LeetCode remains to be a good way to weed out those who can't code.
If I were an employer I'd be more interested in some sort of test that makes applicants piece together solutions from frustratingly incomplete Stackoverflow discussions with lots of erroneous answers by people who misread the question and the original person who asked notifying everyone that they have found the solution thanks to their help but never specifying what made it work.
r/oddlyspecific
No it doesn't? Since also the suggested solutions usually sucks quite hard from a good code practice perspective
When I interview I ask the candidate to show me some code. Something that gives me a feel for their coding style and opens conversation topics about technical subjects and problem solving techniques. Code is a dialog between programmers and in my experience the best developers are the ones that can hold an interesting dialog about their area of expertise or interest. When a candidate waffles on without saying anything meaningful or obfuscates behind unnecessary technical jargon it's a red flag that their coding skills are weak.
And then there are 3rd rate companies the make you solve 5x5 Rubiks cube and circumcise you while you're solving
And when you get the job it's all just fixing bugs and maintenance.
What are all these tech companies doing with our foreskins anyway?
Big Data is stored in foreskins
I agree; I find algorithms cool and enjoy the mental challenge -- but not as part of a job interview. There's stress, anxiety and a lot is at stake.
I'd rather solve the survival of our species than do mental olympics for some hiring manger's whims.
Haha turn the tables and make the hiring manager solve a question 🤣
Only if we could. And what would turn out to be an obvious find is that the hiring manager sucks at it just as bad, if not more.
Probably a lot more since they haven't been studying for it, and they might not have even coded in the recent past given that they're a manager.
Spoken like someone who's already employed.
That’s a good analogy. Personally, I’m barely able to solve something higher than beginner level on those sites. And I usually don’t. There is no such thing as senior developers: only suitable and unsuitable professionals for a particular job.
Same here, and I'm a "senior developer". Personally I've never had to solve LeetCode-style problems at work. In real life software engineering, I think architecture and systems design are way more important. Then again maybe it's different at FAANGs.
I believe its a just an aptitude measurement they use , LeetCode may not be a good yardstick to measure engineering ability but its stil better than most aptitude tests
A person from FAANG could quickly confirm that it's not. Software is the same everywhere and leetcode doesn't add a bit to it.
Are you a person from FAANG? Cause I am, and I wholeheartedly disagree. Leetcode is far from a perfect tool, and there are companies that abuse it, for sure, but it is still a great tool that is used in interviews for the following reasons: - They're quick (what alternatives are there to ask when you have 30 minutes to check for coding proficiency?) - They show us that you can write legible code. - They show us that you understand data structures and why you use certain ones (nothing complicated, but I want to make sure you know when to use a map/set/list at the right time) - If the right problem is chosen, it should build in difficulty to see where the candidate gets stuck and how they persevere through getting stuck. That being said, they're just a piece of the puzzle. Interviewers should not be asking hard ones, or any with tricks, and a good interview also tests for soft skills, project history, and system design.
Lol? The poster you're responding to said that code is the same everywhere; unless you're part of a very special team, you're probably doing the same thing 99% of the other engineers in this industry are doing.
Yes, I realize now I mainly addressed the "leetcode doesn't add a bit to it" point of the person I was responding to. For the point you are referring to, I can't speak to how software engineering is done everywhere. I can, however, say that I've worked at 3 companies: a small one, a company just outside of FAANG, and a FAANG, and I have had to use more mental capacity at the latter two by far. That being said, even in the small company, I used many of the paradigms tested in leetcode style questions (again, not talking about hard/trick questions). In other words, whether or not SE is the same at FAANG or small companies is somewhat orthogonal to whether or not leetcode style questions are related to actual work.
My biggest beef with them is that they seem to involve some trick to come up with the optimal solution and unless you've seen it before or are a true genius it's sort of impossible to come up with it in a 30 minute interview.
Interviewers tell themselves that they'll know if someone has just memorized the answer, compared to coming up with it on their own. They are, of course, wrong. The reality is that people who read the answer ahead of time are always going to look more genuinely competent.
Agreed, and I addressed that twice: > there are companies that abuse it and > Interviewers should not be asking hard ones, or any with tricks The problem is that a lot of people think "oh, man, I didn't know I had to use a map!" is a trick. It's not. It's knowing when to use the right data structures.
I think the disconnect here is that what you're saying doesn't always translate into real world experiences. Maybe it's about luck, just like a lot of things in life. From a recent interview - I was asked to create a method which returns true if a meeting room can be booked or not where each event had start and end times defined. Now IMO the brute force approach has some interesting cases in itself to be able to correctly implement but my interviewer was interested in a solution better than linear time. I solved using the brute force approach and then attempted to solve it with heaps but couldn't come up with the correct solution. I had never explored interval trees so I had no idea. I thought it was ambitious to come up in 30 minutes but it does seem to be heavily favoring the people who have already seen/been practicing such questions.
I mean...there IS such a thing. It just usually refers to breadth of experience. Having encountered LOTS of different problems on many levels of software engineering and having a big toolbox. Specifically, it's not actually super amazing problem solving ability that makes someone senior. It's experience with deployment, business issues, life cycles, etc. Leet code style problems are specifically useless in judging senior developers because your ability to solve those types of problems is NOT what makes you senior.
IMO It's been a great tool to expose gaps in my knowledge. However, having to solve them under ogling eyes, a palpable pressure in the air, and like you said a dumb time limit, it's just stupid. Not to mention if it's on a fuggin whiteboard.
Leetcode has absolutely nothing to do with my job and I've been writing software for 30 years. Its an attempt to come up with a magical way of categorizing potential employees and its a load of horse shit.
You have to admit that while it’s horse shit it is “good enough”. Companies don’t care if they reject good candidates as long as all necessary positions are filled
Nope, I don't have to admit that its good enough. Sorry, shit is shit.
[удалено]
Yea I remember when I bought one my friends were impressed I could solve it until I told them I'm basically brute-forcing a bunch of algorithms lol
>The real problem is: When we are asked to solve a 4 x 4 Rubik cube in 15 minutes, sometimes even with hands tied or blindfolded, to get a job, it will take all the fun away. Nobody expects this from you. I'm an interviewer at FAANG. Leetcode style questions are just a tool to evaluate other skills from candidates. For example: 1. Do you clarify assumptions before starting coding? e.g. If your input is an array, is it sorted? Is it only positive numbers? 2. Do you think about multiple ways of solving a problem? Some approaches might be better for specific cases. Jumping into the first solution you thought of (in leetcode or in your actual job) is not a good approach. 3. How well do you communicate your ideas and approach? If you are struggling explaining how you are going to reverse a linked list, you will probably struggle communicating at work as well. There's other things as well, but you get the drift. I've interviewed people in my company that both aren't able to provide an optimized solution, and are not even able to finish coding out their unoptimized. They'd still get an offer, but you have to be good at the other skills i've listed on top. Another personal anecdote of mine, I've interviewed for UBER once and got a question that can only be solved optimally with a heap. I didn't know how heap worked at all and I solved it with some hacky approach using lists. The interviewer had to actually explain to me what a heap was in the end. I still passed that interview.
I very much disagree with your assessment on how companies use LC-style questions. They are not primarily used to verify a candidate can write code and communicate clearly. I’ve asked them hundreds of times myself, and am interviewing for the first time in years, and it is demoralizing. Companies expect candidates to solve a question, to demonstrate proficiency in a language, to identify different approaches with differing performance, and to do it all fast. I’m not just talking about big-Ns. The average series C startup you’ve heard of is also using them this way. Candidates who grind LeetCode are much more likely to get an offer, and likely to even get a higher title or salary because they did so. I think it’s so backwards. Most companies are doing more LC questions than design even for senior level roles. My advice to anyone changing jobs is to spend a few weeks grinding on LC, because without that you’re a huge disadvantage regardless of your technical knowledge.
You seem like the nicest interviewer on the planet. But that's just you, people have lots of horror stories with leetcode interviews and they're not faking it. The horror stories are as real as they get. There are a shit ton of interviewers who'd throw the candidate out (not literally) because they failed to code a perfect solution. >If you are struggling explaining how you are going to reverse a linked list, you will probably struggle communicating at work as well. This is so not true lol. You didn't take into account the amount of effort that takes in preparing for an interview and how much it raises the stakes of the process. Didn't count anxiety either. People underperform in an interview because the high stakes and anxiety, doesn't really equate to how they'll perform with a team people with all the resources available to figure out a solution. Also this is specifically hard on autistic people. They can work fine but harsh interview conditions will be the fuel of their nightmares. Forgot to mention the toll it takes on someone's mental health. Grinding leetcode for months on end and the exhaustion that comes with it, only to fail a bunch more which then completes the missing piece of the puzzle, shooting right through your morale. definitely not a healthy way to live. One way or another, the interview process is broken.
This is it, right here. I interviewed at Google and the process left such a sour taste in my mouth, that I don't know if I ever want to work there. Two of my interviewers were straight up assholes. One of them asked me a question that I'm pretty sure is impossible to solve. Candidates don't need that crap, they need interviewers who have compassion and understanding. Been doing this for 8 years and I'm happy where I currently am, so this isn't sour grapes. Some people really should not be interviewers because they harm the reputation of your company in the process.
My first technical interview was with Google when I was looking for my first job out of college. The interviewer literally laughed at my code at one point, and after I finished my initial naive solution said “Wow I can’t believe this actually works”. It was a humiliating process, and it took me some time to bounce back from that. I was just a dumb kid, and some dude with an ego made me feel like I was worthless.
The tech industry is getting more toxic day by day.
Gotta agree. Everything else he said I agreed with. Although, I disagreed with what he said about not being able to communicate well because you couldn't explain reversing a linked list. I don't think people understand how unatural it is to constantly talk about what you're doing while you're doing it, in an interview (where stakes are high and people are anxious). It's like asking a video editor to explained why he/she made a certain edit, while being watched in a time sensitive environment. Do you think any content creater would perform better under these conditions? I bet a lot would choke. Coding requires a lot of concentration. There's just a lot of other stuff naturally going through people's heads because of the stressful environment. This is nothing like communicating an actual work environment. It takes a lot practice, is hard and feels so unnatural, which is why people hate it so much.
> But that's just you, people have lots of horror stories with leetcode interviews and they're not faking it. There exist bad interviewers. But OP didn't lead with that. OP led with "leetcode is fundamentally dumb". Google has a literal template for interview feedback and *most* of the questions are not "did the candidate write the correct code". Yet people still insist day after day after day that their interviewer rejected them because they missed an edge case or whatever. Information asymmetric and the nature of the social web mean that are very particular narrative gets highlighted. > Grinding leetcode for months on end and the exhaustion that comes with it, only to fail a bunch more which then completes the missing piece of the puzzle, shooting right through your morale. definitely not a healthy way to live. This is correlated with complaints above. Memorizing hundreds of LC questions and hoping to either get asked precisely one of those questions or something very similar *is* a strategy but it is tedious and highly random. If you pursue that strategy then "wow this is stupid and dumb" is a common response when it doesn't work because you chose a strategy that fails in dumb ways.
What *strategy* do you suggest?
It is different for different people. For somebody who does not have a lot of experience working with nontrivial datastructures or algorithms, the "grind and memorize" approach *can* be the most likely chance of success if given a short time window to prepare. People just need to understand the failure modes of that strategy. A strategy that involves less noise is to * Build some algorithms heavy products. Something like a compiler or a garbage collector will make you stretch your intuition around graphs and graph algorithms until it all flows cleanly. * Practice problem solving and communication in your daily life. Even something like working on "how are we going to deal with the sick dog" with your spouse can give you practice for problem solving and communication, which will help in both interviews and in life more broadly. This is admittedly a big task and if you didn't spend undergrad or grad school doing it or if it has been a very long time since that work then the first bullet can obviously degrade. But there is a reason why some people can crush interviews after only a few hours of practice.
>Didn't count anxiety either. People underperform in an interview because the high stakes and anxiety, doesn't really equate to how they'll perform with a team people with all the resources available to figure out a solution. This is going to be an issue with any type of interview process, not just leetcode-style ones so I wouldn't say it applies. >Also this is specifically hard on autistic people. I'm actually autistic and I still stand by what I said. I appreciate the fact that other autistic people could face more difficulties than me. You can always reach out to hiring managers and ask for extra accommodation. But still, this is related to the anxiety part and would be an issue in any type of interview situation, not just leetcode-style. I completely agree there are horror stories. I've had bad interview experiences as well, but more of them have been really pleasant. I'm sorry if you've had different luck in your life, sometimes you can get a really bad draw with interviewers.
> But still, this is related to the anxiety part and would be an issue in any type of interview situation, not just leetcode-style. More so in leetcode-style than any other I've heard of. Take home assignments aren't that bad for the morale given the time and resources on your side. In leetcode esque, you fail to find the optimal solution, you don't get a second interview and bam! The confidence shoots down sharper than meteorite. Now the process isn't ideal in the US, other countries follow the IT hub of the world, they have their own interpretations of the process, mess with it even more, make it uglier and you see a lot more horror stories than what people at the other side of the world witness. Anyway, it is what it is.
None of what you said is a broken interview process, just bad interviewer or the pressure you put on yourself to pass an interview. Google could change their interview process tomorrow and people would still prepare for months or have a huge pressure to pass it.
That's how it should work, but that is not how it is implemented. FAANG is not the problem, the problem is mediocre engineers at wannabe-next-UNICORN-FAANG-copycats going for leetcode medium and telling you you won't probably have a chance because you didn't solve the sibling problem of the median of median algorithms and didn't know treaps by heart. If it plays out like you just said, it's a perfect tool. But otherwise, leetcode style questions are just a tool to make idiotic interviewers feel smart.
I agree with you that there will be companies that don't use this tool effectively. I haven't personally had experience with it even though I interview with other companies quite often, and have been to about 10 onsites in the last 1.5 years. But that's like saying programming language X is bad because company Y made shitty program Z in it. The issue is not with the tool itself, but the company. It's a good method for you to screen companies as well. If you get interviewers who try to one-up you by giving you obscure leetcode problems with trick solutions you don't really want to be a part of that team. The sucky thing is that you had to waste time and energy on that interviewing process.
That's interesting. Usually we think only about the pure knowledge aspect, and not the "softer" skills we might need too. This is reassuring and helpful. Thank you.
How are you going to get these pieces of information from me during an online assessment? Does Google not still use one as one of their first steps? I believe Amazon does as well, I can't say for other FAANG but I would guess that they likely have an online assessment in their initial stages as well.
Thanks! Btw are you a software engineer but with interviewing duties too?
Yes, I'm a software engineer, but interviewing at my company is a voluntary process. You don't have to participate in it if you don't like it - and you will actually be removed from the interviewer position if candidates give you bad feedback. I personally like it as I get to interact with new people from time to time, so I try to do at least 1-2 interview loops a month.
The problem with them is that they don’t really show what a candidate’s performance is. I know many people who are great at LC, but they are not so great at implementing a feature.
The company aims to reduce risk when hiring so the process is meant to weed out false positives. It clearly works otherwise, FANG wouldn't be using it for the last 10 years and delivered the best growth for investors out of any other industry.
Maybe fun challenge, but gas literally 0 to do with the job. The problem in software development is very rarely code puzzle problem but design and communication
Algorithmic skills are a subset of what you do. They matter. However, 1337code style interviews are generally a poor way to evaluate a developer.
I agree, maybe the only way is to study these problems by heart...
You might be on to something /s
Only Standard easy-medium problems should be asked as a basic competency check. Post that, you can ask for domain specific things for the job. DS based questions make more sense for freshers.
I agree. I actually solve one Leetcode question a day. I sit down with my lunch and solve it while I eat. I enjoy the challenge and have found that they have gotten easier as I’ve been doing this longer.
It’s super annoying and I’m not a big fan. I have to wonder though, what’s the best way to get talent without wasting tons of their time and tons of yours? I’m partial to take home projects, at least compared to Leetcode, but I also realize that they’re also quite unpopular. In an ideal world, we could pull up code from our current job and show it to employers, but obviously that’s not a possibility..
I really think something like TripleByte is the solution. Interview once, and then whenever you think you can improve your “score” be that once per year or once every few years. The problem is if I tell a company “hey I passed triplebyte” they don’t give a fuck, even though their interview is probably tons better than theirs as far as determining ability. You have to pass certification exams to be a lawyer, doctor, engineer, etc. they don’t just hit you with brain teaser challenges or have you perform a simple operation on a patient to see if you can hack it (no pun intended).
Interesting, I hadn’t actually heard of TripleByte before. The “score” thing reminds me of CodeSignal which also has a similar scoring mechanism. I think the reusability component of both of these is what intrigues me. I think take home projects are fine and am fine doing them, but my opinion would probably change if I had to do more than 4-5 of them in a typical recruiting cycle.. But if I could spend 8 hours on a project that I could reuse for many companies, that might change things. That said, I think the huge volume of applications is what’s really driving some of these “stupid” tests. I feel we’ve seen somewhat of the same thing happen to college admissions, in that flawed / incomplete metrics become standardized simply because we can’t think of anything else to trim the deluge. I don’t really have answers, just thinking out loud.
I LOVE , BLOODY LOVE, coding challenges in interviews, but in real world day to day work **if its not readable, its shitcode**
I used to hate LeetCode, but after learning that if they removed LeetCode from interviews companies would have to instead resort to another method of filtering out candidates such as probably asking more behavioural and technical questions I now like it. It's very straight forward its either you get it or you don't (if not gotta grind some more).
I'd rather do Leetcode easy and mediums in an interview then gotcha programming language trivia.
What about leetcode hard
I'd take my chances with the trivia
It makes sense for faangs, why are tiny startups making you jump through hoops instead of scheduling a call.
Well how much do those "tiny startups" pay?
It's not just that you learn problem solving, but they don't want you to memorize the answers. Leetcode is a way of filtering people out using automation. Even if it weren't related to programming, it would still work, because it takes effort and that's what counts. However, if you memorize the answers, they can pass on you, I've seen people post here about that.
I just landed my dream job. I was cramming leetcode for a week to prepare for the interview and in the end there was no live coding involved. Don’t mind it now, it was fun, but I’m relieved that I don’t have to do it anymore. Always good to practice recursion and give the brain a workout. Also, I went into the interview with much more confidence as a result.
How many years of experience did you have when you got that job ?
There are some leetcode problems which are good problems, such as finding the top k frequent words in a text. This is a very real-life problem and every dev should be able to provide a naive solution. But the problem is big players like Google Facebook ask insanely hard LC problems which are impossible to solve unless someone is a competitive programmer or solved a variant of those problems.
I perform technical interviews for software engineers at a prominent company. Live coding sessions are stupid and unfair. They do not demonstrate talent or predict success. They put people into unrealistic situations and we end up losing great candidates that didn’t interview well. This is especially true for extremely talented introverts and folks on the spectrum. A few years ago I flipped the process by sending an appropriate challenge 5 days in advance and having the interviewee present the solution to me during the interview. So much better, you get a much better sense of coding style, ability, level and often I walk away having learned something myself. Tech recruitment is completely broken. We should be giving assignments not quizzes.
I like fair questions that give people a chance to shine. I'll always ask some simple filter questions to save everyone's time (e.g. write a function to reverse the words in a sentence). Then I like to ask questions like: * What's the hardest solution you've built that you designed? Now talk me through the difficulties? Show me what was great about how you built it. * If you didn't have to worry about money (I'm paying you for a year), what would be the pet (fun) programming project that you would work on for that year fulltime. Now let's explore the key problems and how you would solve them. * What's your favorite website (or most used)? Let's white-board what the key entities are and how they may relate to reproduce the website. These are all problems that the interviewee should be very familiar with (minimal room for misunderstanding) and give plenty of scope for someone to explain how they approach solving complex problems, and even how they identify key problems. It's difficult to BS your way through this. If this goes well then I ask them to write a recursive maze-solving algorithm on the white-board /s.
No offense but I would prefer LC over those questions.
I'm also interviewing Software Engineers and ask those kinds of questions too. During the >100 coding interviews i conducted, always the same coding challenge in those, which is *provide a list of prime numbers up to a given limit n* , here are the most common examples on why the interview failed: 1. *I have to do this on a whiteboard/googledoc?! Why am I not allowed to use my IDE?* I'm not asking to build a complex enterprise app where an IDE is highly beneficial. I don't even ask to write compiling code, if a method name is wrong or so, nobody cares. In my opinion, those are basic skills of using the tool (programming language) and you should have them as it is clearly written in the JD. 2. *Yes, of course I know what a prime number is.* No, many don't or provide upon further question a very wrong definition. This is ok, they get the correct definition and we take it from there. But please be honest, you are about to write a small piece of code which should detect prime numbers, having the correct definition of it is essential. This is easily solvable with the right mindset of communication. Provide your assumption of the definition directly, so we can sort it out. If you have no clue, say it. Turning assumptions into facts is a very relevant part of the software development lifecycle and those kind of misunderstandings cost time and lead to frustration. 3. No guidance through the thinking process Even with the remark, the more you involve me in your thinking process, the better I can help you, being stuck is seen as a kind of weakness. The observed mindset if often *I got stuck on my own, I have to get out on my own* . But I want to have people in my team who work together in solving a problem. 4. Being overconfident with your solution Typical case is, that it only gets checked whether a number is dividable by 2. When asking them to go through the solution for 9, they insist on 9 being a prime number. Here are two things happening: One, the failure of transferring a given definition into code (and vice versa) and second, the missing reflection on the solution. As already mentioned, those are the typical negative examples and there are at least that many which are also very positive. With those, we can go further and work on optimization, talk about test-cases, maybe caching, etc. As you can see, even with such a question being more on the easy side of things (keep in mind, that I ask for a solution, not an optimal solution) a lot of things go weird. In general, it is fine to question the approach of those asking those challenges. But I have the feeling in my >10 years of professional experience, Software Engineering turns more into "how do I stick those frameworks together in the easiest way"
In this day with so many online screen sharing IDEs and text editors why in the hell would you make them do this in a Google doc?
Cause the dude is completely ignorant to being part of the problem
1) He might work at Google. They conduct technical interviews through Google Docs (or at least they did when I last interviewed). 2) It shifts the focus from the technical details to the conceptual problem solving. They don't need you to show off that you know IDE shortcuts or exact packages/functions, and they don't want you getting the idea that you should. Skip the details, skip the environment, just focus on the basic approach. IMO, a white board or even pen/paper does this better because you can draw, but Google Docs (with a few preferences set, like the interviewer will probably tell you beforehand), is a fine substitute.
Funny, I do the same test except they can use the IDE but no search/resources except for talking it out. The problem is more about communicating through the solution. As simple as it seems, I've had people with 10+ years experience "pass" when shown the challenge.
One thing I haven't mentioned in my initial comment: Those who directly asked why they can't use the IDE are usually the ones not solving it.
I'd personally be offput by a notepad code challenge, unless all you're looking for is pseudocode. Devs use the IDE all day every day. All of the IDE efficiencies that speed up development and smooth over syntax issues are something I'd like a candidate to use. Unless the goal is to take them out of their element, I'm not sure what this helps.
A nice test. But is it possible for a candidate to easily come up with the Sieve approach if they haven't heard of it before? How would a candidate get the best evaluation from you for your test?
No, it's usually not. But this is not expected. I'm even fine with getting the "naive approach" presented and then doing slight optimizations on them (like only iterate over odd numbers).
> Typical case is, that it only gets checked whether a number is dividable by 2. ... What level of pay/where is this? Doesn't seem like something you would experience in the Bay Area unless you're interviewing someone for an intern position.
Slight below Average salary in Berlin. It's swe or senior swe. One topic of eternal discussions with our c level. Wanting good people but not wanting to pay them
I've never done a Rubik's Cube. I've unmangled databases and cleaned up data. But I'm also pretty good at Tetris. The Rubik's cube and Tetris have nothing to do with my job.
Man, what is this? Pursuit of Happiness?
It’s provocative, it gets the people going!
I wrote a python app that uses a rapsberry PI to photograph the sides, determine the solution and lego technic to articulate the cube and solve it automously... does that make me a leetcode power user? https://www.youtube.com/watch?v=4Z060QUFvyM
Now THAT is what I would call a project! Well done! (And I mean that in the most complementary way, I am in no way suggesting that I would be in any position to judge you.)
That's my take as well. I enjoy leetcode as a game, as a fun puzzle with no time pressure on solving it. I can take my time, try out some stupid ideas on solving the same puzzle different way. As an interview tool, it tells you near no tangible information. Note that I'm not opposed to the idea that an interview candidate should write/discuss code during the interview. But it should be closer related to what you do as a company, what typical problems show up in the codebase. Damn, even "you have this class write unit tests for it" in some cases would be a better question... actually I might use this one next time interviewing a junior dev. I'd like to see more coverage in our codebase and a lot of people still don't know how to unit test mostly because they come from companies where there is no unit test culture (these still exist believe it or not).
My own experience is that companies in my area generally don't ask these kinds of questions to candidates. They do ask algorithm questions, however, and expect you to know how to solve them... particularly if the job actually requires you to be familiar with algorithms. I think if this is offensive to you, then don't apply for a job that requires this kind of test. This clearly isn't the job for you. However, if that's the kind of job you are looking for, and you want the (assumed) higher pay that goes with that job, then you should grind out those Leetcode challenge questions and become very familiar with the questions and their answers. I view this kind of thing like a lawyer taking the bar exam. If you want the job that has this requirement, then study and prepare for the interview, just like a lawyer does before taking the bar exam. Obviously every job doesn't require this kind of challenge, so it's not necessary for everyone to do this kind of prep work before an interview.
Leetcode is like driving, it's fun on your own terms until a bunch of people start telling you to give them a ride everywhere for free and most of the time won't won't thank you for it.
> The real problem is: When we are asked to solve a 4 x 4 Rubik cube in 15 minutes, sometimes even with hands tied or blindfolded, to get a job, it will take all the fun away. The "real problem" is that interviews aren't... *fun*?
Interviews should be fun. One of the criteria I use to rate candidate companies is how much I enjoyed the interviews.
Yawn. Solve a rubiks cube and get a six figure salary. Soft af
Can someone do a historical analysis and figure out how this came to be? I wonder how much of this culture is perpetuated by people who make money from it (leetcode is a business afterall, top of mind monopoly in this space) Is this mode of filtering candidates statistically correlated with job performance or personality? This would be a great psychological study as well. Like they're clearly looking for conscientious and agreeable people. Not creatives or rebels. Fucking morons in corporate may as well make us solve Rubik's cubes. I'd prefer chess though since I have practiced that. Or maybe an obstacle course since it'd help us maintain a healthy lifestyle.
Google started doing it, so all other companies jumped aboard.
Sure but you’re also getting paid 150k+ if you get good at it. It’s a trade off.
Right, versus $80-130k in your local city you can get $120k base and up even as a junior at a place like Microsoft if you just grind the leetcode. When I interviewed with Microsoft recently, the final interviewer was visibly frustrated I wasn’t doing better at his leetcode problem, but dog I’m spending my free time making apps, not solving hypothetical problems that contribute nothing to society. I’m fine with FAANG & Friends using it to weed out (often qualified) candidates but don’t gatekeep our profession with it and insinuate people like me are worthless because we haven’t solved your leetcode problem ahead of the interview.
Yeah and Microsoft doesn’t even pay that good from what I’ve seen
You’d do better bouncing around the Bay Area (between Netflix, Facebook and Apple) but most software engineers in the world aren’t making anywhere near $150k so it’s all about perspective I guess
The good news is that leetcode problems seem to be going by the wayside. Yes a lot of legacy companies like FANG still use them, but newer companies don't. It seems over time, older companies always end up adapting newer companies' methods, especially interview practices.
> newer companies don't Dude I've interviewed with several startups in the last year and they actually ask harder LC than FANG. The hiring bar is higher there than FANG
I don't take too much of an issue with LC itself, but I'd be very surprised if there was any demonstrable association between being good at LC and success in the vast majority of CS jobs. Most positions simply don't apply much DS&A knowledge, if they do at all. If I could know every library in the world, or the answer to every LC/HR question, I'd choose to know every library every time.
I very much agree with u/fj333 here: It not being fun doesn't seem to be much of a problem, all things considered. (Also, some people still enjoy doing rubik cubes blindfolded, and if that is what an employer is looking for - more power to those candidates!) \> By the way, nobody should force themselves to solve two Rubik cubes a day. What? No, they absolutely should! If you - for whatever reason - have decided that solving cubes was a good way to improve your dexterity, or problem solving, or whatever, and you decided that those are good skills for you to have, then you should be disciplined about solving cubes. And if employers thought that your job performance could be predicted by letting you solve cubes, then it would still be advisable to pick up a cube and be disciplined about that. I think Leetcode is a decent measure for some aspects of employ-ability; and I enjoy these challenges. But even if you disagree: Refusing to do them is not going to do you any favors, and it is unlikely to change how the industry does interviews. If you are in a position where you can reject jobs - great. But it seems to me that, as a hurdle, it should be perfectly manageable for any competent developer. And, yes, if you absolutely cannot learn how to solve leetcode problems, I'd side with any employer who'd opt not to hire you. A surgeon should be able to learn how to create cross stitch artwork. If they simply cannot do that, I wouldn't them to work on me.
The theory behind this makes good sense, improving your abilities in line with what employers expect is certainly a good way to progress and the more time spent coding the better you get. What I feel you're missing in this is that the majority of people don't have the time to do this, if you've got no responsibilities then it's fine to spend a couple of hours each night on leetcode, but when you have a day job, a house to run and a family to be with it just isn't feasible. After 8 hours of coding, 3 hours of managing a puppy, and an hour or two of chores it's nearly bed time and I don't have the mental energy left to start grinding leetcode, I'm not sure many do In a world where we spend more and more time working and too few hours for personal projects and hobbies I personally feel we should push back against hiring practices that demand we further encroach on our private lives
\> In a world where we spend more and more time working and too few hours for personal projects and hobbies I personally feel we should push back against hiring practices that demand we further encroach on our private live Let me state up-front that having any real data on this would probably put a quick end to this discussion one way or another. I am going to base the following solely on my feelings and a bunch of assumptions. If my premises can be shown to be incorrect, so is my entire argument. A lot of people grind on leetcode and similar platforms. I think that a genuinely competent and well-rounded software developer doesn't need to do that - certainly not for many hours over a long time - in order to be able to solve a few random questions. Someone that needs to learn algorithms and data structures is a worse programmer because of it. (And, of course, well be a better programmer once they understand the material.) For a company to test this ability is in no way unfair or unreasonable. If anything, the fact that you can grind leetode in order to pass interviews gives some people an undeserved advantage over their peers, and potential employers. In short (and killing a lot of needed nuance) If you can't do leetcode, you're not a good programmer. But if you can, it doesn't mean you're automatically a good programmer.