Avoiding Leetcode Anxiety
leetcodetherapy.com
leetcodetherapy.com
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.
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.
Looking at a smattering of leetcode mediums, I don't understand how someone being able to return "the elements of a 2d matrix in spiral order" (https://leetcode.com/problems/spiral-matrix/) or use Kadane's algortith to solve "k-concatenation max sum" (https://leetcode.com/problems/k-concatenation-maximum-sum/) pertains to building multiplayer software as part of a team.
> 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.
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.
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.
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.
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.
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.
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.
Well, I applied anyway :)
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.
(The site treats other job elements similarly: open seating plans, remote-ness, etc.)
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.
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.
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.
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 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).
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.)"
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.
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.
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.
(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.
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.
If you want to read official tune, here's the article about "内卷" among university students: http://www.xinhuanet.com/2020-11/09/c_1126713666.htm
Other than those publicly searchable contact. There are many nonpublic/deepnet information, for example, recruitment ads, under table HR rules etc.
Here is a recruitment ads from Minhang District government that set age limit (from 18 to 35 years old) for no good reason: http://xxgk.shmh.gov.cn/mhxxgkweb/html/mh_xxgk/ggxxgk_xxgg/2.... And another one from Zhongwei City: http://www.nxzw.gov.cn/xwzx/tzgg/202103/P0202103163192272939...
Case and point, this problem is widespread and kind common knowledge in China.
How so? when it comes to scale they easily compete with FAANG, don't they?
Tencent, Alibaba, Baidu, Bytedance...?
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.
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.
Is it similar to Blind in that it's a lot of people talking about how to pragmatically game the interview process?
* 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.
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.
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.
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?
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.
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.
Not to dismiss your opinion, but where are the proofs?
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.
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.
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.
As an attorney, when you change jobs you've already passed the bar.
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.
There's no way. My family is here. They don't work in tech, they couldn't afford the insane cost of living.
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).
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.
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.
Let me know if you know a better one.
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.
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.
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.
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.
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.
It is a systematic approach to mastering Leetcode
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 :)
tinyurl.com/happyhackers
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.
Pretty tired but maybe tomorrow a designer can help make a real landing page.
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.
Hope it helps somebody.
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 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).
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."
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.
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?
Memoizing 300 questions isn’t easy
So really, you do need to memorize stuff. Maybe not questions per se, but certainly patterns and techniques (on top of understanding the fundamentals)
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.
Should I just be looking up solutions instead of even trying to solve them if the goal is just memorization?
Good actors react from first principles.
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.
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.
Granted, this is most likely not where most HNers would not like to spend their work day, but it does have its own perks.
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.
Or got someone else to do it for you.
I think you underestimate the skill of interviewers. You can learn a lot about a person from one directed conversation, if you want to.
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.
Many can, but over time that practice itself becomes evident to a good interviewer.
No process is perfect, nor can it be. But, that a few can slip through doesn't mean that all can, or do.
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
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.
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.
eg: pick more sliding window pattern, dp, greedy vs pick less for binary tree/dfs problems.
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?
https://hackernoon.com/14-patterns-to-ace-any-coding-intervi...
> 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.