7 ms·
Two outcomes for the technical industry: 1.) Everyone is studying these problems all of the time and they finally disappear. 2.) Other outcome is a dystopian
by codingslave 7y ago
Two outcomes for the technical industry:
1.) Everyone is studying these problems all of the time and they finally disappear.
2.) Other outcome is a dystopian field fueled by a race to the bottom where everyone is practicing algorithms problems all of the time. If you read the blind forums, some people are completing 500-1000 leetcode problems before heading into interviews.
I'm putting my money on number 2, which is where we already are. Can only imagine what this is doing to code quality...
- deleted 7y ago[deleted]
- triceratops 7y ago> Can only imagine what this is doing to code quality... Why would studying algorithms and data structures affect code quality? They would similarly be able to learn to write quality code once they're inside the company, no?
- _hardwaregeek 7y agoBecause you get the college applications problem, where you stop getting the people who have a real passion for programming and coincidentally have problem solving and algorithms skills, and start getting people who are really good at problem solving and algorithms and may or may not have a passion for programming.
- triceratops 7y ago> start getting people who are really good at problem solving and algorithms and may or may not have a passion for programming. Why is "passion" so important? And what even is passion? For professionals in every other field, competence, ability to deliver results, and getting along with people, are what matter. Many pros are passionate, in the sense of loving their work, but passion isn't a prerequisite for being a pro.
- povertyworld 7y agoMost programming is not solving tricky puzzles, but grinding out code.
- triceratops 7y ago> most programming is not solving tricky puzzles, but grinding out code. Sounds like most jobs need dispassionate guns-for-hire who'll do excellent work, no matter how tedious, get paid, and go home. In other words: pros.
- deleted 7y ago[deleted]
- _hardwaregeek 7y agoOy vey. I didn't mean passion in the "I'll work 80 hours a week for little pay mister!" kind of way. I mispoke. I meant that before, if you based your interview process off data structures and algorithms, you'd get competent professionals who just happened to be good at algorithms. While now you'll get a bunch of people who have specifically trained to be good at algorithms. Which has no bearing on competence.
- triceratops 7y agoWhy can't people who study to get good at algorithms also study to write better code? They've already demonstrated their aptitude for learning difficult things.
- _hardwaregeek 7y agoFor one, interviewing requires extremely short term knowledge. Almost everybody I know who plays the interviewing game learns just enough to pass the interviews, then immediately forgets it until the next time. So it's not really comparable to learning and refining a difficult topic over the course of a few years, as in the case of software development practices. Also, it's two completely different skillsets! There's something very weird about interviewing for X but then demanding Y. I don't ask my primary care physician how good he is at surgery, then be like "he knows how to learn difficult tasks, so we're good".
- jjav 7y agoThis race to the bottom, as parent poster said, is from a generation of developers hyper-specializing in interview-style problems. These problems are tiny and self-contained and have a slick solution which can be regurgitated onto a whiteboard in about 30 minutes give or take. While that is not a negative skill to have, it is also not a skill that I'd list anywhere in the Top-25 of most valuable skills for productive developers.
- 13thThief 7y agoJust curious, could you list the top 25 (anecdotal?) valuable skills for a productive developer? Thanks.
- codingslave 7y agoBecause these people are just memorizing coding problems. It's like a spelling b
- lawn 7y agoBecause these problems encourages you to write unreadable code. It makes sense when you write it, because you can fit it in your head, but you never have to revisit it after having passed the problem. It encourages one letter variable names and other quick hacks in the name of speed. They work against creating readable, understandable and debuggable code which is much more important in general than being able to solve algorithimical problems you'll almost never see in real life. I've seen this first hand where some were brilliant at these problems but wrote the worst code imaginable. I would rather hire someone who can write clean and simple code and teach them how to solve these problems than the reverse.
- username90 7y ago> I would rather hire someone who can write clean and simple code and teach them how to solve these problems than the reverse. Why? Teaching people to write readable code happens automatically during code reviews, teaching people how to think is a lot harder.
- lawn 7y agoBecause producing simple and good code is much more important. It's quite condescending and narrow-minded to say that solving algorithmic problems is thinking, but writing clean and simple code isn't. Writing readable code is much more than just formatting code and using decent variable names. It's about simplifying your design just enough. Code reviews is not enough to teach someone this.
- triceratops 7y ago> Because these problems encourages you to write unreadable code. First off, no, writing good code in an interview wins you additional points. Second, why do you think candidates can (or will) continue doing that on the job? New employees aren't allowed free rein to check in code from day 1 at most places - trust has to be earned. And I don't think any decent company allows check-ins without review.
- closeparen 7y ago
- decebalus1 7y agoI started leetcoding again this year because I want to jump ship and holy crap! I used to solve problems on leetcode 5 years ago (last time I switched jobs) and it was pretty laid back. Nowadays, I'm seeing dynamic programming with 3D memoization arrays like it's something normal. It all started like a way to check if someone knows how to write code or knows data structures and basic algorithms but now it's competitive programming level.
- raincom 7y agoThat's what happens whenever there is a competitive exam. Look at math olympiad papers from 1970's, and compare them to the recent olympiad math test. Tougher than 1970s. It is the same about many entrance exams we see in China, India, etc: older exams are easier than the recent ones. People just master the foundations behind the old test material. Now that stuff has become trivia of the today. So, they need some advanced stuff to test the test takers.
- solipsism 7y agoCan only imagine what this is doing to code quality... I don't get why no one seems to consider the possibility that these sorts of interviews actually do get high quality engineers in the door. I get downvoted for raising the question every time. But isn't it possible this interview style actually works, even though it doesn't resemble real coding and even though many of us hate it? I have yet to see any compelling argument for why I should believe these interview practices don't work. And yet the fact that so many companies, with so many resources to change things up if they felt it was in their best interest, keep interviewing this way must at least suggest the possibility that maybe it works?
- fogetti 7y agoI guess the reason is that if it would work we would already know about it and there would be a bullet-proof way to prove it
- solipsism 7y agoCan you help me follow, because that seems like a leap of logic. Why would that imply there's a bullet-proof way to prove it?
- fogetti 7y agoBecause if you can't prove it works, you cannot know it works. You can only assume then.
- username90 7y agoThe companies using it has statistics that it works. They have no reason to publish such statistics since it would help their competitors.
- fogetti 7y agoThat's an interesting theory. But this problem is actually not confined to the industry, it impacts academia too. Even just as a purely theoretical statistical problem since there is enough data and easy access to that data we should already have some research in this field which sheds some light on the hiring issue.
- yodsanklai 7y ago> some people are completing 500-1000 leetcode problems before heading into interviews. Over the course of one year, I completed, classified, commented 200 leetcode problems. I also taught algorithms to third and fourth year university students not too long ago. I believe I write readable code, I know perfectly the language I'm using (at least for that purpose), I'm totally fine with complexity, and I know most methods involved in these algorithms, including more advanced algorithms such as KMP. Yet... I failed my round of interviews at Google. After this preparation, I'm still not able to solve quickly any leetcode problem in the context of an interview. On a whiteboard, with an interviewer in my back, in a stressful situation. I need to practice more if I want to get consistent results. So I agree with your conclusion. We are competing with a lot of people who train using the same resources. Including young graduates who have a lot of free time on their hand. On a positive side, I'm thankful to Google for giving me a shot. Based on my resume (40+ with little experience in software industry), I'm not sure I would have been interviewed in a more traditional company, let say a bank. To come back to my interviews, system design went very well. Algorithms quite well too but not well enough. Couldn't solve one problem, and a bit slow on an other one. The recruiter first told me I passed, and that they were going to find a team for me and make me an offer. But they finally asked me to re-take the algorithmic interviews a few months later, to "make a stronger point to the hiring committee". Never heard from them since then, about 8 months ago. Recruiter doesn't answer emails. I think she moved to a different position. Not sure what to do now?
- raincom 7y agoThere is nothing you could do. Just like when you are new to the dating world, you are just new to the recruitment world: when the company wants, they will send you emails, call you, etc. When you don't hear from them, don't even bother sending emails. That's why you should interview with multiple companies, in the hope that one of them will offer you a job.