Don’t want to do Leetcode? Me neither — after I left Airbnb I vowed to not work at any company that asks this kind of question. I interviewed at a bunch of interesting companies (Airtable, Brex, Eaze, Figma, Lob, Notion, ...) none of which asked this kind of algo brain teaser question. There are tons of places out there with great product, interesting problems, and good compensation - so if you hate this bullshit, don’t give up.
I interview candidates every day, and my impression is that a candidate from FAANG/leetcode company is no better or worse than any other candidate.
Anywho, I’m hiring for a bunch of roles - full stack, Android, infra, SRE, early career, etc - if you’re interested in Notion (https://www.notion.so/careers) ping me on Twitter @jitl.
I'm just gonna glom on to this for visibility, but I'd like to say I wish there was a good list of companies that don't do leetcode-style interviews.
Frankly, I'm sick of leetcode, and I feel like it takes a lot of fun out of working in tech to have to grind this skill that's completely unrelated to any sort of real work. (Rant mode off)
Anybody know of such a list?
Edit: I should add that I'd really like to be pointed toward companies that use a structured interview process. Literally fewer than 1 in 10 SF tech companies seems to have any idea what they're doing when it comes to interviewing, and a structured interview process goes a long way toward fixing that deficiency.
I'm familiar with the "hiring without whiteboards" list, and that does't seem to be quite what I'm looking for.
Do you want companies that don't do leetcode, or companies that don't do leetcode yet pay you a FANG salary? The list of companies that don't do leetcode are probably quite long, but you're looking at an average salary in an average town(i.e. $120-180k/year salary with decent benefits and meager stock opportunities). There's nothing wrong with that. I'd certainly go that route if I could afford to. If you're looking at making above average pay, you'll probably have to jump through those hoops though.
For what it's worth, as an "embedded guy" who went into programming with a EE degree and no algorithm experience, I used to loathe the leetcode dance. After working at a FANG where I actually needed to know some of that stuff, I now don't see it as pure evil. Sure, it's a bit overboard, but some of the problems you'll encounter at some of these companies really do require a level of competence and dedication that is something I rarely encountered in 20 years outside the valley. Maybe it's the particular company I ended up at, but I am working with some insanely smart and dedicated folks. I definitely do not belong among them but it's certainly been a learning experience and something I'm thankful for.
I'm totally fine going the "average" route. At my last company, I was making around $225k TC, and that worked just fine for me. At that level, I'm making enough money put back a considerable amount for savings and investment, while not living in a tiny hovel, and even enjoying an expensive hobby or two. My ideal job would probably be the lowest stress job that I could make at least that much, to be honest.
But, of course, it's just me that I'm looking out for here. I don't have a wife and family to provide for. I'm sure I'd be writing a different comment if I did.
Android, iOS, and front-end interview tracks tend to be more “hands on” even at companies that use leetcode/algo questions for full stack or backend roles. Airbnb pays very competitively (compare to Google and Facebook https://www.levels.fyi/SE/Airbnb/Google/Facebook) and is lighter on the algo stuff for the specialties I mentioned.
That would be fabulous if I knew the least little bit about any of those things. :-) I've done a lot of backend and data engineering. Occasionally that's enough to get me considered for a full stack role, but not often, and that's the furthest out of my lane I've been.
I've created a website - https://sievejobs.com - to allow job seekers to hard-filter out companies with this sort of interview process, and also to quantify to hiring companies exactly how many job seekers they're missing out on.
(The site treats other job elements similarly: open seating plans, remote-ness, etc.)
In the past decade I have politely declined to answer leetcode style questions in interviews. I’ll offer to discuss how to solve coding problems in general terms, and I’ll happily whiteboard diagram solutions, but I will not code on a whiteboard or on a computer set up for the purpose in an interview.
While interviewers are initially surprised at my unwillingness to answer such questions, it often starts a short discussion about interview practices, and my observations about fantastic high-performing colleagues who have been passed over because they failed at interview coding challenges.
Thus far I haven’t lost an opportunity by declining to do coding exercises. In contrast, the couple of times I’ve played the leetcode game, I’ve lost the opportunity despite doing very well in the other interview phases.
I realize I have an advantage of being in this business for 30 years, having a lengthy and robust CV, and having been a hiring manager who can talk about my own experiences of being the interviewer rather than the interviewee.
Wow, that job ad (early career) looks awesome! Do you hire from Europe / The Netherlands?
With every single thing that I'm reading I'm agreeing and/or have some experience with it. The most fun example: the background of my thesis touches on Engelbart! What a visionary he was.
It seems to me that having tough interview questions can allow a company to be less credentialist, because they know their questions are tough enough that anyone who solves them is qualified to work there. My resume doesn't necessarily make me look like a senior developer, but leetcode mediums are no trouble for me and with a little effort I think I could learn to solve hards quickly and reliably as well. So I've got a comparative advantage applying at a company that has that sort of interview.
I say this as a happy Notion customer who spends a lot of time evangelising it within my own company: Notion is one of the most unpleasantly slow apps I have to use in my daily work, it has been the same way for years, and I can't help but think that a deeper appreciation of computer science fundamentals _might_ possibly help find better ways to fix that.
When I look at the performance of many pieces of software produced by FAANG companies and other big players known for basically bringing us the "leetcode interview meta" I really doubt the strongest connection can be made in that regard.
Probably not that bad these days, although it depends on your content and workflow. I _enjoy_ Notion more, and for what it's worth I do actually trust Notion to give more a shit about it than Atlassian, but it's still the most common complaint I get from teams. Trello is certainly vastly snappier than both (as is a Google Spreadsheet, which is many users' go-to solution for any type of even vaguely structured data).
I read the guide to engineering interviews you posted, but I am curious about the difference between your "Technical Screen" and leetcode type questions. Having to solve a problem while someone is watching and having to talk while you do it sounds similar to the FAANG style. Maybe I'm missing something?
> Please prepare a skeleton web application, using any web server framework you like, preferably a lightweight one, e.g. express (node), flask (python), sinatra (ruby).
> Have a tool to send payloads to your server and inspect responses, for example cURL or Postman. No front-end client is required other than cURL or Postman to send test requests. This will be a backend only exercise.
This is a far cry from leetcode stuff - these are real world tools and concepts many developers use every day. Yes, it is an interview with time pressure, talking, and problem solving. But, the tools and problem are much closer to web development than they are to a CS51 graph proof.
Hmm I don't see the quoted text in the guide. Maybe it's something different internally?
The page I see only says there's a 60min "language-agnostic coding exercise" and that you have to share your screen and talk through your thought process. That's why it felt similar to leetcode stuff.
LeetCode is a problem that took a famous computer scientist a month to write a paper about, but you have 30 minutes in a proprietary web app to either remember or re-invent it, and pass a test suite.
LeetCode-type interviews are about 60% a how-bad-do-you-want-this test, and 40% a barely-concealed IQ test.
I'm not even sure that's the wrong way for FAANG to do things, given how many people want to work there. I do know it's a damn bad idea for any place not offering FAANG-like comp, since at lower comp levels you're in competition with a ton of places that don't demand hours of grinding leetcode to prove you want the job bad enough.
I used to spend whole interview working on actual problems candidate will face on day-to-day. When hiring for back-end roles I had a few scripts I used to use to see how candidate does code review, or had an EC2 instance with specific problem simulated so candidate could look around and talk about what they see and how would they approach the problem at hand. I only gave algorithm problems to juniors who claimed they can code.
You really need to decide in advance what you want to get out of LeetCode. It has a lot to give.
For example, some LeetCode questions are textbook problems. You really should familiarize yourself with them, but you will probably never see them verbatim on an interview. Other LeetCode questions are too tedious or time-consuming to do on a whiteboard in an hour. You will also not see them on an interview. For some people they can be fun brain-teasers, but if what you want from LeetCode is time-efficient prep material, you need to be able to tell apart these three kinds of questions.
If you look at comments on LeetCode questions, you will immediately discover that tons of people treat LeetCode as a pissing contest for its own sake. Should it matter that your solution runs in 18 milliseconds and theirs runs in 15? Or that they code-golfed theirs into 200 characters? Probably not. On the other hand, most canonical problems do have canonical solutions, and you should probably know what they are.
Knowing what to take from LeetCode and what to leave is almost its own discipline.
> Other LeetCode questions are too tedious or time-consuming to do on a whiteboard in an hour.
Afaik all leetcode problems are from contest where thousands of ppl solve 4 in 1 hr. Its unlikely that there are questions which cannot be solved in 1 hr whiteboard.
No, I stand by my claim that many LeetCode problems are too time-consuming or tedious to be effective whiteboard interview questions.
It should be noted that whiteboard interviews are slightly similar, but not identical to IOI and other coding competitions. An IOI problem is not necessarily an effective interview question.
I think a lot of people lump leetcode questions into one thing, when it can be as many things as one would like it to be. I like to do the easy questions to familiarize myself with a new language.
There are certain questions that are math questions disguised as programming questions. I like to do those when I feel like brushing up my math knowledge.
There are questions that test your knowledge on data structures. I like to do those if I want to learn that.
There are questions that test your knowledge on algorithms.
And there are questions that combine some or all of the above.
How one uses leetcode or leetcode style questions is up to them. I think exploring the extremes of possible answers for the questions is a completely fine way to spend your time. And I also think there are several questions on leetcode that should be no where near an interview. But people aren't perfect and you often see those questions misapplied in an attempt to gauge skill.
It's worth checking out the other links/blogs on this site. I read a lot of complaining about Leetcode, most of which I think is valid. That said, something that's not discussed often is its effect on interviewee's mental health.
I used to admin a large Discord server for junior software job hunters. It's pretty insane how many struggle from anxiety and stress directly caused by the interview formats popularized by Leetcode. The author here makes a pretty good point, honestly:
>Leetcode is a competitive programming platform at its core, not an interview platform.
I think this is where a lot of the stress comes from. Like the author, I mostly avoided Leetcode and focused on fundamentals (literally reading CLRS and implementing foundational algorithms).
I've recently been thinking about this a lot. The single highest-leverage action I've found for myself has been to shift my goal from:
A. (destination) I need to get a top-tier job at a FAANG company.
to
B. (process) I want to develop my ability to think structurally, so that I can enjoy spending time with code by honing an intuitive sense of the pattern language of code.
The former is future-oriented, stressful, feels overwhelming, triggers Imposter Syndrome and a sense of dread like crazy, etc. The latter is fun, joyful, centered in the present moment.
It's much more motivating and rewarding to get excited about developing a meta-skill than it is to try to hit your target total problem/contest numbers and then run a completely separate gauntlet of interviews after that.
If you want to be an Olympic athlete, you don't start from "I have to make these times, so that I can put myself in the highest pressure contest in the world." You start from "Man, I just really love (running|swimming|etc.)"
I like the mental shift that focusing on process entails.
For your process goal, do you have a list of activities or tasks you do for that?
Here are some of mine, although I’m unsure of relative ROI’s (maybe “return on investment” is antithetical to the process goal lol):
- Read well-established repos and type the code, for example, I’m currently going through all of the React source and typing everything up as I read it
- Add research comments and questions as I retype code, eg ‘// What is React Fiber?’
- Use typing.io to increase my typing speed
- Use anki to memorize the most important API’s (this helped me learn Sequelize and GQL really fast)
I might want to incorporate more “do it myself” projects, but I think my main focus is really grasping best practices and being able to scaffold my solutions with ideas from code I’ve already seen. I think that helps me focus on the logic of my solutions, and helps minimize bad “cowboy code” habits.
Honestly, just spending time reading through any good code, well-maintained repos, official CTCI solutions, other people's LeetCode/CodeWars solutions, etc.
(The absolute best way I've found to learn a language's conventions and best practices is to study all of the community solutions on CodeWars)
Then I have a list to which I add any "code tropes" (i.e. using a loop to search a collection and conditionally flip a flag outside of the loop, etc.) or useful patterns (favoring early returns, etc.). This turns into a dictionary of the vocabulary of code that I just keep adding to.
Mainly it's the act of careful, patient reading that unconsciously develops your sense of conventions and ability to visualize abstraction.
- Read well-established repos and type the code, for example, I’m currently going through all of the React source and typing everything up as I read it
How is this useful at all? If you want to learn you should actually start contributing to a project and get feedback that way. You don’t learn how to do math problems by copying solutions.
The point for me is that it makes my reading more active. I also get a physical feel for code style. If I was just reading source code, it would be a lot easier to skim over things without letting them cook in my brain from a bit.
I do this as well, I think the idea that code is physical is underrated. We've evolved to intuitively understand physical things; physicalizing something so abstract seems like a natural way to understand it.
I think there are two learning styles, one is to learn by doing, filling in the gaps as you go. The other is to front load information first and then apply it by doing.
For me, I learn the most by getting a broad overview of the material first, understanding how other people have used it, etc. then applying it myself.
For copying code, I actually do this to get a feel for a new language. An analogy might be to carefully watch Tiger Woods swing a golf club, then replicate the motion yourself to build muscle memory for the swing, then go out to the driving range and hit balls yourself.
> We don't realize something important - Leetcode is a competitive programming platform at its core, not an interview platform. Yet, we fall into the trap of thinking it's an educational website.
There is a word circling China's Internet call "内卷", which can be translated directly to Involution, but on the ground it actually means "Over competition" or "Doing zero-sum competition". People trying to climb over the others while preventing others from climb over them, so they created many arbitrary obstacles to block others.
Keep in mind that, in Chinese society, 35 years old is equals to 70 years old (In many places, you cannot even get a gov job if you are over 35). Failing a competition can be really, life-changingly costly.
So, it is rather a "standard practice" for Chinese companies to keep throwing LeetCode questions to the interviewee during a job interview (, after all, many of those questions are marked by LeetCode as "Interview Questions"). This method creates a lot of benefits for the interviewer not only for the interview, but also for later negotiations.
Funny thing is, even though the top dogs in China got the best talented engineers in the entire nation, their public-facing products are still nothing but trash (or even fruaddy). And as for those engineers, many of them has their own big dreams, but they cannot realize it because the market is a highly restricted blood sea.
>Funny thing is, even though the top dogs in China got the best talented engineers in the entire nation, their public-facing products are still nothing but trash (or even fruaddy). And as for those engineers, many of them has their own big dreams, but they cannot realize it because the market is a highly restricted blood sea.
How so? when it comes to scale they easily compete with FAANG, don't they?
Someone just released a product that offloads Chrome to the cloud. Gmail has a very long loading screen. Hangouts was replaced by something like 4 incompatible apps. Android phones are significantly less power efficient than iPhones. YouTube copyright notices are trivial to game.
Google’s software over the past 10 years or so leaves a lot to be desired and they’re the worst offender for filtering by leetcode-style interviews.
Do you know about the 1point3acrea forum for LeetCode-based interview preparation. I was told by a friend to check it out as they have an extensive set of tips, tricks and general suggestions. Their forums and posts seem to be mostly in Mandarin and Google translate doesn't take you far. So I was hoping to get some Chinese tech person's opinion on 1p3a.
Sorry, couldn't help you there. The website is titled "北美最有影响力的华人社区 (The most influential Chinese (online) community in South America)", which is little less than half-earth away from me, so..
However, if an interview is really LeetCode-based, I'd say it's a fair game for the interviewee to do some preparation. In my opinion, the best kind of interview is based on real production needs, the interview question (regardless whether or not it's came from LeetCode) should reflect that.
If you don't possess advanced understanding of Chinese, then don't even think about trying to read it. I came to Canada in my teens and I often have trouble understanding. The forum rules dictate that you write cryptically. But it is incredibly useful if you understand it imo, especially the interview experiences. That's why they can charge like 80usd per month for VIP access..
It's a little more on the nose. I just checked the subforum for a random quant firm and it goes something like:
* Just interviewed at {firm}, here are the questions:
1. Question One: here are the math and stats subquestions.
2. Question Two: here is the Leetcode question they asked.
3. Question Three: here is another question and my solution.
4. ...
Followed by other users posting stuff like "Thank you Landlord {OP}" or "Giving rice {forum clout points} to this Landlord {OP}." Guests without accounts are tourists. I'd say it's like the Leetcode discussion forums except they're leaking actual company interview questions.
There was a Twitter thread making the rounds a while back in which someone claimed insiders (existing employees, especially if they're able to develop a significant social circle in them) in big tech companies do the same thing: when they job hunt, they'll hit their low-priority prospects first, have others with inverted priorities do the opposite, then all parties concerned with have very recent test question lists from their, say, top 2 preferred employers, by the time they interview there.
This insiders-have-a-large-advantage factor may be at least part of why the practices survive. People without a friend & colleague network frequently interviewing at those places have a strong disadvantage... unless they hire people to scout for them, which the Twitter poster also claimed is a thing that happens.
I wonder ten years from now how common LeetCode like interviews are. These types of interviews favor those who have the luxury of ample time to prep for difficult interviews and aren’t representative of most daily working environments. This process fails to consider candidates that would be good fits. When I help with interviews, I place much more values on communication skills, teamwork, mentorship, and a general passion for technology.
These types of interviews favor those who have the luxury of ample time to prep for difficult interviews...
Interviews that test for anything that isn't directly related to the job the candidate will be doing are essentially codified discrimination - the expectation that someone will have a skill or significant knowledge outside of the job itself is effectively a way to filter out candidates based on arbitrary criteria even if they are capable of doing the work.
In other words, Leetcode interviews favoring people with lots of spare time is by design, because that's who companies that use Leetcode want to hire. There is little reason to believe that will change.
That's one way of looking at it. But there's also another side of it: this type of interviews let you change career path.
Imagine that you're run-of-the-mill java programmer, but you'd like to dive into Machine Learning, or BlockChain, or whatever. Some companies will require you to have 3 years of previous experience before considering you for such job. Others will give you a Leetcode interview to ensure that you're smart, and then let you learn the actual tech stack on the job.
Also, Leetcode problems might be removed from everyday development work, but most of us did learn those things at some point, i.e. in college, so asking them in the interview kind of makes sense, it's kind of "common denominator" for all programmers.
That is wishful thinking in most cases, because unless you are targeting a startup without ageism agenda, unless the techonology is listed as something that you actually worked on (side projects don't count), the CV won't survive HR review.
Nobody obliged to give you work. They gave you a task and you couldn't solve it, fair and square.
I can stretch your logic even further that giving BE task to FE person is a discrimination because they don't have luxury to work on BE. Why do we discriminate against QA people who don't have luxury to work on dev jobs? Why do we discriminate against people who don't work as developers at all?
Asking someone whether or not they can do the job isn't discrimination. Asking someone if they know something basically unrelated to the job might well be. It could be designed to filter out people who wouldn't know that thing rather than filter in people who'd be better at the job. What is that if it isn't discrimination?
Hiring is hard. It takes serious effort to interview someone and (i) get enough confidence in them to make an offer and (ii) make them want to accept the offer.
LeetCode seems to have become accepted by candidates as a way to do (1), leaving the interviewer more time for (2).
At least, that how I assume people think it works. In reality, hiring is just hard, and if you lean too hard on shortcuts like LeetCode, you come across as lazy, and you end up hiring LeetCode assholes who you catch doing LeetCode during work hours "to stay sharp". One of the most useless team members I ever worked with was good at code challenges but terrible at real work because he didn't care. He wasn't invested in working on the actual problems we faced as a company or as a team.
When we had an opening for an infrastructure engineer I created a handful of gitlab projects (terraform, puppet, python) and put some effort into building some baseline infrastructure. I allowed the candidate to choose one to work on, and then gave them a real world challenge. Not some tricksy bullshit to catch them out, just a realistic task they might encounter. They were given access to an environment where they could run the code. So at the end, I had a runnable merge request to review. Why? Because, to me, the purpose of a code challenge isn't to find the top 10%, it's to weed out the bullshitters. The rest is about figuring out what makes them tick, whether or not they're a good personality fit etc.
It's not that different than lawyers needing to take the Bar exam (have to study on your own, and not all of it covered in school), or doctors having to pass boards. In both those fields practitioners spend a lot of time outside of "work" preparing.
There will always be some sort of arbitrary selection screen as long as there are more people who want these high paying jobs than there are actual high paying jobs.
I really don't know but isnt the bar generally the same types of questions every year? Like the SAT? It feels like preping for interviews is hard in part because you could be asked anything from reverse a doubly linked list to design facebook. If it was a smaller set of questions it would be a lot easier to study for.
Don't count on it going away ever. The programming languages/frameworks landscape is set to explode. It won't be possible to hire people based on experience with you specific languages and frameworks. The only equaliser is core knowledge - algos, data structures, OSes and design.
I do not think they are going away. They are a filter some like to use.
I personally use a dead simple 'leetcode' style program because I want to see they have the basics and can communicate them. I have had to filter more than a few people just because of that. If you can not handle some simple if's and for loops you are in for some real trouble later on. Sometimes they will come in and bust on through it quickly. Which actually helps me decide. Because I can then say 'oh you got through that semi quickly which site/book did you learn from?' That opens up what they know and gives me a good handle on how they are technically. I can then move quickly on to 'let them brag about previous work'. That shows if they were passionate for or was it just a job to grind out. Some cases it matters others not so much. If they come in and really give it a good try but struggle a bit and can say why I may recommend making them a bit more junior and pairing them with someone.
I also do not see it going away. I recently proctored some classes in my org. By the time the 'class' was done most had not bothered to even do 1 or 2 chapters. It was mostly just watching a 20-30 min video with whatever level of homework you wanted. I watched many of them for a few months after. The ones who bashed it all out were ones who tended to be tech leads and suggesting better things to happen.
1. You seem to think that your interview version of basic concept of 'simple ifs and for loops' is the base tier of programming. It's not man, everyone has their blindspots and you are selecting for candidates who are most similar to you.
2. You display hubris in your skills test by assuming that people who can brag the most are somehow more qualified than those who are more humble. Protip, people who code outside of work are not better developers. They are just enterained by their work skills in their personal time.
3. You display immense superiority claiming that your 'class' could not achieve what you wanted them to achieve. You attach meaning to this result. Not many people really want to study at work.
1. it is the base. If you can not do that you have more learning to do. I have seen many fail it. I am nice about it but they just need more training. Most of they type of code they will be writing is little more than enterprise glue code. It is not that complex but it takes a bit of logic skill and base coding skills to do. It can help me help them with what sort of training they need.
2. The interview is not about the code. I want to see them in action and see how personable they are (a grump/huckster will ruin a team). I usually have very little time with them so the test has to be simple (something someone who is semi competent can do in 10 mins). That they are studying outside shows they are at least willing to do the work (and a bonus and helps shortcut many things). Learning to do things is usually part of the job. I do not expect them to do it outside of work. But it shows passion if they do (which is not a bad thing but is sometimes needed to grind out more glue code). I am usually more interested in what they used to work on and can they describe what they did. I do not even really care what the thing is. I want them to explain it to me. Explaining what is going on is part of the job many times. As in 'hey so and so wants a powerpoint presentation of what you have been working on for the past 3 months'. Some are good at it many are terrible at it. I am not looking for slick presenters but people who understand what is going on and show that they can do it. Interviews are about time management too. So you have usually 40-70 mins to decide if someone is worth it. You have to divvy up that time into chunks. That is on the interviewer. I usually spend the first few mins just trying to calm the person down. Then the next few with a semi simple test and explanation. The rest of the time is them showing off and hopefully asking questions about the job (not all do). Them not interviewing me shows something too.
3. The whole class was voluntary. I could have snapped the whip and made them do it. But that was not the point of the class. It was to be a group thing where we learned from each other. It was up front that you can do this on the clock or off. It was up to them. It was very free form. I do not think it was too much to ask them to watch some training videos for a framework they were going to soon be using? My 'meaning' that I attached was many do not want to put in the work but still reap the reward. Honestly it kind of shocked me the numbers. It was not like a couple of people dropped out. It was 95% of them. All of the other people helping with these similar classes had the similar results. My 'bar' for them was to watch 1 video per week over 12 weeks (for 9 videos) and some (optional) simple code test. Is that hubris? I was not expecting much at all.
'Not many people really want to study at work'
Well then that will be a problem for many. If both 'do not want to study outside of work' and 'do not want to study at work' are both true you will find your skills rusty and long term unable to do the job. I have watched it happen over and over. At some point the tech stack will change. You will need to learn it. I can honestly say I have not gone many days in my career learning something. Reading docs, reading tutorials, watching vids, classes, prototypes, whatever.
After crashing and burning the startup rodeo, I gave up. I live off my savings, dabble in crypto for some income, and work on my own software to sell. I've never been happier. Silicon Valley didn't seem to want me anyway.
Nothing wrong with that. SiValley is fucking toxic and I'd leave in a second if I could afford to(mid-life divorce... long story). Leave SiValley for the folks that need to be there(for ego, for money, to satisfy the lofty goals instilled by their society/family/etc). You'll lead a much more fulfilling life in a normal town with your friends and family around you.
> You'll lead a much more fulfilling life in a normal town with your friends and family around you.
This is a false dichotomy. Leaving SV has nothing to do with your friends and family situation. So you can leave SV and be completely alone, or bored, or stuck in a toxic community. And you can also have family and friends in SV.
When I used to complain about the dearth of jobs in my region of the country(Midwest US), people would often say something along the lines of "well duh, the jobs are in SV and the coasts, you've gotta move." This means that I would have to move halfway across the country to one of the most expensive cities in the planet just to have an opportunity for a good job?
There's no way. My family is here. They don't work in tech, they couldn't afford the insane cost of living.
There is a middle ground. I work for a company that is pretty low stress. Salary is also a lot lower than FANG but I'm pretty steady at 40 hours a week and I don't have to live off of savings.
Back in my uni times I remember helping out a few of my friends from CS course by doing pair programming with them (I myself was taking mechanical course, I was not good enough with math and physics to get a place in CS course). They was asking me how do I do this, that I sit down and start solving their problem like I knew the solution despite the fact I have seen each problem for the first time. I used to tell them, that if they cut through enough of problems they will be the same.
From the perspective of time I think there was one thing that I had and most of my CS friends did not - programming was my hobby and I loved everything related with computers, they only wanted the end result which was good money and stable job.
Would I do 1500 leetcode problems? Maybe when I was younger and had no commitments, but certainly not now.
From perspective of years I see that leetcode is quite far from what I do on daily basis, and I do write quite a lot of code.
If I went to the job interview and was given a problem I have never faced before I would want the interviewer to see me finding the solution and not giving memorized (or practiced) answer. If result was not great and interviewer decided I'm not fit for the role that's better outcome than to give false impression and then struggle (even if interview problem is nowhere close to what they do in daily basis).
IMO getting better at Leetcode problems is similar to getting better at mathematics and physics - you become familiar on a topic by doing problems on a daily basis, trying to wrap your mind around the concepts and at times doing a bit of drilling just to stamp the things that need to be memorized.
Both require you to be disciplined and dedicate time on a daily basis, otherwise you won’t get further.
Having the time to address this is absolute luxury to me. Only when I became relatively rich (I‘m coming from a poor background) could I consider learning Leetcode problems. Before that point, I was learning whatever earns me survival money.
I am from a poor background and I did the same thing. There was more important stuff to worry about than Leets. I'm only focusing on it because I'm already successful now and just want to take things to the next level and get "better" work.
When starting with Leetcode you face two questions:
1. Which ones should I do to be prepared?
2. For a given problem how do I find the knowledge that should have helped me recognise and solve it?
Imho, the Competitive Programmer’s Handbook [1] does answer these, every trick and pattern is explained in the most succinct way, in the order you would want to progress on leetcode to see all the basic problem formulations.
Afaik every random interview question would fit into one of these.
I honestly think leetcode is a pretty terrible way to learn how to do algorithm problems, especially without a formal education in algorithms. The large test case bank is the most useful feature. The discussion and solutions shared on the site tends to be lacking in breadth and depth.
I was happier to learn algorithms properly via the algorithms Coursera course taught by Sedgewick. The next time I need to go through the interview loop, I’ll probably start with Programming Interviews Exposed and supplement it with some other algorithm books as needed.
You need both. The theory is important for seeing what class of problem you're trying to solve and to give you an idea of what general approaches might work. The actual problems are needed to get you skilled in actually applying the theory and for learning how to adapt the basic algorithms/techniques under different conditions.
This is so on the money. Leetcode/hackerrank are one form of practice, but they're not comprehensive. They're like a practice putting green or a driving range. Very useful practice, but they teach you how to swing the club not how to golf.
This hasn't really been true in my experience. It's one component, definitely, but in general people are also looking to get a sense of how you handle yourself and communicate when you're stuck on something. Most people will agree that the point of interviews isn't to get the right answer, but to show that you can reason about problems and communicate well.
Ah, man, I get being anxious in interviews but it never occurred to me that newbies would be stressed out by their (lack of) Leetcode score. It's totally unnecessary of course - the people who've racked 1500 problems are probably as unemployed as you are :p
When everyone is a superhero, there will be no superhero. When everyone leetcodes, it is time to get back to fundamentals. So I agree with the author: grab a book, study fundamentals. Instead of memorizing 10 different dynamic programming problems, do study dynamic programming -- it's fun and it is useful in production code anyway. Instead of bitching about finding a shortest path of whatever criteria on a tree, do study backtracking. Instead of agonizing over how to build a LRU or a token bucket, build a LRU and a rate limiter. Instead of pulling your hair on implementing a concurrent queue, study The Art of Multiprocessor Programming. The list goes on and the process is fun.
I'm going through this now and it isn't leetcode anxiety, it's interview anxiety. If you haven't had that many great opportunities in your career, getting a FAANG interview feels like your one shot. And yes, in your rational mind you understand that it's just a job and you already have one so you aren't desperate, there are many other companies too, and there will probably be other chances to interview at the same company... but the anxiety is still real.
Fully agree. If there is any material available to prepare for the interview I will try to fully use it just to calm my mind about the interview itself. Because imagining myself in the interview and not knowing the answer to the one question asked that I could have prepared makes me do it.
Alternatively just refuse to do leetcode "challenges". As a software engineer leetcode is barely related to what i actually do in my job. Anyone who thinks it is a good way of evaluating candidates is a clown.
I started doing leetcode when the pandemic hit. I wanted to be ready in case I got fired and I have to do an interview... surprisingly I fell in love with it. I am one of those ppl that writes codes in their head, so I just look at a problem and go on with my day until I have a solution. Then I write it and test it out.
It's enjoyable to me, and I have been forced to learn a lot of CS concepts I had forgotten and techniques I wasn't aware of.
I don't approach it with the drudge of performance, but just as something I do now. Like other things in my life, basketball practice, namely.
I am pretty sure eventually I'll be in a position I can breeze through an interview if I really wanted to, but that's not my goal anymore out of leetcode.
I'm a simple man, I see "Accepted" and my solution is faster and more efficient than "X%" it makes my day. Maybe I am just the type of person who just enjoys coding for fun.
Also I forgot to mention, one of the reasons I started doing leetcode was our team started a new project in python. Having never written a line of code in it, being a javascript developer for most of my career, I needed the shortest path to proficiency. Solving a bunch of leetcode questions in python also helped me get a grip on the language.
I'm writing solutions in a couple of languages. It takes time, but helps to solidify concepts. Writing Python in a way that is compatible with statically typed languages doesn't take advantage of what Python offers but my run results lead me to believe perform better for that reason.
Also try solving a question in Python then in C++, you will notice drastic performance differences. That is also fun.
The testcases leetcode has is impressive. I know that I can never generate those cases in my spare time or with other tools, so its also enjoyable to watch your code work through it.
I sure as shit hope you don't breeze through. Why should practicing mental leetcode questions prepare you for a job interview in the real world? In my company, you wouldn't breeze through, because we don't participate in 'whiteboard culture', or maybe those sorts of companies you have self selected out of?
Your company isn't the only one in the world though, and the sad reality is that many, many (I'd say in the US - most) companies use leetcode interviews.
If you become a Master of Leetcode, you benefit from massive horizontal scaling that will make you ready to interview at a huge range of companies.
As the parent posted, hate the game, not the player, especially since nearly everyone here is in no position to change the game.
Great site. Spot on in terms of trying to tackle the problem of preparing in a more sane way, and countering the beliefs we have that we need to be able to do XYZ to get a job.
I think the reason that leetcode is so popular is because of so many software engineers underlying anxiety, sense of being unprepared, imposter syndrome. And when that’s already present, we look for solutions that flow into our emotional story. If I already believe I’m underprepared and that the goals I have are hard to achieve, I’m more likely to believe I need to solve 500 leetcode problems.
I help software engineers resolve your underlying interview anxiety and stress around things like interviewing and preparing. If this is you, come talk to us :)
Somewhat related: I have been recently looking for a new part-time project. In the past I have looked on freelancing sites for specifications, built demos, and usually within a certain number of days or weeks had a new client.
But those freelancing sites are horrible. So I decided to create an alternative. Just deployed it today. https://postaspec.com. Submitted as "Show HN", apparently not noticed by anyone in any way. Would be awesome to at least receive one comment about it.
The first time I visited this, the explanation of what it was didn't show up for some reason, but the second time around it worked. This looks interesting.
OP doesn't seem to realize that leetcode questions are used verbatim by companies other than FAANG. Do you need to know how to solve leetcode questions? That depends whether you're going through the front door or the back door. If you're going through the front door, regardless of your experience level, you are going through the leetcode hazing process because that's what your interviewers did and they have no intention of having spent hundreds of hours doing work without a purpose.
Honestly I have done great in every part of life except competitions.
During my school I always score good marks because there were only few books ,( to reach the bar ) , after that due to my issue with perfection, I have always put extra effort and I was successful . I had a very fulfilling schooling with great academic as well sporting results ( National Level Table tennis player) .
Then comes entrance exams . As a person who have always done well in tests , encountered a whole new world of competition. I started reading lot of books for the same subject , never satisfied , I had been a victim of maximum resources and minimum learning. Too be honest I never reached the bar to pass the entrance. Had I been focused on few resources I am sure the story would have been different.
I took engineering and again make the same mistake of maximization of resources and never reached the bar. Completed engineering , now comes the interviews , again made the same mistake. I had lost confidence in all my abilities and stopped applying for roles.
After few months I started freelancing and worked well with clients because there my maximum resources model worked. Now I have significant money to take 6 months off and really start from bottom at preparing interviews.
That's funny, I got anxiety not because I mainly could not solve algorithms problems (looking at you, graphs) but also because I could not beat my colleagues or friends who started to play too.
I used to play heavily on CodeSignal, a similar website. They used to post daily challenges back then. But there, it wasn't about reaching the best time complexity or whatever: the number of characters was more important, like on Code Golf.
You first try to solve the problem and then you try to reduce your code to the minimum. The level of anxiety was starting to be really hard to handle and I'm happy I stopped playing this. Also, writing creative small codes won't help you when developing real softwares that much since most of the times, small codes or one liners are terrible in terms of time complexity or memory.
I learned a few tricks and a lot of things about how some languages work through this practice and by looking at people solutions but I'm pretty sure it would have been better to read some algorithms courses instead.
I enjoy it as a standalone. I hated it at first, but it's actually quite fun as a standalone activity.
I don't enjoy the fact that being a Professional Leetcoder (not a Professional Software Engineer) seems to be the requirement to successfully and reliably (as opposed to eeking through with luck) pass the interview gate at most of the better companies to work at (I'm not just referring to FAANG).
I don't enjoy the fact that I need to put on a circus show act that pretends I can serendipitously come up with the optimal solution to a problem handling all obscure edge cases within 20 minutes.
I don't enjoy the fact that almost everything I do at work is close to meaningless for career progression because very little of it is relevent to passing the interview (usually only touched upon in a "system design" round).
Only after shifting from a goal-oriented mindset to a process-oriented mindset; I now just love improving my intuitive structural thinking ability, and LC is for nothing more than that.
> Instead, pick a book or a course that teaches ~100 well represented problems. And don't pick a book or course that has only problems. Pick something that teaches you to think about them.
The site doesn't actually list any books or courses that do this. It just states that bouncing around is bad in https://leetcodetherapy.com/interview-prep-today, but it gives no specifics for the right way of doing it. Maybe the reason that guy is bouncing around is that there IS no resource that steps through "100 well represented problems."
> Leetcode and other websites have conditioned us to think that we need complication.
A paradox that's plagued me my whole career is that simple abstractions are less approachable than complex ones. Simple abstractions almost by definition create bubbles of private language, making it hard to use existing knowledge to bootstrap into new knowledge. Complex abstractions don't have this problem.
I don't think Leetcode has conditioned anyone to think they need complication. I think beginners just find complexity more tractable, at least at first. Grappling with it feels like learning and doing. Leetcode rode that wave to where it is today.
I agree that you only need to master 100, maybe 200, core questions then solving 1500 leetcode questions is only a time problem. However, most of candidates are not reaching or even closing to “master” level.
For example, given a question, can you immediately figure out the real problem you need to solve? What kind of algorithms and data structures look possible or useful for this question? Do you clearly understand the time complexity of each possible algorithm? Can you explain the solution quickly and clearly? What about other alternative solutions?
> Here's all you need - master 100 problems first, then slowly progress to maybe 200 more problems. Do it well, and you can crack several top companies.
I still don't see the memorization part. The last time I touched quicksort was at uni, three years ago, I still understand how it works (choose a pivot, partition the rest according to the elements' relation to the pivot, then quicksort the partitions), and I'm pretty sure I'd be able to implement it right now. Maybe not in C, but in Ruby, absolutely.
Understanding is the hard part, the implementation should be the automatic part. I mean, we're programmers, right? We know how to shuffle arrays around and return values from functions.
This is actually the hard part for me. Like I guess I can memorize some questions but not 300. Also how long should I bang my head against the wall before looking up the solution?
Should I just be looking up solutions instead of even trying to solve them if the goal is just memorization?
Memorizing LC solutions is attempting to "stockpile."
Instead, we should be learning the main principles, and then reacting to technical interview problems from there, rather than trying to recall the solution to the problem.
The author says on the site to focus on a 1-2 resources. I have gone through CTCI but it seems lacking on explanation. Any other BOOKS (not online) that are superior?
More and more tech companies are beginning to hire for soft skills as a main emphasis, with basic technical skills as a given. They're tending to intentionally NOT hire l337 folks, with a lot of emphasis on avoiding the "brilliant jerk." So, if you are personally interested in the work, willing to learn, and aren't a jerk, you'll probably go further than someone who has traveling salesman memorized in 8 languages.
Curious what companies these are or where you are seeing this data. This has not been what I have seen, I actually think leetcode is becoming more and more common in interviews. Just adding some of my own anecdata.
The last two companies I've worked for, and feedback I've gotten from product managers and hiring people.
All of the interviews I've done over the past few years have used leetcode, or some variant, but most of them used it only as one dimension when considering candidates. If someone was leet at coding, but bad at team work, they didn't have a chance. The opposite position was far more favorable (I've heard "you can train people to have skills, so hire for the things you can't teach" more often than once). In fact, I'm seeing companies swing the pendulum a little too far away from skills, but that's to be expected, when doing this kind of balancing.
> if you are personally interested in the work, willing to learn, and aren't a jerk, you'll probably go further than someone who has traveling salesman memorized in 8 languages.
I'm not sure how you test the first three qualities reliably in an interview. The point of leetcode interviews is that they are arguably harder to game: if you manage to write some code solving some problem, you at least memorized a solution and somewhat understood it.
Maybe you trust engineers to be completely transparent, but then you also let in a different kind of "brilliant jerk" (as you put it) who learnt to fake interest.
I assume you're talking about cheating? That's mostly possible for remote interviews, not that easy to pull off.
> I think you underestimate the skill of interviewers. You can learn a lot about a person from one directed conversation, if you want to.
You can definitely learn a lot, but the three qualities you mentioned were:
> interested in the work, willing to learn, and aren't a jerk
If someone wants the job because of $REASONS that differ from these, they can still practice to show these traits during the interview.
You could dig deeper in their portfolio if they have one, but my point is that the 1h interview is not going to bring you much more with respect to these three criteria you mentioned.
What’s a good way to pickup CS skills in a well rounded manner outside of a CS degree?
Moving from Sysadmin to DevOps rolls and need to learn this stuff.
The algorithm design manual by skienna is a popular choice. The first half is more instructional regarding different classes of algorithms and datastructures and how they should be used while the second half is like an encyclopedia of descriptions of various algorithms. It's a very approachable read and I've found it to be a great book, all around.
A lot of people recommend the super heavy tome textbooks, which could be useful, but I feel like from your description you'd be better off with this
"CS skills" is broad, and mostly irrelevant for a DevOps role.
Computer Science can be quite fascinating and can involve considering fancy data structures/algorithms, applications of linear algebra in terms of computer graphics / computer visions, machine learning or AI.. or stuff like how a compiler or a search engine works.
But I'd say moving from System Administration to DevOps, it's more important to know software development skills (like using version control software, or how to achieve the things you'd do as a sysadmin using a programming languague) than it is to know about algorithms for balancing a binary search tree, or to crank out leetcode problems.
I've had good success with some Finnish MOOC on java when I had a teacher who didn't even know what RAM was. I had to learn quick unfortunately cause she just graded if it was right to wrong. But even with probably writing over a couple thousand lines it code, I don't think I became comfortable with OOP until like 6 months in. Personally, I think C# and Java are the easiest to learn and I don't care what anybody says. C/C++ gets hardcore fast and makes things frustrating. Web Dev gets boring because you mess with html tags and css more than you do javascript.
2. CS stuff is widely available for self-study if you've got good discipline. "The Algorithm Design Manual" by Skiena is my favorite textbook on algorithm fundamentals. CLRS is a bigger book with more mathy crunch, if you're into that.
There's a lot more to computer science and software engineering than just algorithms, but it's what you'll get grilled on the most in junior level interviews. By the same token, the skills you need as you get more senior in this industry aren't really taught in school.
If you are a traditional sysadmin with limited programming experience, then you have a very tough road ahead of you in 2021 - getting up to speed now is not picking up "stuff", think of it as a new career.
You should stay at your current job and work on devops projects to learn the devops tools and skills and get proficient at basic programming first.
After that, start on more advanced programming.
If that doesn't get you through interviews, then LeetCode. I put this last because even with a fair amount of practise, most people can't finish a difficult problem in 30 or 60 minutes and pass the test suite.
I don't get why interviewers sometimes start with, "Sorry, this is the problem, but nobody ever finishes it." (One was write a hash library with tests in 30 minutes, for a devops role.) You just have to move on to the next company.
This is where I’m stuck: how do we know which patterns are possibilities? I’ve never seen a “patterns for leet code” website, yet.
Further, how does a naive person know which pattern applies to a problem? Without that knowledge, how can I vet a learning resource and know I’m not wasting my time?
> Further, how does a naive person know which pattern applies to a problem? Without that knowledge, how can I vet a learning resource and know I’m not wasting my time?
Problems in leetcode have tags under "related topics" and you can look at discussions to find out the pattern.
That said, sometimes its not simple pattern matching. Its an itution that you can develop if you keep solving leetcode problems.
I interview candidates every day, and my impression is that a candidate from FAANG/leetcode company is no better or worse than any other candidate.
Anywho, I’m hiring for a bunch of roles - full stack, Android, infra, SRE, early career, etc - if you’re interested in Notion (https://www.notion.so/careers) ping me on Twitter @jitl.