Ask HN: What to do about ‘Good at programming Bad at Leetcode’
Many of these people are fresh out of college and the ‘industry’ puts them through leetcode/hackerrank style rounds that are needlessly hard. I’ve seen the kind of questions these rounds have and quite frankly, if I graduated this year, there’s no way I’m going to get a job.
Ever since 'Cracking the coding interview' was released, every company's interview process has become like Google's and Google didn't have a particularly great interview process to start with.[0][1]
Now, there are several GitHub repositories that prescribe 3-4 month grinds on leetcode questions to "crack" the interview. And people do go through this grind.
The people who do manage to crack these rounds are not necessarily good at programming either because the time they spent doing competitive programming stuff should have been spent learning to build actual things.
The no-whiteboard companies are very few, hardly ever seem to have openings and not hiring junior engineers.
What would be your advice be to fresh college graduates, or anybody for that matter, who are good at programming but not at leetcode? Surely there must be a way to demonstrate their understanding of algorithms without having to spend 3-4 months memorising riddles
[0] homebrew creator.. https://mobile.twitter.com/mxcl/status/608682016205344768?lang=en [1] Zed Shaw gets offered a sys admin job https://news.ycombinator.com/item?id=93984
502 comments
[ 2.7 ms ] story [ 396 ms ] threadIt’s a common thought among my circles that interviewing is the hardest part of being a software engineer - once you’re in somewhere it’s a lot easier.
There needs to be something better.
I’ve heard a similar sentiment from my circles too. But lately
I’ve also met people for whom it’s the exact opposite: they can clear the first round of the interview and they fail in the subsequent design rounds (which in my opinion are a lot less challenging)
I’ve also met people who manage to get hired but are soon overwhelmed with the real work that they have to do and some even get pip’d
Engineers are expensive to start with and inexperienced/over-confident engineers even more so due to the potential damage on the product.
Tough interview stages like leetcode are a simple method HR can employ to establish a baseline competence.
Personally I have zero interest in grinding for months solving riddles and when interviewing I always check what the stages involved are. On numerous occasions leetcode has been dropped upon request - no harm in asking!
I'm not so convinced that these are two distinct things. I want coworkers who can maintain their level of skill under extremely hostile, stressful conditions. I'm not going impose those conditions on them, but I can't necessarily control the myriad third parties or circumstances that might.
If you care primarily about your salary, become good at leetcode.
If you don't, join a startup.
But to be honest, your answer is not likely to change my opinion. For the vast majority of new grads leetcode is the obvious recommendation to maximize income. People grind for 3-4 months because it actually works, that's the reality.
You have a different target employer than I do, and that's fine. I optimize for a different set of requirements.
Maybe OP is, too. If he isn't, I think my suggestion is appropriate.
Knowing how to solve problems for someone willing to pay you a lot for it seems to trump knowing how to solve problems in a specific way. I've improved my salary more by putting work towards fixing things for existing code bases than I have by building brand new things on brand new technology.
With that said... having been in the position of the hot-headed junior engineer full of ideas, I don't think that position's without merit either. The trick is to balance new ideas for the employer, personal knowledge growth, improved performance for the employer, and making the right kind of mistakes.
In that latter bit, I don't think _anyone_ has figured it out, yet. Not in a way that's easily repeatable, anyway.
Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.
Doesn't mean that pay grade is fully correlated with skill, of course. There are other industries that pay more and don't require anything like that.
But the thing is... you can
Most of us are not designing algorithms, most of the time, or any of the time
Many engineers are just filling seats in places that are just in the business of sucking up talent from the market instead of having a bunch of entreprenuers running around
Rest and vest
However, something to note is that while money is important, it's not the most important thing in life. Or it shouldn't be, anyway.
I work at a well known SV tech company with about 3k ppl and we got over 50,000 job applications last year. Code interviews suck, but they're a scalable way to assess skill with minimal bias.
A fresh grad is expect to be able to solve ~medium problems.
Someone with ~2 years of experience is expected to be able to solve ~hard problems.
Someone with 10 or 20 years of experience is still only expected to be able to solve ~hard problems.
The standards for a more experienced candidate are of course higher for other attributes: Leadership skills, communication skills, etc.
And if you would suggest they learn them what would that person be gaining that they lacked before?
"Skill" is probably one of the least valuable metrics of a given hire's performance over time for an employer.
Yes, being able to effectively select for the people most likely to develop a competitive non-extant algorithm is an important metric for certain employers that skill tests will assist with. However, it's as niche to general society as academic studies are.
This is not to say that it's unworthy of practice or attention. In some cases, it's absolutely justified.
What I'm advocating for, however, is skewed towards the broad middle of employment cases - people who are competent, able to solve most day-to-day problems, and not adverse to new practices.
In most cases, people aren't looking to advance the knowledge of a particular field of study. They're just looking to solve problems for their day job while earning appropriate compensation. The employer gets a satisfactory advancement of their capabilities, and the employee gets to enjoy a quality of life they're used to.
The "broad middle" is much messier, but also easier to filter for. As a hiring manager, I would look for people that are A) not obvious assholes, and B) likely to improve my team's performance in some measurable way.
In other words... Company X, which lives and dies by having the absolute latest technology available to humanity, may well need to use code interviews to even establish a baseline performance metric. Company Y, which is just interested in appreciably improving its market share versus a wide cohort, is probably better served by "softer" hiring metrics.
You are also less likely to deal with the "leetcode" subject matter (e.g. design and analysis of algorithms) at a non-tech company, so if you don't want to deal with that, applying at a non-tech company is a good idea. Does not mean that a job at a tech company won't be like that, though. They have CRUD SaaS apps, too...
It's all the money that they're making compared to everyone else. Even in a crash like we're seeing now, they have extremely high revenue per employee.
The other US markets don't "get it" yet imho.
We've had a problem with candidates who seem impressive on paper and during the first phase of the interview, and then can't solve this exercise without being seen to glance at Google or SO results on camera -- or worse, being caught copying a worked example directly off the web!
There are plenty of people who can talk a good talk about their technology experience but can't write a line of code to save their lives! Entire majors at universities are devoted to this; when I was in college, all the people who couldn't cut it in CS because math, fell back to MIS -- Management Information Systems -- whose courses had big colorful textbooks I call "Richard Scarry books" because they're packed full of busy-looking illustrations. MIS helps you learn about technology in a business context, but prepares you very little for actually doing technology and building the systems with it. The coding exercise helps screen out the people who can't actually do what's needed of a developer.
I guess people reach for leetcode because it's easy, but it misses the point of the coding exercise. The point is to screen out people who can't program at all, not to select for the programming equivalent of NES speedrunners. So it needs to be set at a very low bar and administered by forgiving interviewers.
If you can hit director level, they stop asking leetcode questions. But if the goal is to eventually get into a Big Tech company, they may down level a startup director to be a line manager (which may still require leetcode).
I still don’t feel ready.
If you’re curious: https://www.github.com/glouw/rr
I applaud the effort, I'm just curious why you say you wrote it "just to solve leetcode", when I'd imagine the skills for creating a programming language have limited overlap with Leetcoding.
FWIW golfing languages are a thing, where a language is designed specifically for code golfing type problems and usually optimizing for a tiny core language and small source files.
i take this as an insult and reject instantly
no matter how much money and stock you offer, i'm not gonna bend my back over to prove anything to you (that's what resume and GitHub are for, fool)
luckily, i have saved enough money to not care about this shit
Leetcode is a very learnable skill, and I would argue any decent programmer can learn it well enough to pass an interview. I for years thought I wasn’t good at it, then I actually practiced and I got job offers at google and Facebook. I have also optimized code quite a few times using algorithm skills I picked up practicing for interviews so it’s not totally a waste.
There is a limit though, and some companies are pushing it with absurd questions that you couldn’t reasonably solve unless you had seen it before.
In summary, algorithms are useful and learnable, but some companies take it too far.
Leet code is very contrived. However, learning leet code, then applying it in an interview shows you have the aptitude to learn quickly.
I've been 10 years in the industry. If recruiter tells me I need to prepare for an interview in ways other than looking back at the projects I've done, then the interview is not testing for what is important on the job.
Some people lie on their resumés.
If they're good at lying in person, it can be difficult to detect that.
If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements.
I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing.
My point isn't that I want to only chat about my resume - just that the problem you give me should be something I may encounter in the new job, ergo I do not need to prepare for that since my entire career prepared me for those (unless I want to reskill and the new job is different than the old one, then some preparation may be warranted).
> If they're able to deliver working code of some kind under the pressure of a job interview, then they're almost certainly about to actually program at least a little, so you can trust me of what you see in their background and what they tell you about their achievements.
Sure! But if the assignment is depending on stumbling upon a brilliant idea, instead of solving a problem that you may see in your day-to-day job, then I don't think it's useful. Think "trim a string" or "split a CSV" [1], not "find the longest increasing subsequence". And maybe also explicitly stick to ASCII encoding for string-based problems (but TBH, if a candidate asks about encoding, they probably know their stuff, or at least know where the gotchas are)...
> I'm personally skeptical that leetcode really tests what most companies need in a programmer, but it's probably better than nothing.
Agree that it's better than nothing. Disagree that we can't do better. :)
Edit: [1] ... maybe w/o relying too much on standard library if those are built into the language you chose.
FWIW, I agree we can do better than leetcode.
I'm personally a fan of an approach I saw someone else describe here, where you literally have the candidate do a few-hours freelance gig for you, paid at a decent rate. Triage some of the low-priority bugs so when you're interviewing you have a little stack of relatively self-contained, well-defined tasks for candidates to pick from. Probably good to have someone pair with them, if the candidate is willing.
You get to see them work in a real context, they get paid, you can learn about how they work, and it seems like a win-win to me.
I also think it's good to be open to other options - if a candidate has a different way to show they'll be good at the job, let them do that. If burntsushi wanted to work on a company's CLI tools, I'd hope a link to the rg repo would satisfy everyone that he knows how to write a good CLI.
That’s not why they were introduced. Leetcode using tools like hackerrank were introduced because college GPAs were very bad indicators of programming proficiency and a lot of people also did not have a CS degree.
The questions weren’t this bad before.
And these competitive programmers aren’t necessarily fast at learning things either.
the trouble is that this just trains code monkeys to memorize optimal solutions to a set of problems and to quickly reproduce them.
it does not optimize for real engineers who have the experience to build good software and to come up with creative solutions to hard problems.
It was out of that judgement, that companies started to require degrees for office jobs of all sorts, as you could discriminate based on education but couldn't on an arbitrary IQ test. And naturally, tests on the topic of a job can also be administered.
And I do think you're right - Leetcode does select for recent graduates who likely were taught in a throwaway language for academic purposes. And selecting for young college graduates are highly likely what they're searching for, as they also do not know their worth.
I think lots of those who stay on long-term in that environment, say >3-4 years, effectively become institutionalised, condemned to spend the rest of their life philosophising about whether they can ever be L8 material. These are people who are, by and large, smart but not wise. Yes, the money is good, for an employee, but it barely equals what even a small business owner could make - and these are people whose smarts would allow them to thrive in the software niche, at least with a minimal amount of commercial nous.
The truth is that FAANG (or FAAG, considering what's going on at Netflix?) keeps these people there by creating a value system. If you've ever read the internet-classic 'Five Geek Social Fallacies' post (https://plausiblydeniable.com/five-geek-social-fallacies/), you'll know that people like us - frankly - are suckers for taxonomy. If you tell them that they are the best because they work for you, and the only thing that can make them any better as an engineer is creating maximum returns for the Borg, and surround them with others who mirror and validate that behaviour, they will fall for it for the rest of their lives.
Don't fall for it. There are a fuck ton of smart people at FAANG companies – that's one of the few marketing points which is unvitiated in its merit, they do scoop up very many of the smartest (again, smart-not-wise) people in the world – but that doesn't mean the only way to be smart is to join. It doesn't mean you - as a unique human being - will be happy there. Carve your own path, be suspicious of people selling you axiologies and hierarchies, find a middle road between excessive cynicism and excessive credulity.
I feel very strongly that this premise is flawed. It shows that you have aptitude for a very specific type of learning.
I lead an engineering org at a small startup. We teach our engineers to dive deeply into the customer value prop to find ways to deliver the simplest technical solution to their problem. You don't need leetcode skills when you can identify simpler, more accessible solutions to a customer's need.
The reality is outside of very specialized technical businesses (or business components), most engineers jobs are not to build technically advanced solutions.
MAANG seems to use Leetcode as a legal proxy for conscientiousness and IQ without testing for other relevant qualities such as strategic insight, creativity, and other skills that are essential for a successful business.
There's no problem with testing for basic coding ability, but if you're not selecting for broader skills - preferably with some diversity - you get the same old leet monoculture causing the same familiar delivery and stability issues.
If you aren't willing to dedicate a considerable part of your unpaid, personal time to an activity that they mandate, you aren't a good fit for them.
Now I'm mentoring two devs who didn't study CS in college and only completed a coding bootcamp and they're working out amazing.
This is my take too. So I don’t see where the disagreement lies.
Except it’s not just some companies doing it. All companies paying over a certain threshold seem to be taking this to ridiculous levels.
And please do share your ideas for what people should do or what finally convinced you that you weren’t bad at this
They can afford it. And assuming they are a tech company, they need that in key roles. You cannot write things that scale without solid knowledge and intuition in designing and analyzing algorithms, something that can be learned and furthered through experience.
Now of course it's true that not every job in a larger tech company is like that, so there would be some room to adjust the interview based on the exact role. And there actually is. But overall, if you have a massive amount of people applying every week, why take chances, why not take someone from the pool who can demonstrate the skill and allow for some horizontal movement within the company, into a tech-heavier team?
> And please do share your ideas for what people should do or what finally convinced you that you weren’t bad at this
For me, back then, it was something that was fun for me. Part of why I got into computer science in the first place. I would be totally lying if I said I didn't study for the most relevant of my interviews, beyond what I would have done without them.
But I distinctly remember for example freshing up some graph algorithm skills not by doing leetcode examples (I don't think "leetcode" was already a thing back then), but by arbitrarily taking the Debian package database and do fun self-made exercises like: Let's find the largest strongly connected component in the debian package library, i.e. the largest set of packages where installing one will always install all of the others.
> You cannot write things that scale without solid knowledge and intuition in designing and analyzing algorithms, something that can be learned and furthered through experience.
The point is not whether people need to learn algorithms, they of course need to, but that Leetcode questions seem to test people’s ability to solve riddles more than their ability to design algorithms
Basically if you weren't already familiar with the question and knew the trick you're screwed.
Plus they're really blatant about it too – the recruiters will _actually tell_ you to practice LC, and to try again in 6mos/a year if you didn't make it this time!
Here they do this before you even take the interview for the first time
The recruiters actually email me all the leetcode prep material and tips
No, I said design and analyze algorithms, which is a distinct skill from "learn algorithms" (although that certainly helps). And which is certainly very riddle-like.
Ie. Leetcode style programing is/was used to filter out engineers that couldn't program. And the problems themselves were relatively easy, reverse a tree, build and LRU (which is not trivial at all).
But then there is an army of prep information, and people are just optimizing for Leetcode style programing. Then companies have to raise the bar again, and keep asking even harder questions. ie. build LRU from scratch was considered hard, now it is just a 'medium' level.
It has taken to stupid levels, where it is not anymore a metric of 'is this person a good engineer', but more of a 'how much this person did prep'. i.e. it becomes a measure of effort and desperation, and not just sheer ability.
That's why you see so many stories, of engineers preping for leetcode only, getting in, and not being able to do their job and getting piped....
Also, personally, the best thing that I did to make me a better engineer was creating an app, a backend, and full service, with paying customers. That taught me much much more than spending months on leetcode ever did. Brushing up some CS concepts and Data Structures, and some coding, does help you to become a better engineer. But doing just that, it doesn't make you a truly useful engineer at all.
It’s the ‘Cracking’ idea that has thrown this whole process off. People have started over optimising for the metric
Sounds like they are trying to breed a cult...
Lots of programmers think they are 10x but few are. Even my best senior engineers took 2-3 months to settle in and contribute more than they take and juniors are bigger gamble.
The best proxy now is will you spend 1 hour on a simple set of tests, if not you are not serious or are shopping for counteroffers.
I worked across a couple big tech companies mentioned in the thread, and I've met maybe a couple coworkers at most who "devoted their life to the company". And that's across almost a 3-digit number of people i worked with in some capacity over the years. People take vacations often, they work 40 hours a week or less on average (over the year).
One big thing about most teams at big tech companies (probably sans Amazon, from what i hear, haven't worked there myself) is the work/life balance being an important priority. We had a manager giving stern talks to the few teammates who would reply to work emails on their days off ("you left for a week of vacation in Hawaii, why are you replying to work emails or even brought your work laptop with you? Please stop doing that and enjoy your vacation, everything will be totally fine when you come back.").
I don't even care to defend any company, that's their problem. But seeing the whole "cultism" and "expected to dedicate your life to the employer" accusations just make me feel like I am reading some alternate timeline fiction story.
They've decided things like ability to devote time to a meaningless skill that is required to get the job, attention to detail, and problem solving skills are what is required to become a great engineer and see that letcode is a good way to test for those things at massive scale.
I don’t know where people get this idea. Leetcode used to test programming proficiency
I feel the only reason companies continue to take leetcode to absurd levels is because (a) they think harder questions would get them better engineers and (b) other companies are doing it
The discussion is exactly this, that leetcode is used to test programming proficiency, but it's an inadequate bar.
The parent is postulating that it's a lie; that actually leetcode tests for malleability, and we're getting bent out of shape because we think it's a poor test of coding ability.
However it might be a good test of malleability, and that might actually be it's intended purpose, but that's not communicated.
200 person tech companies are doing the same.
I guess that really depends on the language. IMHO, if you can solve a reasonably complex problem using a language, you know that language.
Find the (gotcha) in this string and emit len(gotcha) ... Now do it computationally efficiently (or be able to explain tradeoffs to other resources).
Go makes normal string operations tricky due to rune being an alias for int32, ranging a string gives []byte indexes ...
https://go.dev/play/p/33jCwNG6Eu6
But manipulating sequences comes up a lot in many contexts. Usually it's sequences of more complex things: instructions, packets, files, polygons. It's hard to assign tests directly on those, because you have to explain the objects themselves first. So it's a reasonable shortcut to test ability to manipulate sequences of characters.
LeetCode problems are solved with under 50 lines of code, using textbook models.
So I don't think these interviews evaluate the candidate's ability to solve complex and abstract problems. They seem to evaluate the candidate's ability to grind contrived sophomore-level computer science homework. Experience solving the real-life version of the problem rather than the academic one is unwanted.
There is quite a world outside these mammoths Google/Facebook/Amazon/(MS, depending on how their IBMization is going these days) and their minions/wannabes. Personally I would not work for any of these even if they paid me in gold bars.
I mean, look, it sucks when you can't get a job. I've been there (when I briefly tried to escape programming for a different metier) and it's awful. But pretending that the entire outside world is a dark mass of malevolent forces arrayed against you.. well, it may be psychically necessary in some Freudian, Jungian sentence, to prevent ego death or whatever, but in the long run it's neither (a) true (obviously), and (b) nor is it going to do your mind and mindset any good.
Maybe you can post this in the endless Russia threads posted here, which seem to have crowded out the endless China threads.
I guess what you're saying is that apprehension about the motives of of corporate executives is so irrational, it's akin to a psychological problem.
No, that wasn't what I was saying there, but coincidentally, yes, I would agree with that statement. For one, 'corporate' is a phenomenally lazy word used to invoke some mental image of besuited sociopathy, from a million children's movies and internet debates. In the real world, 'corporate executives' - human beings, mothers and fathers, working in management careers at (large) companies - are humans doing jobs, like any other humans doing jobs.
I've been involved (as an engineer) in C-level meetings with people like that, as well as worked alongside them in the same teams, and my experience - thoroughly unsurprisingly given what I said above - is that they are pretty ordinary human beings on the whole. I'm sure there are differences between companies in terms of their cultures or values, but that's company-specific and not discipline-specific or seniority-specific.
I get that your experience is that these are people who mete out decisions from on high, which affect you in sometimes-negative and always-unforeseen ways, and that makes you feel like a mediaeval peasant might have felt towards his feudal liege. And maybe it's helpful, from a cathartic standpoint, like I said above, to picture them as evil baddies from kids' movies. But no, the reality is more banal.
(Incidentally, I think those who worship company CEOs - and suchlike - are equally stupid, from the Elon bros to the HackerNews types who recite stories about startup founders as though they were superheroes. These people underestimate the role of chance and – in a way, very similarly to you – overattribute the differences between execs/founders vs regular workers to a proportionate difference in their inner essence [in their case, they think intelligence & industry; in your case, you think amorality]. Both are fantasies.)
This doesn't reflect my lived experience in SV. People I know who learned leetcode skills and got into big companies usually work less than people who passed more practical tests and get into smaller companies.
I'd say big companies are trying to hire employees who are a "good" mix of:
1. Smart
2. Conscientious / willing to work hard on the right things
3. Existing CS knowledge you know well enough to explain and apply.
For some vague handwavy definition of "good"
(2) is probably worth expanding a bit. Many people are willing to work very hard on the wrong thing, this extends to engineering. As an example, a common failure pattern you might see is someone constantly struggling with how React works and what they really need to do is sit down and read the ~15 pages of documentation. But they never do, and just keep putting in 10 hour days with subpar output.
I've met some legit geniuses (think Putnam winner) for whom basically no studying was required to pass these interviews. Companies paying top dollar are happy to have them. For people like who are less smart and need to dedicate ~100-200 hours of focused studying and practice, companies paying top dollar are happy to take our mix of smarts and willingness to do that work. But once in the company I haven't noticed any expectation to "devote my life" to it.
Why not ask candidates to build a desk? As a take-home project! If you're truly kind, you'll let them keep the desk even if they don't get the job.
Sounds like the epitome of a slippery slope, to be honest.
Some people are going to say FizzBuzz (or similar) are a good enough bar.
More people are going to say 2Sum is a good enough bar.
Even more people are going to say Longest Common Substring is a good enough bar.
{...}
And the cycle will continue, because people who will have been asked such things will (most of the time) feel like 1) they've been asked it before, so now they must ask it, 2) they can solve it and feel anyone can solve it (in theory this is fine but in practice, not everyone can solve a problem in 45 minutes that they've never seen or never fully solved before).
Which reminds me of when I was going to college and I frequently had professors or TA's say X problem from the problem set is an "easy" one. Well, yeah, you're the professor or TA (for a reason) and you're the one giving it, of course you'd know how to solve it and such.
System design on the other hand... that can be hard to prep for!
The reason companies provide so much info upfront, and even send candidates to leetcode.com, is so that everyone knows what to expect. Not everyone is on HN or is even aware of these types of interviewing trends.
It's just a simple filter with the usual caveats of false positives and false negatives.
I highly doubt that we are talking 3-4 months of memorising riddles. There are a few recurring concepts that you should memorize, sure. But after that, if you have the programming and logical thinking skills you claim to have, you should be able to think on the spot for the rest of the leetcode question.
Here's what I recommend: start with a specific topic -- maybe HashMaps, Graph Problems, Dynamic Programming, Greedy Algorithms, whatever. Start with the easiest problem on Leetcode for that category and work your way up to a "Hard" problem in the same category. It helps build a mental "muscle" for that type of problem, and it will be easier to activate that "muscle memory" whenever you have to brush up on Leetcode again for your next round of interviews in the future.
I would disagree. My guess is you are only going after top tier companies. It is okay to have a job with a company that is not a household name.
I kid you not, I’ve received messages from 200+ companies over the past 3 months and all of them have the leetcode round as their first round.
I've been asked a wide range of interview questions from "what's a cache" (I answered "would you like to me to cut to the chase and implement lru cache in python?"), how many steps does it take ants on a stick to fall off (https://physics.montana.edu/avorontsov/teaching/problemofthe... the interviewer said "it's easy if you just think of them as virtual ants that can pass through each other"), "what's the average waiting time for a bus that comes every ten minutes" (interviewer could not answer some of my starting questions like, "what is the arrival distribution- every ten minutes, or is that just sort of an average, is it poissonian, are the buses interacting with each other, etc", "implement quicksort" (got this wrong the first time I interviewed at Google).
When I interviewed at a company recently a junior employee administered a question straight out of leetcode, with the data inputs and outputs completely unchanged. I exited the interview and contacted the CEO directly to say that if that's how they interview senior staff, it's not the company for me (I wouldn't have complained if they'd changed the inputs/outputs or slightly modified the problem, or came up with their own interesting variant).
Because we need some signal that a candidate can program and do something a little more complicated than fizzbuzz.
The homebrew creator shouldn't have been hired at Google if that was his attitude. Also, homebrew sucks and many googlers try to avoid it if possible.
My suggestion is to start with the easiest leetcode questions and memorize the answers and type out the code and run it with various inputs.
> homebrew sucks and many googlers try to avoid it if possible
Huh? What do they use then? I wonder what makes a Google engineer with a MacBook different from any other engineer with a MacBook that only Googlers in particular are avoiding brew
Many of the questions in leetcode have a skill rating. The easy ones- I expect most programmers to be able to figure out in 30 minutes and type out an answer. The hard ones- those are for people (as you say) doing programming competitions, or who are doing CS research and have a lot of prior knowledge and skill, or for extreme coders operating at the 10X level.
I think many people have moved to macports. In my experience, the Googlers mostly do dev in the cloud and don't depend on having custom software installed on their machines. Also I think the other big problem was that half of homebrew is broken any time you try to install something complicated.
I did the opposite. Macports reliably broke itself every three or four months under ordinary use, and Homebrew's package selection was much more useful to me, so I switched. I also think the Homebrew CLI is above-average, ergonomics-wise.
Granted, that was about 10 years ago, but exchanges for/against brew and macports looked awfully similar then. But maybe it got better, I dunno.
Homebrew is popular, and is indeed a very successful project, it is just not very well designed. Let me quote the author's own words:
> https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
> I wrote a simple package manager. Anyone could write one. And in fact mine is pretty bad. It doesn't do dependency management properly. It doesn’t handle edge case behavior well. It isn’t well tested. It’s shit frankly.
> Is it any surprise I couldn’t answer their heavily computer-science questions well?
> On the other hand, my software was insanely successful. Why is that? Well the answer is not in the realm of computer science. I have always had a user-experience focus to my software. Homebrew cares about the user.
Google is more than welcome to come up with something better...
We do the dance when we swap jobs, other professions do the dance as their licenses / certifications expire periodically. I'm sure there's an engineer somewhere that struggles with anxiety when attempting their Engineer in Training [1] certification too.
In short, buck up.
1 - https://en.wikipedia.org/wiki/Engineer_in_Training
The huge advantage to the latter is that it decouples the license exam from changing jobs. This helps for two reasons:
First, it means that the friction of the recertification doesn't coincide with the friction of switching jobs. It's a lot harder to leave a bad job when you know you'll need to review for the "recertification" for a month before you can start interviewing.
Second, in these other fields your employer has a vested interest in keeping you certified, because you can't keep working if you aren't. This should mean that they're incentivized to help with the process, rather than it being something you have to take full responsibility for and do on your free time. In software, not only do your employer and coworkers not help you study for "recertification", you have to actively keep it a secret that you're grinding leetcode lest you tip them off that you're looking to switch jobs.
Should the hoops be a take home assignment? White boarding? Pair programming? A new governing body that offers a license? Not sure, but something will exist, and your anxiety and need to prepare likely won't disappear.
Since they haven't created a cert, and they do make people re-test, they're clearly doing it for purposes that aren't served by those actions.
For one thing, I don't think they'd be happy about any change that makes it easier to leave. Imagine what'd happen to comp at these companies if you didn't have to do yet another goddamn leetcode gauntlet every time you switched.
My problem with this analogy is that our field has no examinee "bill of rights" that slowly evolved over time (often hundreds of years or more) in some of these other fields. We (software developers) have no idea who will be conducting our exam, how they will be grading it, or whether it will be done consistently. We don't know if the graders are competent. There is no clear and defined study path, nor do we get any feedback. The exams appear very suddenly, when we get an offer for an interview, we have very little control over how and when the exam will take place. And lastly, we take them again and again and again, every time we interview.
I've read that people suggest several hundred hours of prep on leetcode to get ready. When I interviewed at Google, my lunch interviewer (no coding, just a conversation) told me that when he got an offer for an interview, he asked for and received well over 6 months to prep, and he studied intensely the entire time. Now, for the bar, I'd understand this, because passing the bar doesn't require getting hired by a particular firm. But if he'd missed google? Well... I suppose there are other companies, and the prep would have you ready. But also - these interviews can take all day, and there may be multiple rounds. Hundreds of hours of study and several all day exams? That actually sounds like something approaching the bar - but for just one company that can capriciously throw you out, with secretive processes and no accountability at all.
Law firms don't run the bar exam. They respect the results, and I suppose some might volunteer or work as professionals, but Dewey Cheatum and Howe does't run the bar. Also, large law firms don't claim that there is a critical shortage of lawyers to hire, all while running a makeshift, privately administered bar exam that they acknowledge results in an extraordinary high false negative rate.
I'm not sure if there is a great alternative to leetcode interviews, and I actually do respect the right of high tech companies to hire as they please. But I sure have no sympathy for companies that rely on these interviews and then wail about a shortage of people to hire.
There's tremendous potential in this space for a startup, but nothing seems to have stuck, which demonstrates the difficulty of getting companies to trust a third party. They'd almost always rather trust their hiring process flawed though it is.
In perspective, is 3-4 months of studying to get a job really that big of a problem? I spent longer than that studying for the SATs.
That is not universally true.
So I guess try to get your first LC job before your personal life gets demanding, then hold on to that job for dear life so you don’t have to grind LC again?
Very skeptical of someone who switches every 2 years... you also become only really efficient after 6 - 18 months.. not only the code / legacy / wider system your stuff integrates with, but also socially knowing all the right people, context of all the bigger processes, a good chunk of domain knowledge ingrained??
Sometimes it’s not the worst strategy as the hidden truths of a startup reveal themselves over the course of a year or two.
I think it doesn't have to be this way if you focus on the fundamentals when you prepare, as it's easier to refresh a reasoning that clicked the first time than a complex algorithm you understood only superficially. And these fundamentals are enough for leetcode problems of medium difficulty.
I have studied at least a hundred hours for leetcode and I still have never passed an interview at a well paying company. Leetcode hards are legit hard.
I’m in India. People spend 2-3 years grinding leetcode questions too. So you can imagine how difficult the tests have become over the past few years and how pointless this whole test is.
The zero sum burnout games many Chinese and Indian students play are also a good example of such a system, and I think it's a positive feature of American culture that it's objected to.
That said, some coding in an interview is pretty much a requirement for any sort of programmer job. If you ever start interviewing candidates yourself you will see why - a non-zero percentage of applicants are very poor programmers, even those that claim years of experience.
doesn't that prove you have experience?
> The no-whiteboard companies are very few, hardly ever seem to have openings and not hiring junior engineers.
Both those statements are false.
There are plenty of places, both small and large, that don't do leetcode interviews. There are places that don't do whiteboard interviews at all; there are far more that do have you go to a whiteboard but don't have you do leetcode there (my own company is such a place).
Personally, I don't grind leetcode at all. I know what I know. If a company wants that, fine; if they don't, I'll work somewhere else. But I am far from junior. For a junior programmer, it may be harder to get the first job, and leetcode may open some doors. But the absence of leetcode doesn't close all doors - far from it.
What we care about is, can you code at all. We give a problem that is a step above FizzBuzz, but not all that far above it. Can you write code that does something like that? Can you think through the problem? It's not a "you have to find the trick" problem at all. We don't care about whether people can find tricks. But can you code at all?
We aren't alone.
But most of them merely pay very well, instead of ZOMGWTF well, and you'll be writing software in probably Java or C# to help out boring but profitable companies, rather than doing flashy startup change-the-world (LOL) stuff while burning VC dollars, or being in the advertising business.
If leetcode is necessary for interviews in your city, train leetcode. DO NOT MEMORIZE. But, do simple exercises and work your way up to harder ones. It is learnable, but memorizing is just about the worst way of learning it. You don't have to burn yourself out either, go by pace easy for you.
Not being good at leetcode is not some kind of helpless unfixable state.
as a fresh college grad, you have to decide whether you want to work at a company that does leetcode interviews. if yes, you have to practice them until you can pass the interview. if no, there are plenty of companies that don't do this style of interview. they just don't get discussed on hacker news as often. unless you are an incredibly well known engineer, there is no third way.