4 ms·
Perception of talent is also a function of how boisterous the claimant is. Leetcode script kiddies get in, jump from project to project, not spending more than
by yudlejoza 6y ago
Perception of talent is also a function of how boisterous the claimant is.
Leetcode script kiddies get in, jump from project to project, not spending more than a few months at each, make a filthy mess of every codebase, and leave it to the silent but persevering, a.k.a real, talent to clean up the mess, and steward the ship.
You can focus on the serious tech challenges, or you can be boisterous. You can't be both.
edit: "can't be both" == "improbable/competing-factors, not impossible"
- deleted 6y ago[deleted]
- mathgladiator 6y agoyou can do both, but generally when you take on serious tech challenges it humbles you. As an example, I used to work on Amazon S3, and that was a humbling experience. Unlike a lot of people that bounce after a year, I stuck it out for 3.5 years which is the shortest term on my c.v. Now, part of my time there was massively refactoring a critical service to maximize test coverage, reduce memory footprint, improve reliability, measure new things, make the system more durable, and introduce new features. It was exceptionally serious and difficult, and if I made any mistake then the internet would effective go down. After the fact, yes, I can be boisterous because I did serious shit without fucking up.
- volume 6y ago> You can focus on the serious tech challenges, or you can be boisterous. You can't be both. There's always a spectrum right? Or I guess you are exaggerating to make a point.
- hobofan 6y ago> You can't be both. Why not? It's not like both of those are full time efforts.
- spideymans 6y agoIt's definitely an exaggeration. But there's some truth to what they said. Towards the end of university I spent my free time honing my skills as an engineer. I debated whether I should spend my free time leetcoding, or developing a fairly complex distributed application (complex, at least for an individual engineer). I could do one, or the other, or both. But doing both would mean degrading the quality of my learning (there are only so many hours in a day). I decided to focus exclusively on the disturbed application. The lack of leetcoding experience definitely hurt my job search, because plenty of employers will completely refuse to interview you without a high enough score. However, among the interviews I did get, they were very impressed with my experience developing and architecting applications, and it ultimately helped me land a job. Long story short, every minute I spent leetcoding was a minute I could've been spending improving my skills as an engineer. I have no regrets about my strategy. It left me better positioned in the long term.
- Mc91 6y agoI don't think it ends at university. I have been in IT a while but am somewhat new to my stack, and had trouble two years ago when interviewing, a number of companies passed on me. I got hired at a decent salary but don't want that to happen again so I have been studying. I am more in control of my timeline, and have been studying, but I want to be in a better place if I want to look around in a year. So for your choices of learning to improve quality of knowledge or doing what needs to be done to pass leetcode, my choice is to do a little of both. I am studying for the things they may give me on an interview (work samples to complete, 30 minute coding exercises, whiteboard class design etc.) But I am not doing it in a shallow leetcode way where I just want to know enough to pass the interview. If I am building something akin to the complexity of a given work sample, I want to understand the architecture of what I am handing in, the language aspects of it, how the unit testing works and what to unit test and all of that. To have a deep understanding of it, or at least more than a surface leetcode understanding of it. If I am new to the topic I try to get some grasp of it, move on, and then sometimes I revisit the topic in the future to deepen my understanding of it. So the immediate ends of a lot of what I do in my spare time is to prepare for the interviews I may have in a year. But one aspect of it are that I will spend a little time if needed to learn things which may not be asked in an interview, but which would let me do a better job at my current job or next job, or even if I want to write a program on my own. Another aspect of it is that I spend the time to try to get a decent enough understanding of it before moving on, not just enough that would pass over the leetcode bar but not into a slightly deeper understanding. So the main aim is passing an interview, but I will take the time out to learn things to improve my work, not just interviewing, and to deepen my knowledge of the subject as well.