It always blows my mind how most interview in our field. When I first started in tech I was afraid to talk about not knowing leetcode to my peers. 15 years in and I now can confidently say I’ve yet to meet someone who thinks these are a valid metric.
Why do we make this the gate keeper to our industry when we know (except for the very specific roles) we will rarely need leet code type problems. When we do we just google them.
Somebody here on HN recently shared the notion that leetcode tests are a legal way to discriminate by age or lifestyle, as older and well-rounded developers do not have the time or inclination to grind on such things.
As a successful developer well past middle age, I find this to be nonsense. The most common complaint I hear around this is "yeah, that discriminates against people who don't have time to grind to do the preparation."
Why is it weird that people should spend time preparing for ask for a new job? I mean, ask an orchestra musician how much time they put into preparing for auditions, or how much time many degreed professionals put into passing a certification (e.g. the bar exam or medical boards).
If you don't want to spend time preparing for job interviews, then fine, don't. But don't claim "discrimination" when there are those of us willing to sacrifice to put in the hours to prepare.
> Why is it weird that people should spend time preparing for ask for a new job?
Because that preparation, by and large, is not related to the actual job.
> I mean, ask an orchestra musician how much time they put into preparing for auditions, or how much time many degreed professionals put into passing a certification (e.g. the bar exam or medical boards).
Those are all instances of people being asked to do/know things that they will need to do/know for their actual jobs.
An actual comparison would be if the orchestra musician was asked to perform blindfolded on a random piece of music, and have to spend 6 months training to memorize the most often requested pieces to be ready for the interview, only to play for the rest of their career with the sheet in front of them.
(Not trying to compare difficulty, but absurdity. I don't doubt orchestra musician's auditions are harder)
Also, bar exam and certifications are not job interview. You also have exams and certifications in CS and no one is complaining about having to train for those.
A lawyer/doctor certainly doesn't have to pass the equivalent of the bar/medical exam every time they want to change firm/clinics. They just talk about their past experiences. Barely any prep required beside being able to give a good sales pitch about you.
Meanwhile, as a dev, you are expected to do it all over again every time you will change job. Even for internal moves, many of the GAFAMs expect you to go through this again.
I'd push back a bit on the orchestra musician preparation relevance. Playing at an audition alone is very different from playing in a section. The hyper critical attention to minute details that wins you a job at, say, the New York Philharmonic, isn't what makes you good at blending with your section. Also, no one is ever practicing concert repertoire as much as they practice audition excerpts so what you hear at the audition is not necessarily representative of what you hear every week.
Granted, it's more representative than leetcode performance but still far from a perfect system.
> I'd push back a bit on the orchestra musician preparation relevance. Playing at an audition alone is very different from playing in a section. The hyper critical attention to minute details that wins you a job at, say, the New York Philharmonic, isn't what makes you good at blending with your section.
A bit off topic, as this isn't orchestral music, but in college I was in a couple of bands as a bassist, and in one of them the guitarist was probably one of the best musicians I ever played with technically. However, because he was so good, sometimes he would get taken by surprise when someone less talented in the band messed something up during a performance. When practicing before one of our gigs, I noticed that our rhythm guitarist was playing a certain section incorrectly and essentially finishing it in half the time he was supposed to; the drummer and I would generally catch on immediately and course-correct, but the lead guitarist tended to be flummoxed and took the longest to group up with everyone. I made sure to mention it to everyone since I figured it might come up again, but I think everyone else forgot by the time the gig happened, and the same exact thing happened, and even though it was the rhythm guitarist who made the initial mistake, the lead guitarist ended up being the one who "looked" the most wrong to the audience because the drummer and I knew that the only way we'd get back on track was grouping up with the rhythm guitarist and leaving the lead guitarist behind. If anyone were trying out our two guitarist to join an existing group, I think almost everyone would take our lead guitarist due to how much better he'd perform in an audition. However, if the band he tried out for wasn't able to keep up with him, it's very possible he would have been the wrong choice. This seems pretty similar to "leetcode" style interviews for a software engineering role; the person who is able to impress the interviewers the best technically might end up being a bad fit for some teams if they aren't able to collaborate as effectively with their team.
> Because that preparation, by and large, is not related to the actual job.
TBH, depends on the job.
I think the problem is hiring people with these skills to do jobs that don't require them. That's bad for both parties. The employer is going to be paying for a skill it is not required, and the employee will get bored and switch jobs, costing everyone time and money.
Was going to disagree but ended up coming around to the argument. I guess the difference is at a certain point preparation turns into a wasteful arms race, it’s not just a reasonable amount of effort put into your next gig but too much effort on things that don’t really represent real day to day / reality. Not sure where the line is, but there is definitely waste and it definitely favors those with spare time.
Does seem like there is a growing movement to explicitly not do leetcode style reviews at many places which is good.
> Why is it weird that people should spend time preparing for ask for a new job? I mean, ask an orchestra musician how much time they put into preparing for auditions, or how much time many degreed professionals put into passing a certification (e.g. the bar exam or medical boards).
It's weird because the preparation is often the thing we're not doing in our day to day.
I'd also go as far as saying if you need to cram crazy hours shortly beforehand to pass any exam or test then you're not really qualified to pass. If you were qualified you wouldn't have to do this because you'd already comfortably know the answers. I get wanting to casually review the finer details which is fine, but if you're in "oh crap, it's Tuesday and the test is in 3 days, time to drop my life and cram 10 hours a day to prepare" mode, maybe you're not ready?
I also think you can't compare software development to musicians or sports. I do play the guitar and there's a massive amount of muscle memory involved. I've gone a few years without playing in the past but within a few minutes of picking it up somehow my brain can resume where it left off and my hands just move to the right places almost on their own.
The same can be said for sports, there's a lot of practice and warming up to burn in muscle memory and literally get your physical body in an optimal state. Also the stuff you're practicing is directly applied to what you're "really" doing in your professional day to day.
> I'd also go as far as saying if you need to cram crazy hours shortly beforehand to pass any exam or test then you're not really qualified to pass.
Tests are different because you are on a timer and they are balanced around it. I almost got straight A's in university, apart from a single B in a course I was confident I actually understood. I got A's in shit I couldn't even begin to explain. But signals and systems, which I genuinely understood at the time, I got a B because I didn't bother studying and memorising shit. I had to work stuff from first principles and ran out of time.
I feel like it's the same in programming interviews. There's no time to actually work out anything from first principles or any original thoughts. Either you know the answer immediately and you spew some shit to make the interviewer happy, or you fail.
Like you say, it's very different for physical activities (can't comment on music), because you cannot drastically increase performance by cramming for a few hours. I was an amateur powerlifter, I stopped training when covid started. There's no way I can get my strength back in 3 days. But I bet I can get an A in some random
exam after cramming for 3 days in some random university course I did however many years ago.
A musician put it in time for an audition because that will be the piece he will be performing. But doing leetcode when the job definition is: You will be working on this e-commerce site is not the most motivating things. While algorithms and data structure knowledge are important, most of the time is spent writing code gluing data sources to interfaces. I'm perfectly fine doing an interview on the technologies I'm expected to master, but knowing by heart how to sort strings doesn't help anyone, IMO.
Minor bikeshedding, but orchestra auditions are more about measuring musicianship at various time constraints: sight reading - O(minutes) of prep, audition excerpts - O(days) of prep, and personal repertoire - O(months to years of prep).
By and large, professional musicians are paid for a standard level of performance competence and a strong level of versatility. The small handful of remainders are the famous ones renown for exceptional levels of performance.
Plenty of professionals are paid to play the musical equivalent of e-commerce site.
It feels more like auditions for tech involved being assigned a random instrument, even though you've been playing flute for ten years and they are hiring because they need a flautist.
Pushing the metaphor further is surely silly, but I'd compare s/w dev to jazz improv or the ability to deftly adopt the musical expressive style of a new ensemble, and s/w design to musical composition or arranging. Switching instruments is more like switching programming languages or stacks. Presumably appropriate auditions should assess these complex skills and not rudimentary fare like scales or key transposition, AKA leetcode.
> most of the time is spent writing code gluing data sources to interfaces
Pretty much anyone can do that. We’re looking for someone who can do the other 20% of the job that’s novel and difficult. Ideally someone who recognizes that rereading glue code is a waste of human effort, and automates it away instead.
> ask an orchestra musician how much time they put into preparing for auditions
Training is basically the main work performer has to do to earn his life, and all training is valuable. You could compare with professional athlete and see how it’s absurd.
> If you don't want to spend time preparing for job interviews, then fine, don't.
The idea is that you have to understand the process. If you don’t see the point of certain exercise, you search for a rationalization, and discrimination looks like a good one.
Also, the discrimination is not against people that won’t train for interview, but to give a bias to people that don’t evaluate returns on their invested time
Actually, the pro athlete metaphor seems pretty apt. Only rookies are assessed primarily for leetcode metrics like their 40 yard sprint or bench strength. Pros are judged entirely by their game play, both individual and ensemble. So it should be for pro SWEs. And the better employers understand this, finding ways to assess candidate facility by working with staff or the design of solutions to representative problems, where incapability does the most damage.
I think some of the weirdness is that orchestra musicians at the very least demonstrate skill reflective of the job, and doctors and lawyers only have to get the license once. Software is in this weird category of interviewing being it’s own technical domain that needs dedicated study, of which no amount of experience or prior success graduates you from.
Additionally, I find the logic behind this strange. It implies that just because some people can afford to sacrifice that this setup isn’t discriminatory. But the criticism is that some demographics are disproportionately unable to sacrifice. Discriminatory doesn’t mean no on in that demographic is able to afford to dedicate whatever resources towards the thing. In fact systems of discrimination often work better when there’s a model minority or “one of the good ones” that can be pointed to as an example as to why a discriminatory system isn’t really a problem.
> doctors and lawyers only have to get the license once
Doctors have to recredential over their whole career. Used to be every ten years, but some specialties are moving to annual “quiz-sized” credentialing over once-a-decade cramfests.
Yeah, older people are more likely to have other priorities, but they’re also more likely to be financially secure and thus able to trade money for time to study. Also, they’re more likely to have gained time management/prioritization skills and discipline that they could apply toward studying.
Ultimately it seems like arguing that older people lack time or inclination depends on ageist stereotypes.
I think the argument is that more experienced people are less willing to do useless things just because somebody wants them to.
I could never go back to university for that reason - studying, fine, I did a ton of courses on edX and Coursera, but I pick what interests me and a lot of test problems you are given (at least in my experience, at university and later online) too often are more about understanding the intent of the person creating the problem rather than anything useful. I could also never go back to the army (Germany, mandatory service, battle tank mechanic) and take commands from some guy who just wants to posture.
I'm not any less willing to study than I was at university - but now I refuse to do what I think is useless or meaningless. Studying for tests is high on that anti-list. Not all tests, I had no issues with tests I took for things that needed certification, e.g. sailing or for the pilot license, but that stuff was useful in practice and not nearly as over the top because those tests were not designed to "weed out weaklings".
> He authored a textbook on electromagnetism called Static and Dynamic Electricity, which was a widely used reference in the field during the 20th century. His electromagnetism course was modeled after the Cambridge Mathematical Tripos examinations and designed to "weed out weaklings." Smythe's course was so infamous that future Nobel Prize in Economics laureate Vernon Smith switched to electrical engineering from physics to avoid it.
Anecdotally, I am one of the older people in our dev team, and also once of the only people who cares even slightly about big O. I’m talking simple stuff, like knowing whether indexing a given list data type is constant time or O(n). To be fair, it’s not particularly relevant to what we do.
I think asking a candidate some basic big-O notation questions in an interview is great. Asking a DevOps candidate if a search algorithm developed and published in 2018 is O(n log(n)) or O(n log(n) K^(log n)), and then dinging them for not getting a perfectly correct answer, is over the top the kind of stuff that's used for age discrimination. Not because the young candidate will know it, but rather they will be excused for "almost getting it" and "having a good attitude" etc. in the hiring committee.
The large companies don't need tens of thousands of system architects. They need tens of thousands of coders who can do what they're told on small parts of a system without fussing too much about the bigger picture. I think that's what OP is referring to—leetcode filters for young developers who don't need to understand all the reasons why they're doing what they're doing.
Every job has random overhead and your productivity is boosted quite a lot by already being familiar with some random bullshit problem like "don't configure your test environment this way or you'll run out of file handles after a day or two." Hiring more experienced people means fewer delays due to issues like that, even for boring "code-monkey" work.
This doesn't make sense to me. I work in a FAANG and we are desperate to hire senior engineers and it wouldn't make any sense for us to turn our nose up at older candidates.
They are convenient and standardized ways of testing. These "legal ways to discriminate" that companies come up with are nonsense, that's not what is happening.
The issue is the sheer number of fradulent and stuffed credentials people have begun using, and applying, en masse to job positions.
To be clear, I dislike the current way interviewing is, but do you have a better solution to screen out 7,000 applicants? The vast majority will be knocked out by the leetcode style interview, and sure, some brilliant minds might fail because they can't remember linked lists in the moment, but atleast you screened down from 7,000 -> 70. If there is a better way, we'd all love to know.
I am prepared for this to be voted down, but I am genuinely wondering the answer to this.
I think the distinction to be made is between the process of finding the best out of 7,000 and finding someone sufficient out 7,000. The first is surely extremely expensive for companies. The second can be done in a week or two. I think the anecdotal evidence shows though that no company can accurately do the first, and the gamification of this process is a deeply researched topic, so it's likely that a company that believes they're accomplishing the first is really doing the second in practice, all the while spending unnecessary money and time, and deluding themself into thinking they found the needle in the haystack.
My belief is that if you aren't doing Ph.D. level research, all you need to do is get the candidate to prove they can write themselves out of a bag with React/Python. Anything else is overkill, and a real cost loss to the business in terms of money and time.
I will admit that for most businesses there will be times to do the first, and time to do the second. But I imagine this distribution is something like 20/80, whereas most companies are doing 80/20.
Coding is hard, but so is marketing, accounting, management ... But are your marketing candidates being put through the ringer too? I suspect software engineers are being uniquely hazed.
That's a false choice. The number of applicants is mostly a function of time, so if 7000 applicants is too overwhelming then just throw out 6900 and focus on evaluating 100 of them. To weed through thousands of candidates is to believe that you can find the one that's exceptional, yet if the position being advertised doesn't need to be filled by a genius then it's strange to scour the earth for the right person. If you are at the point where a genius is needed then hiring through personal connections is probably the better approach.
But if I must write code as an applicant, it better be similar to real world tasks and not some bullshit, especially if my chances of getting hired are still slim. Having to do work in order to get hired is literally sucking the lifeforce out of me, so don't suck even more out of my via the agony of glorified brain teasers.
I worked in ATS company and 7k seems like an exaggeration. Most companies would only get tens of candidates, some of them hundreds and only a tiny minority would get thousands. I would also confidently say that the vast majority have sourcing issues, and that’s why they ask recruiters, agencies, etc to fill more applicants to their open positions.
And yet, all these companies would have complicated hiring pipelines to hire. I have seen examples which made me laugh; like receiving tens of cvs and asking almost all of them for take home exams (felt sorry for the reviewers and the candidates who lost their time), multi stage technical reviews for companies with less than 10-20 employees, final executive level interviews with more than 5 candidates in parallel, time to hire times of 3-6 months, etc.
> Coding is hard, but so is marketing, accounting, management ... But are your marketing candidates being put through the ringer too? I suspect software engineers are being uniquely hazed.
My girlfriend works on the business strategy side of Fortune500’s. Our interviews look like a joke compared to theirs.
My developer friend stopped working as an engineer because he found out he can pass those interviews with no preparation and the job takes way less effort compared to software.
He's now doing two jobs at the same time and the companies don't notice he's barely doing anything but appearing in meetings.
YMMV
Big corporations are incredibly wasteful, so I'm not surprised.
I also know plenty of developers who do little at work, but at least they need to produce a substantial amount of code, at the end of the day.
> he can pass those interviews with no preparation
I've never had to prepare for an engineering interview in some 15 years of doing this professionally.
> the job takes way less effort compared to software
The easiest part of my job these days is writing code.
The challenging fun part is setting a technical strategy that aligns with the business and gardening the team around me with soft influence towards that strategy. Super challenging. Would've been easier to just do it myself, but there's only so much I can do on my own.
Ultimately, you should go do whatever comes to you easiest and/or is most fun. No sense grinding away at something you're not good at. Maybe your friend has an immense talent for business and strategy.
Also interested in top strategy interviews. Not that they aren't hard, just that "strategy" has always seemed so ephemeral to me. My business profs failed to impart any real criteria to define it. Seems like something people either have or they don't and all you can do is hire based on past success.
You are put through an initial ringer to vet for basic fit and competence. Then you get a take-home exercise that consists of several business case studies. You have to detail a strategy for what you would do in that situation, support your argument with research, etc. My girlfriend said it’s a lot like writing a term paper in college.
Last time she interviewed it took her I think 2 or 3 days of full-time work to do the case studies.
Then you go back and defend/present/discuss your work at an interview.
Her job consists of doing basically that, but with a team, larger consequences, more direct ownership, and loooooonger processes because so many people get involved in everything. Her team is strategizing what could become a trillion dollar product (in like 10 years) if they get it right. It’s pretty cool.
As a software engineer I would rather do what your gf does than leetcode problems. I went to school already for six years and don't feel like hanging out on a website for the next six months solving CS problems.
I've always been of the opinion that a take home software engineering project that I can present in the interview would be preferable. Coding alone for a few hours and then being able to get all my ducks lined up.... Sounds like a practical and great interviewing process to me.
Yeah, having an entire day of 4-5 leetcode-esque interviews seems excessive (looking at you Google) but having none also seems irresponsible IME (looking at you government contractors).
I've been in organizations that were spawned by both of the above extremes. The former is definitely more pleasant to work in (everyone is at least competent) even if the interview was much less pleasant to do. I do feel like more orgs should try to target the middle ground instead of just aping Google and going ham on the leetcode shit.
Sure if you have a lot of noise, now if you know the people? If you’ve been working with them for years akready? Even engineers who want to change role within the org have to re-interview and do these silly exercises. I actually find leetcode things more valuable than system design interviews which are more like “let’s see how you can pretend you’ve built things at scale eventhough you’ve never done it”
I agree with you. It's just not going to work to trust peoples credentials especially now that people from across the states can apply to our jobs. I'm a fan of take-home projects though. You still need to find a way to reduce the number to something meaningful but a take home gives them time to think about the task, but also gives me an opportunity to hear them walk through their code when we talk.
If they "cheat" by having stack overflow do their work for them, but they can explain it well enough, they probably understand the concepts at least.
Google receives about 3 million applications per year, and hires less than 1% of them. Not all of them for dev positions, but still probably at least a million. Google is probably the most popular, but even the maligned Facebook gets a few hundred thousand applications per year.
I concur with the parent's point. HN is perpetually complaining about tech interviews, but nobody ever suggests a viable alternative that can cope with such application volumes.
Companies like Google (and similar) are kind of the exception; I'm starting a job next week, and I had an initial video call for almost all jobs I applied for when searching. Sometimes I wrote a cover letter, often I don't. My CV is decent enough, but not uniquely "oh wow!"-type of impressive. I don't think I was filtered out of thousands of applicants in ~90% of the cases.
While remote positions can certainly receive a lot of "noise applicants", as I discovered in my last job, you can filter out half, if not more, on just a quick pass. Most companies are dealing with dozens of candidates at the most, often less. Certainly not thousands of them.
Google (and all the other companies with similar net hiring ratios) use multiple factors to narrow their pre-interview pool; including standard techniques such as resume and phone screening. And then there's in-person interview itself, which involves broader cognitive and personality assessments (apart from in-person LC recitation).
The parent poster was literally saying that LC screening by itself will get you your 99 percent reduction.
Of course, LC-only won't get you there, and all companies with LC use the whole arsenal. But I don't doubt that LC will filter out a very large fraction of applicants (hence the incessant whining on HN). The point is though, with Google-like application volumes, if they drop LC they'll need to substitute it with something that also filters out a very large fraction.
The actual hiring ratio at google is something like 0.2%. They pass over 998 out of 1000 applicants, so no matter what they do, they'll pass over a substantial number of qualified people, and no matter what they do there will be complaints on HN.
The thought crossed my mind, that they are doing it on purpose: to make the whole experience of switching jobs as unpleasant and traumatic as possible, so that people will stick to their jobs. However a conspiracy is highly unlikely, given that there are so many players involved.
More realistic explanation: they try to make an 'American Idol' like process, this gives them the feeling of having chosen 'the best'. Now it probably takes some standardized task to do that kind of competition, as it is necessary to maintain the claim of having an objective hiring process.
I was once told, that in the olden days there was a different kind of hiring process (that was not about programming jobs, actually, they didn't have that job at the time). It would go as following: the owner would invite the candidate to join the crew for lunch, if the candidate eats a lot, then he would count as a good worker. Actually that would make a good test for 'culture fit'...
> make the whole experience of switching jobs as unpleasant and traumatic as possible, so that people will stick to their jobs. However a conspiracy is highly unlikely
I've thought this too. Apple, Google, Intel, Adobe, Intuit, Pixar, and Lucasfilm were hit with antitrust litigation starting around 2010 because they were all involved in colluding to reduce the ability of devs to switch jobs. Since then we've only seen the rise of leetcode style interviews. We're way way past the days of tree traversing and FizzBuzz. We're asking candidates to recite Dijkstra's but pretend they've never seen it before. It's just way more convenient for tech companies if people don't leave in the first place. I know I've stayed at my job much longer than I should because I hate interviews.
> as it is necessary to maintain the claim of having an objective hiring process
Yeah no one wants to admit they don't know what they are doing. It's bad for FAANG myth-making. A company the size of Google or Facebook is never not hiring. They are a big boat that can't just stop moving like that. They have a constant churn rate, the need to keep interviewers sharp, and a certain target rate they need to hit of applicants in, new employees out. All the process between the in side and out side is Scientology. It's just complete fabricated cultish nonsense. The owners of LeetCode must be enjoying it though.
>were hit with antitrust litigation starting around 2010 because they were all involved in colluding to reduce the ability of devs to switch jobs
I didn't know that, really interesting detail.
>no one wants to admit they don't know what they are doing.
Interesting perspective, though I don't know about the vodoo part. They seem to be taking the matter quite seriously, at least google does. Take the matter of competitive programming: Peter Norvig says they were checking, if taking part in programming contests would correlate with good performance at the job [1]; I think having read somewhere that Norvig revised his negative judgement later on, as they had examined more data [2]. (actually that would mean that they didn't act on the data to begin with, well well).
These companies are good at data processing, any data that is, at least they seem to be taking it dead seriously (disclaimer: I never worked at google, though I have managed to fail at interviewing there, however i am not sure if i would have accepted an offer ;-)
Oh, definitely. I'm sure they do take it seriously. I just don't believe taking it seriously to be the same as actually producing results. Managers still take OKRs/KPIs seriously. There are still people that believe in the healing power of Agile.
If any of these companies knew what they were doing then they wouldn't require multiple interview rounds. I expect the correlation between one's ability to perform at Google with their ability to pass the interview gauntlet to be no better than a coin toss.
Well, i have worked at Amazon, for less than a year; My rather limited impression was, that this is a very dysfunctional organization. Now if this impression is correct, then the leetcode appoach has some merrit; the leetcode approach would select for people, who stick to the technical part in the narrow sense of the word, and who would not question the state of things too much.
Working like that, at least at Google, will only suffice up to about L4. If you're good at leetcode, you might be hired at L4 directly, but if you're a normal person then it means you have one promotion before you need to learn completely different skills to advance.
I do nothing that looks anything like leetcode whatsoever.
Gotta keep the gate somehow. You wanna pull in the big bucks like everybody else on the team? Well? Study those stupid leetcode questions and suffer a day long interview loop first.
It’s hazing. Nothing more.
That being said I’d rather work for a shop that had at least some code tests. I’ve worked in places with none and the code quality is about as shifty as you’d expect.
The most amazingly productive engineers I’ve worked with have all been incredible leetcoders.
You’re right though — I might as well be saying they were also incredible bakers or skaters. If those were also high signal identifiers of good devs then we’d be kneading dough while doing ollies in the interview rooms.
What irks our industry is that there are plenty of good developers out there that produce quality day to day plumbing and integration work that suck at leetcode. That’s fine. We should hire them too, but if you are FAANG you don’t need to if you have post grad leetcoders knocking down your door every day of the week to supplement your already burgeoning cadre of sensible staff engineers.
I have never applied to FAANG for exactly this reason. But I have seen this style of interviews creeping up to dominate over the last decade. At least in the Bay Area. My impression is that European interviews are more sane (no dynamic programming, more take home coding challenges).
I’ve heard plenty of horror stories about someone being hired that couldn’t write simple code.
It’s easy to study leet code, and it’s relevant because it shows the interviewer you can write code.
I’ve had non-leet code interviews, like write some feature in 60minutes. It was fine. It tests code and knowledge as opposed to just algorithms and tricks.
I dunno I’ve always felt that the people who can’t leet code are the ones that complain about it. The ones that can just spend a bit of time to practice and ace the interview.
> It’s easy to study leet code, and it’s relevant because it shows the interviewer you can write code.
I have a million things I want to learn about. If a potential employer would rather I spend time on what amounts to trivia, then great, I don’t want to work there.
> I’ve had non-leet code interviews, like write some feature in 60minutes.
This is also a problem because it’s impossible to understand the constraints, context, specifications, etc. during this time. When I am asked to implement a feature in the real world, it takes time to understand the domain and context. Writing code is usually the last and easiest bit. It also never occurs that you need to understand and complete something in just an hour or two.
So in leetcode interviews you’re asked to turn on a bunch of knowledge you don’t really need. And in implement this feature interviews, you need to turn off a bunch of important knowledge and experience.
Both are irritating interviews.
The best way to interview, in my experience, is to ask about a project or projects someone has worked on. Even better if there’s time for them to present on it. That way you get a real world picture of their skills, they are comfortable, and you can ask detailed questions without jumping the shark. Further, it is perfectly reasonable for someone to be required to present and answer questions over something they’ve worked on in an hour or two. That does happen in the real world.
I’ve conducted many interviews that starts off with asking questions about projects. Many candidates sound like rockstars. They even nail all sorts of technical follow-up questions.
Then when I start asking coding questions, and I’m not talking leetcode here, more similar to fizzbuzz, they can barely write an if-statement. My conclusion is that some people are great at talking, but you really need to test the technical abilities too.
Perhaps your technical questions are not adequate enough if someone can sound like a "rockstar" while not being able to program an if statement?
I've interviewed hundreds of people over my career and I've never had an interview where I couldn't figure out their technical abilities through a conversation.
I'll tell you what leetcode interviews do find you though, they find you people that have no idea how TCP/HTTP work, they have no idea how you would debug a distributed system. They've never deployed anything to a server. They probably have no idea how to even measure the amount of work being performed by a server. They've never thought about CI/CD/Deployment/Scalability. They've never used any cloud resources. They have potentially never been through a code review.
etc, etc, etc, etc.
Someone crushing a leetcode test tells me about 1% of the stuff I'd like to know about their knowledge and abilities.
The best interview strategy for me is to give a short take-home assignment (coworkers go through it in under an hour max.) which is somewhat related to the domain space we are hiring for.
Some solutions are rejected on the spot (bad practices, does not solve the task correctly), other candidates are invited for a technical interview. Some generic questions, then we go through the solution - with emphasis on less than perfect areas. It is quite easy to see when someone is bluffing, and you also see how the person deals with feedback.
> The best way to interview, in my experience, is to ask about a project or projects someone has worked on.
This doesn't scale and introduces a bunch of biases on other dimensions. People who don't have time to prepare for leetcode interviews might be the same ones that don't have time to work on FOSS, and it could be that they can barely talk about their past work for IP issues. It's also way easier to fake your way through a high-level discussion of a software engineering project (that the candidate prepared) than through a leetcode interviews.
At this point, the leetcode interviews are as much of a behavior interview as they are a technical one, no? It makes sense that they're only hiring candidates willing to spend the time and effort studying.
“Ask about a project” proves I understand the final implementation, but not whether I could or did choose that approach or design it myself, nor how long it took and how many false starts we had.
We know how to apply them, it just that algorithms are not fit all solutions for most type of problems you encounter in the real world. I had to write a frequency analysis code. What I did was search for existing methods, found a paper that provides a mathematical procedure, then convert it to code. The data structures came directly from the OS and thankfully, there were no need to convert them to something else.
I'd say a lot of us learn about algorithms and data structures early in their career. But most of them are guidelines, not rules. So, you just remember how to google for them, not learning specific ones by heart. No one has ever told me: You need to work on this string manipulation and be done within 30mns.
And on the actual job you have two weeks on the sprint with barely any consequence, not time trial to beat the averages set by desperate college kids from Asia.
There’s probably better code writing interviews to be conducted, but I think writing code in an interview is important. I’ve conducted many interviews in C where the candidate has years of C but doesn’t know the stack from the heap.
So I dunno, it’s not fun doing the gimmicky leet code questions but it definitely filters candidates.
I think people in this thread take them for granted… many candidates struggle with them. The ones that think they’re easy and you just gotta study a little bit — they’re honestly probably pretty smart.
I run feature code interviews. There are no tricks, just data modeling, simple logic, and automated tests.
I am exceptionally good at algorithms problems and I recognize it is not a useful skill I want to filter on when hiring. A dev team of 20 may only need a few to really understand algorithms to look over relevant pull requests. and even then such situations may be rare
More like you gradually come to a realization that your time in this world is extremely, extremely precious.
And that you just don't particularly see a need to cater to other people's made up (and sometimes downright farcical) rituals to such an excessive degree.
No matter how much money they may dangle in front of you.
> More like you gradually come to a realization that your time in this world is extremely, extremely precious.
> And that you just don't particularly see a need to cater to other people's made up (and sometimes downright farcical) rituals to such an excessive degree.
> No matter how much money they may dangle in front of you.
I confess to not understanding this take, money can purchase back a substantial portion of time. Working at big tech can fairly easily reduce your working life to 10 years if you spend conservatively. Outside of big tech the norm seems to be more towards 20-30.
The cost of those decades of saved time? About 100ish hours of prep for your first interview, 40-50 from there on (based on personal experience, conversations with my colleagues, and a friend who runs a FAANG interview class). Assuming 3 job hops in your 10 year working life, that's 200ish hours to save 20 years. Is there a reason you don't think that's worth it?
(1) Most chiefly, the egregiously unethical behavior of nearly all of the "big" players (the rest being merely moderately unethical)
(2) Reports from close friends of the day-to-day grind at these places (literally none have anything more than superficially positive to say about it; some have suffered significant health problems, include one full-scale nervous breakdown)
(3) And the intellectual dishonesty implicit in the LC process also, but only as icing on the cake, as it were.
And independent of all that - it is by no means a binary (either you work or for big tech, or you grind along at for an extra decade or two at middle range). There are high-paying opportunities out there, if that's what you're out for -- they just aren't as immediately obvious to find as FAANG.
> they just aren't as immediately obvious to find as FAANG
Sounds like you'd need to spend some time to find these :)
To your other points, I get feeling revulsion to Google or Facebook, but I feel there are other companies like Netflix or Stripe that are ethically fine. The idea that the employees are generally overworked doesn't mesh with my lived experience the bay area, I have a fairly wide social circle and I don't know anyone putting in more than 40 hours a week at a big tech company unless they're trying to climb the ladder super fast. I think we also may have to agree to disagree on whether all leetcode is intellectually dishonest. 4 leetcode hard problems is a silly way to interview, but when working on problems at scale I appreciate a gut check problem on big O and an algorithmic workhorse like depth-first search or something.
I’ve been a dev for over 20 years and have never had to do leetcode to get a job. You either find a place that doesn’t require it (more places than you think) or rely on your network to get jobs (which is probably what OP is referring to).
No I won’t get a job at a FAANG this way, but I’m not particularly fond of megacorps.
For every software engineering faang level company that requires leet code interviews, there are 100 others that do not. Your rhetorical question is patently absurd.
I mean how much money is enough money? You have FAANG tier people crying about TC - at some point it becomes clear that's their whole identity. Maybe they're just sad to be stuck in horrible cities (I'm also in one of them lmao) where no amount of TC buys them peace and happiness. It is pretty cringey, and honestly sad. I've been to so many meetups which basically turn into grieving sessions for highly paid engineers to cry about how their friend got an offer for xx amount while they make 6x the average US person in a year.
And you have people making 6x less than you working at different jobs than yours. These kinds of complaints really lack perspective imo. Getting paid less at work is the same as over paying when buying something. Would you call it cringey if someone doesn't want to pay 30% more than all their neighbors for their house? They can "probably" afford it, can't they? Just be happy you have a house at all, right? What's a few dollars anyway?
What finance jobs? The only companies in software engineering paying more than FAANG are trading companies like Jane Street. And AFAIK they have harder interview loops than Google.
Yes, trading companies and even trading divisions at banks.
I've interviewed at plenty of them (only one in recent years, though) and while I wouldn't say they were easy, they aren't doing completely irrelevant challenges like leetcode.
I've certainly never studied for one, unless you count flipping through a book or two just to remind myself of things I may not have thought about in a while. Like 1-3 hours tops.
Imagine a job, say "Professional Football Player", where the only criterion for getting the job was "In three weeks, show us your six-pack, do 20 chin-ups, and do the 40M sprint in under 6s".
You don't have to dribble the ball, you don't have to answer a quiz about the rules of the game, you don't have to tackle anyone, you don't have to kick the ball, you don't have to be good at positioning yourself.
Clearly the test seems pretty odd as a way to pick players. But it has benefits as well. The expectations are clear. People who can't do it won't try. People who are in the ballpark and pass will feel special.
Leetcode is a first-order screen to find people of base-level minimum intelligence and problem solving ability. It's not a quiz of actual problems you'll solve on the job, it's a way to screen out the wannabes who couldn't program their way out of a wet paper bag.
Grinding leetcode also shows you've got grit, and are willing to prepare for a task and do what it takes to succeed.
Grind leetcode, show the companies that you can meet their minimum threshold of cognitive and executive capability for entry into their tech department... or don't work for them, it's that simple.
If I ever do an on-site interview again, I’ve given thought to just bringing in a six pack of beer. If I get any bullshit questions, I break out the beer and say “how about we pretend that I did a good job on this question and talk shop about what you really need here, because that’s what I’d like to talk about.”
When companies like Facebook get thousands of applicants per job there has to be _some_ way to unceremoniously cull the herd. Leetcode is it.
I've interviewed at a lot of other places and it's mostly take-home assignments or just talking about past projects or my open source projects. I've never had to do leetcode for an interview in 14 years of working as a software engineer.
the reason why FAANG/M companies do ds/algo interviews is because they get an ocean of applicants and it's necessary for these questions to be the immediate filter.
Most startups I have applied to previously rarely asked ds/algo interview questions.
It's not that they want to, it's that they have to.
> I’ve yet to meet someone who thinks these are a valid metric.
It is a valid metric. It screens for "overachieving" types who have the will power to power through unpleasant drudgery for a pot of gold in the end. If they really want those kinds of people who am i say its 'silly'.
> Why do we make <leetcode> the gate keeper to our industry
This is not about having to use leetcode type problems in day to day work.
Knowing about those is about a state of mind and a culture: that you are passionate about tech and have what it takes intellectually to dig very deep into it and not just another drone that learnt Java just because you knew it would give you a decent-paying job.
I've read through some of the comments and there is some solid advice. I work at a large company and see this fairly frequently.
You have to approach these things as what do you want out of it.
Do you want to prove someone wrong, just to prove them wrong?
Do you want to steer them in a better direction?
Is this something you will end up owning, so want to avoid the pain?
etc..
There are numerous scenarios. For me, we are one company, large or small if I am not trying to steer it towards a better path, why am I here? If thats the case, I should just take my paycheck and shut up. It's good you care, it means you value your company and/or people.
That said, let me share my exp.
When I was 18 I managed a restaurant my dad had bought. I was a kid telling people who had worked there for years what to do. One day I disagreed with a head waitress that had been there for 10s of years. I did it in front of customers. She got defensive, stormed out, and I served tables the rest of the day.
The takeaway here is, theres a time and place. I feel my role as an employee is to work slightly behind the scenes. I advise my management why I think an approach is better or worse, highlighting we CAN go the way you suggest, but how do you propose we handle X. Usually you can lead them to the way you believe the correct one.
Another point to keep in mind, you dont know everything. I think the most valuable thing I have learned is to understand the motivating factor of why something is going in this direction.
Is there a timeline?
Funding constraints?
Promises made?
Is the person an idiot?
Again, there are so many different scenarios.
There is no black and white answer to your question. I will say though, if you make a statement, be confident you can back it up. Be sure you have thought it through, because there is nothing worse that saying someone is wrong, rallying people to your side, and being unable to deliver.
Small improvements on every feature you write. Just keep iterating, sometimes things look bad and you want to delete useless lines. But those useless lines may be there for edgecases that you don't know about.
Enhance, clean, iterate. Inspire the other devs to write cleaner code by leading by example.
I can appreciate this point of view but I think you are missing out. We learn as programmer's by making mistakes and experience. Familiarizing yourself with a crappy codebase (you didn't write) not only helps you get better at debugging but holds a wealth of experience of what not to do. As you don't write shitty code yourself, how else will you learn to deal with these problems? Everything we do should be to further our own skill set. My first real programming job was working with quants who wrote 1k single procedure Perl scripts, you had to scroll your editor to the right to see all the indentation from conditionals. When I look back it's one of my most valuable learning experiences.
I'd actually like something more like thunderbird/gmail for multiple accounts, where the storage/client is mine, but the imap accounts it connects to are on other services, with multiple account support...
In the past, I've used Python to automate Excel, Outlook, and some non-MS products like Catia.
Honestly, I don't see the advantage here. FOSS is nice, and OSX support is nice, but if you're interacting with MS products, FOSS is not a concern anyway, and it's probably running on Windows...
What would be really nice is if it supported multiple backends, so I could run the same Python code with Excel, Apple's Numbers, Google spreadsheet or Gnumeric, and have it work the same on all of them.
My dev friend and I were looking into doing a similar product a few years back. We stopped because of laws that prevent you from putting anything that may obstruct you or another drivers vision / attention.
This is such a great project. I remember when it started back when I used to work in perl. The main devs on it are awesome. If I ever build anything in perl again that needs an webserver it would be this.
I do most the interviewing for our tech team. I will rarely even ask a technical question. I look for passion, confidence and that they can keep a dialog on the topic of tech going. If I cannot have a conversation with someone for 30 minutes, how would I work on a project with them for months? I personally loathe logic and algorithm questions. If I ever get asked them myself on an interview I will actually ask for a different set of questions. I dont think it adds any value.
Why do we make this the gate keeper to our industry when we know (except for the very specific roles) we will rarely need leet code type problems. When we do we just google them.
So silly to me.