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
If the candidate obviously didn't know what they were doing, we ended it early. Usually you knew within 15 minutes.
One candidate hated the interview process, and walked out. One candidate, likely a future business leader, argued vociferously for a higher hourly rate during the interview, and later with the founder.
But I would describe our success rate for finding good programmers who were easy to work with as "extremely high", and our rate for false positives as "I can't remember ever having one in about 4 years of working there".
The overhead for the engineering team to run these was not zero, and not everybody enjoyed doing it. But some people did, so we had them do it more often. I have no idea why this isn't a more common practice, I would recommend it to anybody.
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.
Sell back to your employer or their competitor. Congrats you've just started your career in coding and you didn't do a single whiteboard riddle I interview. Also your doing real work for real people and making actual differences in day to day lives. Not just some faang companies pleb work, bleeding metrics from the masses.
Learn heapsort, quicksort, how to find medians, how to derandomize and calculate the running time of the quicksort/median algorithms.
Learn how hash tables, red-black trees, and b trees work. Learn why vectors allow O(1) append but only if you amortize the analysis.
Learn depth-first and breadth-first search, learn A*, learn all-pairs-shortest-paths. Learn enough dynamic programming that you could implement a memoize decorator.
All of this is valuable knowledge. It'll pay off to learn this in the long run. Yeah, interviews overrate its importance. It's good to learn it anyway. If you learn that stuff and you are good at the basics of practical programming like string and array manipulation, you'll be able to do well at interviews.
It’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.
At some point I've interviewed for a company who gave me four exercises to solve in an hour. Normally, it would've been impossible to solve them without previous knowledge. Funny part is that I knew the idea for all 4 and the only difficulty was to write things quick enough so I can finish everything in time. 57 minutes later, I was finishing all of them, to the surprise of the interviewers who were watching me coding.
I had the all time best score for that company, and everyone thought of me I am some kind of genius, which was certainly not true, because I know my limits, and I am far from it.
Nevertheless, everyone was a little disappointed by me in the next 6 months. I was quite junior, and had junior problems.
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.
I know it's popular to throw shade on interviewing for "wasting" candidates' time on this instead of "learning to build actual things", but even if DS&A toy problems aren't the best-correlated with actual work performance, the fact is that (a) they're well-enough correlated, by the standards of scalable interview assessments (b) contrary to popular belief around these parts, presenting "actual things" is much easier to bullshit your way through than a few hours of talking through toy problems (c) every job opening gets a deluge of bullshitters.
2-3 months of devoted effort on algorithm interviews has given me some of the best ROI / time for engineering growth I've had in my career.
Consulting jobs require case interviews - they're pale imitations of actual projects that translate loosely at best. And every company uses them.
Trading jobs ask probability questions - they're idealized versions of what traders do all day, requiring tangential (at best) skills like mental math and memorizing niche formulae. And (almost) every trading firm will ask them.
Tech jobs ask leetcode questions - they're vaguely correlated with tech skills (you can't learn leetcode without learning to program, I guess?). And (nearly) every company asks them.
All of these industries put up somewhat-arbitrary filters just to get a manageable signal, however imprecise, on the endless morass of new grads trying to break in. They ask them because they work: the pool of candidates who pass them are of a higher average quality than the pool who fail.
They're biased, arbitrary, and often quite silly. And they've persisted for a half century. Get used to 'em.
Doing so takes the pressure off and helps you to realize that there's a ton of opportunity out there if you want to get to that level.
The truth, though, is to build stuff, practice, and don't stop. I've circumvented most of the gatekeeper stuff because I intentionally hustled freelance/contract work early on and got to a level where I had a portfolio of high-quality work (i.e., leave money on the table short-term to make big money easily long-term). Now if companies turn me down, they look like fools.
Always worth asking: "how do I circumvent the hoops?"
Also (via Derek Sivers):
> “The standard pace is for chumps.” - Kimo Williams
Feel free to email if you want an opportunity to practice/gain experience: ryan.glover@cheatcode.co.
Trying to get a 20% raise by doing a good job I've found to be a protracted difficult task, but a 50% raise by interviewing? Much easier.
You do need some job skills, but in my experience being fired for not being good enough is rare, and can take a lot of time - during which you're getting paid.
Another thing I've found is I pick up the most exposure to new ideas in that first 12 months in a job.
These two things together means being able to get a new job easily is very useful.
But getting a job is different from doing a job, don't expect the two activities to have much in common. It could be better, but hey 3-4 months of evenings spent programming to get a big step up in the job market is a pretty good deal if you enjoy programming :)
(Personally I've found leetcode useful at becoming a better programmer, though I didn't approach it as memorizing riddles.)
My resume is very good. Its a little scary, because this experience is actually common. No one trusts anything, and nothing you have done is worth anything, unless you are well known. You need to study whatever textbook answer they are looking for.
Silicon Valley and its satellites seem to disproportionately favor code interviews compared to the rest of the US market, for some ungodly reason.
So yeah, you can be a competent dancer without this emphasis. But you ain't gonna be a champion without a very solid foundation on your feet, as it all grows out of that.
I've advised college graduates to learn the leetcode stuff. It's foundational for being a champion programmer, and besides, with the $$$$$ that Google pays, it's a very high return on investment of your effort.
It's also easier to just learn it than expend all the effort fighting it. It isn't that hard, either. Just make it your bathroom reader, one puzzle at a time.
SV-tech culture was attractive in the mid-late 90s when new things were actually being built and innovated, but today it seems many are just rent seeking near-monopolists that exist to sell ads. Working for a near-monopolistic advertiser with stupid hiring practices just isn't something I would want to do, or dedicate my life's work to.
If you want to use your talents in a way to make humanity better in some small way, advertising isn't it. I would recommend going into another industry and company that values tech skills, but doesn't cargo cult like SV type companies do. Almost all the code you write will probably matter and be used by people. In my 20+ years of development, I've had a total of one project shelved, and that was due to an M&A.
You have a pretty good chance of creating new products as well rather than just doing maintenance tasks (although you will do plenty of that too). Most SV type companies seem overcrowded and mostly out of ideas, at least significant ones. There are of course exceptions, but like I said, I see a lot of rent-seeking from the big boys.
If you're just into it for the money, SV type companies are probably your best bet, at least for a couple of years until you're financially set. Also, it helps to have at least one big name on your resume. You can earn plenty of money in other industries too.
> 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.
Go for jobs or companies that are not popular and are struggling to find talent. Try to get the highest paying one of those (my subjective experience is that your colleagues will be more professional). A job is what you make of it. If you take a role at a company that puts you through a tough leetcode test you may find yourself editing config files all day because you are surrounded by superstars and there is only so much interesting work to go around.
My first job was at a startup that couldn’t attract the talent that the bigger Corps could. They paid more than the big Corps and I’m pretty sure I learnt a lot more than if I hadn’t taken the risk.
Another approach is to use Meetup events in your chosen tech field to shortcut the hiring process. You chat with someone who works somewhere, they speak to their manager and get you an interview. People that know each other personally are unlikely to put the other person through a leetcode test. It helps to have one or two projects on GitHub that someone can browse through to make sure you are legit. They don’t have to be popular or useful. Just some code that is not terrible.
Second, it sucks but the only way to get better is to practice. I recommend Python since it's the most efficient least verbose option for Leetcode. There are also a lot of shortcuts for learning as efficiently as possible:
Learn and internalize the 14 patterns: https://hackernoon.com/14-patterns-to-ace-any-coding-intervi...
Then practice with either the Blind 75, Neetcode 150, or the Sean Prashad leetcode list: https://seanprashad.com/leetcode-patterns/ There is a lot of overlap between these lists, and most of the problems are slightly more complex versions of a previous problem.
You also need to be able to talk about your solution and explain why something is O(n). Talk out loud to yourself while you are coding, you'll feel like an idiot but it really is helpful.
I know that it sucks but unfortunately this is the price to pay for the insanely high salaries for fresh grads in tech atm. On the plus side I think that Leetcode made me a better programmer in the sense that I became more intimate with the language I chose (Python) and am able to write code more quickly since I unconsciously internalized the syntax.
Lastly when facing rejections, don't take things personally. Luck is a huge factor and if a tech company doesn't want to hire you it has nothing to do with your value as a human. I applied to hundreds of companies and went through about 10 on-sites just to receive one FAANG offer. Keep in mind that on forums like Blind or Reddit, or personal blogs, you are mostly going to be reading stories with high survivorship bias and embellishment. Everyone wants to brag about their six-figure offer from Google, fewer people are going to write about the excruciating toll that hiring practices took on their mental health.
Did I become unhappy b/c of this change? It's arguable. I'm sad that I can't play video games anymore but I'm happy to know that I'm interview ready at any given time, and can exercise my will to attempt to get higher salary jobs at any given time. So it's a give and take.
We don't have to, but we'll have less pool of jobs to choose from.
As for solving leetcode problems; it's just like a riddle. You become better at it the more you do, b/c you start to see a pattern. However, if you choke or don't get a question you solved before (or you solved before but can't remember) , better luck next time.
https://www.naveed.dev/posts/senior-engineer-interviews-brok...
https://www.naveed.dev/posts/leetcode-alternatives-compared
https://www.naveed.dev/posts/alternative-senior-engineer-int...
I even avoid board games for the same reason. OTOH, I enjoy cooking, construction work... manual labor, that is.
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.
This model of operation feels kooky but it does work on various levels (but fails in some also e.g. as panglossian fantasies ). The overall hodgepodge results in SV dominance we see today in many sectors.
Leetcode is self-fulfilling now. It's like a ticket on to the prestige and mega-bucks ride a lot of engineers desire. People pay for the ticket with 3-4 months study. Those that cannot make the time, say due to family circumstances, are actually part of the implicit unfair bias in the system.
I think what works best is when Leetcode is part of the gauntlet but not the whole game. A genuinely good person, in terms of character, together with good programming skills is what I've seen as a company's best asset. An open ended technical focussed discussion on specifically what the engineer has done lifts the lid on that part of things.
first-order: employs them to build something at a lower cost than the market would expect
second-order: convince non-FAANGy companies that you can identify employees who are lower-cost and higher-value, thus starting an evaluation and matching business
third-order: write a business book about evaluating people better than leetcode-like methods
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.
If you are memorizing leetcode you are doing it wrong.
If you are doing more than 60-80 problems, and not applying to the most competitive companies, you are doing it wrong.
There is a strategy to learning how to study leetcode, and yes, studying leetcode is hard. But you need to make sure you are not blindly memorizing solutions or else you're doing it wrong and wasting time.
Let's say you are doing an array problem and there is some trick that is necessary for the problem that you didn't know. When you get the problem wrong, learn what the trick is, but don't "memorize" it. Learn it and learn how it works. Then think deeply on what other problems might use this trick. Does it involve a loop that goes until `i <= someVar.length` ? What happens if you change the code to < instead of <= ? What happens if some other edge case happens?
I've seen this happen with binary search. Someone learns the algorithm by finding the algorithm online in their language of choice, but doesn't spent time fiddling with the code or thinking about edge cases.
My advice is to just vote with your feet and not work for companies that leetcode interview.
You're premise assumes someone who has the safety net to spend time on non-compensated work (which is what leetcode is and is really unfair to poor people, but that's a different discussion). Assuming your premise holds:
- Work on an open source project and contribute to it.
- Work on your own project and publish it
- Get an IT job (which only requires Windows and Mac skills but not programming) and then volunteer for any programming project that comes up (automating the ticket system, automating deployments of equipment, automating basically anything that's manual).
- Find a non-profit that needs a new web app or phone app and volunteer your time building it for them.
Basically, take the time you would be doing leetcode and actually build something public, so that you can take that to an employer and say, "hey I built this".
I thought these hiring managers were insane. I get it now. I think code tests are fine, but timed puzzles just don't tell anyone much about any dev's ability to assemble features out of higher-level tools.
The last 12 years in tech I’ve actively fought back against leetcode and homework coding interviews. Unless you’re going to pay me for my time, I’m not going to work for free.
Someone in a thread said “show them the actual day to day during the interview” is spot on. If you are interviewing and they aren’t doing this, move on. If you are interviewing for your team and aren’t doing this, start.
> I have a personal policy against any type of live coding or online coding tests during interviews and I don't enjoy or engage in any form of competitive programming. Otherwise, I am happy to work offline on coding assignments with reasonable goals and deadlines and to have in-depth technical discussions about software architecture and design as well as relevant technologies.
Yeah, I’m aware that I can easily get away with it given my current CV, but some companies do care about their candidates and adjust their process as needed. As long as we bend backwards and tolerate any abusive practice, nothing will change.
Over the past couple years, I have interviewed at a handful of other startups who also have similar coding interview philosophies.
Also, for system design interviews, they should use stuff like Factorio and Zachtronics games
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.
If you care primarily about your salary, become good at leetcode.
If you don't, join a startup.
although the leetcode hiring model is too often cargo culted by orgs trying to emulate faang this is not representative of the industry at large. if it seems true you may be considering too narrow a slice of it
> What would be your advice be to fresh college graduates, or anybody for that matter, who are good at programming but not at leetcode?
consider applying to roles that don't use the leetcode hiring model
personal anecdote:
first job out of undergrad, small shop whose software you probably haven't heard of but have almost definitely interacted with if you live in the US: phone screening, remote technical session with 2 hours (own time) to write 3 functions, on-site interview given a laptop, an hour, and instructions to write a toy API then asked a few questions about solution and general concepts
second job, cold emailed a professor asking about openings for a programmer/research software developer, asked to clone and build a project repo and sketch a simple (<1 hour) feature
third job, also research software, online application, 1 hour video interview, entirely qualitative, no coding component, having work from the previous role on Github likely obviated the need for a technical session
I'm not a great leetcoder, I reason fairly slowly, I struggle under time pressure and observation
if you're like me, play to your strengths, you're still competent and you can find work
Leetcode problems aren't that difficult and if you can't solve them, your coding skills are weak. Not surprising since you are fresh out of college and still have massive amounts of knowledge to learn.
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.
Yes, leetcode questions are a part of the process, and are often an early gate. However, one can perform “badly” but still score sufficiently well on the non-obvious metrics and make it through. Most interviewers don’t actually care if you have the standard libs memorized, and get that. You typically have a lot of leeway to demonstrate your knowledge, and staying open about what you’re thinking and doing goes a long way.
If you have sway in how your company interviews, consider being clear with candidates on all the dimensions they are being eval’d on, maybe let candidates choose take home assignments, ask candidates about projects they have worked on, etc. as part of the process.
I'll get downvoted for this but... There's no such thing as "leetcode/hackerrank" interviews. It's simply using questions that will be familiar to any candidate who took a serious algorithm and data structure class [0]. Any serious engineering/computer science degree should have at least one. If you can figure out algorithms, you should be ok figuring out how we built our back-end in whatever language, as the fundamentals (the underlying algorithms and data structures) will be evident.
If you're just hiring programmers, don't expect them to be familiar with those concepts. But any serious engineer will and should.
[0] https://ocw.mit.edu/courses/6-006-introduction-to-algorithms...
People argue that we should make interviews more relevant to the actual work you do on the job. But in practice it looks a lot like we're really just trying to pass more people. Half the new "practical" questions are literally like make an http call, iterate through the array of objects and do some basic data transformation using map and filter. Or something. The actual thinking part is usually about leetcode easy, maybe low medium.
Seriously, any time I see a "modern" non-leetcode interview I basically start rehearsing salary negotiations in my head. I suppose you could argue that's all that's needed to do 90% of modern software development, and so the new questions are measuring the right thing... but then doesn't that just indicate that modern software development is a joke and the job is not actually hiring developers to do anything difficult?
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.
I disagree with this, with a disclaimer that I enjoyed competitive programming since before I knew of leetcode's existence.
That said, salaries for SWEs are increasingly becoming bimodal. You can have a fulfilling career without having to do Leetcode-style interviews. Or you can have a go at grinding Leetcode for a few weeks and have a higher salary for the rest od your career - a much greater RoI than a 4-year degree, IMO. Framed differently: would you grind leetcode for $100,000?[1] How about for $100,000 every year going forward?
There are no wrong answers, for some, the answer is "no", and they have my respect.
1. Assuming you're in the US and aiming for FAANG/FAANG-adjucent employers; adjust this figure for your circumstances.
I do believe having someone do paid work / pair with the team for a few days is likely the most valuable, and I do actually think the best people are ok with this because they use it as a way to evaluate a company. But this strategy simply isn't scalable and can take a lot of company man hours without extremely good up front vetting.
I've found coding exercises, of some sort, they don't have to be leet-code-esque, to be one of the very few "put your money where your mouth is" activities to perform. The amount of folks that can speak forever and in-depth about what they've worked on, and then will completely fail at writing for-loops in their favorite language has astonished me. I don't believe live coding exercises have to be adversarial, I believe candidates should be offered a more accessible often if it's too high pressure for them, but I don't believe coding exercises are inherently bad or evil. I do believe there are bad or evil exercises that can be chosen.
A practical coding exercise that requires no more than 8-10 lines of code done live has generally served well in my experience for assessing candidates. I've seen similar pure failure rates from practical exercises as I have from "perform a dfs" style exercises, in the above 60% range.
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.
Obviously, that's not exactly an easy route, but anyway.
We don't challenge this enough in the industry.
If your interviewer was interviewing a candidate who was a prolific software author who published works that had mass adoption, 9 out of 10 of them would be nonplussed by it, and it's so stupid.
I still don’t feel ready.
If you’re curious: https://www.github.com/glouw/rr
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).
We have so far had one person get all the answers in the allotted time, without any help, and he is working on his second PHD.
Go to meet-ups, join mailing lists/discords, network. Get hired for minimum wage on very small projects (but make sure somebody pays the taxes). Add them to your resume. Get contracting gigs (contractors rarely have to pass the scrutiny full-timers do). Join a startup.
FAANG may not hire you on these alone, but I would, and so would many others. We want to see that you can build something, and we want to see you have made lots of mistakes and learned lots of lessons. After you have proven yourself, you don't need to do leetcode. Then you just have to worry about the rest of the interview...
If they think this isn't OK even with me understanding this need and communicating about it upfront, then it's probably not a good fit anyways.
most common day to day tasks have solutions or best practices. So you're looking for someone with the the foundation skillset and right mentality to do the job.
I think leetcode is comes from the ivy league elitism culture of faang. also a lot of nerds are deeply insecure and like to show what they know or tell others what they don't know smugly. just look at the "show hn" posts and the type of comments your get there eviscerating some noobs hobby project.
Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.”
Leetcode questions are a useful measurement in the interview process
What they are not is a useful goal to hire someone by.
https://ramp.com/careers or hit me up nico@ramp.com
There is nothing to be gained from them. Candidates waste time trying to solve problems that may never face in a real work environment. Companies end up hiring people who has prepared for the interview, not for the job. Even worse, some companies seem to have standardised the same useless process across many levels, and end up asking senior candidates to e.g. reverse a binary tree.
Personally, never in ten years has a code assessment helped me choose the right candidate.
i then took an interview with another FAANG. i was asked to solve this exact problem and it was clear i was supposed to do so within 3 minutes or so. this just illustrates how horribly broken the process is.
it’s infuriating how this woman lobbied herself onto the hiring committee and essentially created a broken process that disregards any experience gained and optimizes for those willing to memorize optimal solutions.
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.
What those programmers have been doing is gluing code from StackOverflow to create UIs. Just look at development in React. There's no thinking involved whatsoever. Just navigate to Redux copy-paste code and remember what it does to create a glued up pile of shit. Npm install 100 packages and you are good to go.
I don't know of any decent engineer who's good at problem solving that would struggle with LC easies which are the most common types of problems asked. I mean, how could they it's just basic logic and looping.
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.
Not really sure what to do in my situation either. I know it's different from ops but I thought of it as sort of a corrolary.
Lots of options for improving, but I suggest if you're feeling stuck to pay for a coach.
Also, stop focusing on FAANG type companies. There are tens, if not hundreds, of thousands of jobs, and if you're a new grad you're as mobile as you'll ever be. There are too many jobs to care about specific hiring trends; there'll be a job for you out there somewhere.
>homebrew creator / inverting a binary tree
This is just a traversal of a binary tree + swapping two variables. I would expect any good programmer tqso be able to do both of these things.
They're judging you on your 1337-coding skillz.
It's ok to judge them on their poor judgement. And seek employment elsewhere.
You can even be more helpful than most employers are to job candidates. Tell them that's why you're not interested. Maybe they'll learn from it. Maybe.
It's okay if instead of doing a medium problem in 15 minutes it takes you 4 hours at first. Start solving and make a habit of doing 1-2 problems per day. In no time you're going to learn that the problems are doable and the time it takes to do a problem will go down a lot. When you can do an easy in 10 minutes and a medium in 15-20 min you're ready. I have rarely seen hard questions in an interview.
Also the more senior you are, the more the emphasis is going to be on system design and behavioural.
Yes, it's stupid. It is what it is. You know what is going to happen, you prepare for it, you get the job.
Were all of your college classes relevant to your career ?
Get better at leetcode - it’s a learned skill, if you can pass college CS you can pass leetcode
I think no-whiteboard companies correlate pretty heavily with ‘good place to work’, ergo, they’re not looking for people as often as revolving door companies.
“here is the many thousands of lines of code in my various GitHub accounts, don’t like the code, don’t hire me”
Do I learn enough in leetcode? Do I get anything valuable (outside of skills/practice) out of it?
IDK
This is a gross over exaggeration.
I'd say about 50-60% of companies do a programming test.
Others are happy to look at your open source code and discuss it with you. They might pepper you with some programming language trivia questions.
That has been my experience.
I just want to add that I 100% agree with OP: many companies put too much into LeetCode type testing and interviewing.
I have been a web developer - so not advanced in algorithms or LeetCode type stuff to begin with - for the past 13+ years. in 2021 I resigned from my employer due to burn out, took 10 months off, and started looking for an employer again.
Many interviews for "web developers" and "wordpress developers" required me to take a LeetCode type test, which I bombed repeatedly. One company I really wanted to work for asked me to retake the test in 30 days. I spent the next 30 days in the pockets of time I found available trying to go through LeetCode challenges and wrap my mind around these algorithms. Many times I could "solve" the problem my way with my own experience and knowledge, but not LeetCode's way, so my scores were poor.
Fast forward 30 days, I retook the potential employer's test, and got a 14%...they advised I should re-apply again for 2 years. LOL. It was so comical I had to email them that the process didn't allow me to display my 13 years of experience at all, and the testing challenges in no way reflected what I knew as a web developer.
In the end I took a different position for a vastly greater salary than they were offering.
Managers aren't some kind of stale guy but predators who sucks slaves' blood. They actually know what they're doing, they're sending a powerful messages that they have power to order subordinate dumb things, like memorising riddles.
My advice as someone who doesn’t accept these kinds of interviews on principal - and has repeatedly payed the price for my insolence - you have three choices: accept and do it, work around it, or something I don’t know about.
I work around it.
My life isn’t special, no one cares what I have to say, and no book will ever be written about me, but I get to build great software everyday and I am happy.
In not so many words, you have to optimize for what you really want.
- Do you just want to build software?
- Do you want to have a lot of money?
- Do you need access to a quantum computer?
- Do you want to live your life learning new things, or focus only on one thing?
- Maybe build your own business?
- Do you want to buy and sell people like cattle?
If you’ve got that right in your head, and you don’t want to play the game I’ve found the gigs outside of the valley/US to be more often about doing work than about status and position. It’s less about the “difficult hiring process as a badge of honour” BS, and more about building things. I mean, Ex-fannG people are out here too so you still run into it from time to time.
So, TL;DR, maybe look at the world as an option instead of narrowing in on the typical valley/FANNG path.
Our company, which is service and tech based (GIS) has about eight full-time developers among 400 or so employees and we're doing cross platform mobile development and some web and some server applications and plugins.
When we interview, we usually do a phone interview with basic questions ("Explain inheritance" or "What's the difference between abstract and virtual"). It's weird, but a lot of people either panic or don't prepare. Missing things like this isn't a deal breaker, but we want to see the thought process.
If that goes well, we do an in-person interview and tell the candidate to schedule at least a half day (or sometimes a full day). We introduce them around, chat, do a more formal interview, and then do a coding test that we concocted. Basically, it's pieces of our app and a list of like 10 things to accomplish, like "Make it compile and run" (usually there's a syntax error or two and we want to see how people use the IDE and tools) or "Add a label to the page or app that shows the current time" or "Fix the alignment of the buttons on the left side" (for web). They get progressively harder and we've only had one person complete them all on time (we hired him, naturally). We've also had candidates completely choke and not even know where to start (you are free to ask questions and look up things online - totally open book, as if you were working and had a list of tasks to work on). There aren't any tricky problems. The harder ones require a little domain knowledge in GIS (which isn't a requirement), but can be figured out with Google (or by simply asking us how to do something - it's kind of a joke that NO ONE ever asks). You're not watched, but we check in every once in while to see how it's going.
We eliminate quite a few resumes, and eliminate others after the phone interview, but for those who make it to the in-person interview, we've eventually made offers to about 50% of them. And we've had great success in getting people who can do the job and excel, which you have to do with such a small team.
We do look for github projects, open source projects, and any sample code you can share. We also like people who have completed successful individual projects, written on subjects, and we love it when candidates actually have domain experience, but, as I said, that's not required.
My favorite interview question is "Tell me about a project, personal, school, or professional, that you are proudest of. Preferably something that presented a challenge you figured out." I like for interviewees to relax and geek out a bit. I honestly want to know if they enjoy coding, designing, and learning or if they're just looking for a paycheck or stepping stone (not that there's anything wrong with that, but I don't want to feel like we're paying someone to do something they're not the least bit interested in).
It's just a simple filter with the usual caveats of false positives and false negatives.
What is the group of customers for your labor output that will never put you through a test?
Hint, other beginning developers.
If you think leetcode is the worst part of being in this workforce - you live one incredibly privileged life. Wait until you have to deal with toxic management that exists in virtually every company and in virtually every leadership position. Wait until you have to deal with people who have a personal vendetta against you because of prejudice and will block any achievements you can make at a company. Are you excited for stack ranking? It exists at nearly every company and if it doesn't explicitly - it happens mentally. Are you excited to see incredibly huge churn in your industry? Are you excited to see the best and brightest constantly shutdown due to favoritism (and you will likely not be in that in-group)? Are you excited to watch people over the years lose all their hope and become soulless corporate ghouls who become the shill LinkedIn promoters that they themselves condemned a few years previously? Are you excited to work 60+ hour weeks to get PIP'd because that's just the way it is? (It will happen) Are you excited to put nights and weekends in at startups to see a round where the execs lose no value but your stock sees 3x+ dilution and no increase in value?
These are common problems at companies within SV. Leetcode is hardly a problem when you see how fucking terrible the rest is.