Does anyone else just enjoy leetcode? I think it's fun.
Avoiding Leetcode Anxiety
131–140 of 157 posts
Re: Avoiding Leetcode Anxiety
#132Earlier quoted context omitted.
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?
Mediocre actors stockpile material. Good actors react from first principles.
Re: Avoiding Leetcode Anxiety
#133Earlier quoted context omitted.
What do you love about leetcode problems? Mindset makes a huge difference.
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 profi…
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.
Re: Avoiding Leetcode Anxiety
#134Does anyone else just enjoy leetcode? I think it's fun.
Re: Avoiding Leetcode Anxiety
#135I 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 tec…
What do you love about leetcode problems? Mindset makes a huge difference.
It is a systematic approach to mastering Leetcode
Re: Avoiding Leetcode Anxiety
#136I'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, fee…
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.
Re: Avoiding Leetcode Anxiety
#137Earlier quoted context omitted.
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?
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.
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.
Re: Avoiding Leetcode Anxiety
#138Earlier quoted context omitted.
Can you shed a bit more light on what kind of thing is discussed? Is it similar to Blind in that it's a lot of people talking about how to pragmatically game the interview process?
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}"…
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.
Re: Avoiding Leetcode Anxiety
#139Earlier quoted context omitted.
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 criter…
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?
Re: Avoiding Leetcode Anxiety
#140Earlier quoted context omitted.
Sure but one can understand quicksort, then forget how to implement it a month later. Or not be able to modify it to produce quick select. So really, you do need to memorize stuff. Maybe not questions per se, but certainly patterns and techniques (on top of understanding the fundamentals)
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 a…