News for hackers. Stuff that matters.
Re:Tech Interview Handbook by lawn on Sunday August 18, 2019 @05:56AM (#20729287)
Because 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.

Re:Tech Interview Handbook by username90 on Sunday August 18, 2019 @06:03AM (#20729305)
> 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.

Re:Tech Interview Handbook by lawn on Monday August 19, 2019 @01:12AM (#20735045)
Because 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.

Re:Tech Interview Handbook by triceratops on Sunday August 18, 2019 @12:10PM (#20731036)
> 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.

Re:Tech Interview Handbook by closeparen on Sunday August 18, 2019 @03:43PM (#20732356)
Code reviews are good at catching oversights and at giving design & implementation pointers to people acting in good faith. Senior talent doesn't have the time or energy to push back on all of a systematically incompetent person's code until it's good. See the bullshit asymmetry principle. And once you hire two of these people, they'll just review each other.
Re:Tech Interview Handbook by triceratops on Sunday August 18, 2019 @07:23PM (#20733596)
> giving design & implementation pointers to people acting in good faith

Why automatically ascribe bad faith to people who study for coding interviews? They went to all that trouble to get better at something, so they're obviously diligent and seek self-improvement.

> Senior talent doesn't have the time or energy to push back on all of a systematically incompetent person's code until it's good.

That sounds like a problem with the company's timelines or priorities. If senior talent is so strapped for time that they can't insist on decent designs upfront, then they likely can't hire the right people either. Because even that takes time and energy. Mentoring juniors is part of the job for senior engineers.

Re:Tech Interview Handbook by closeparen on Monday August 26, 2019 @10:27AM (#20800122)
The time to review a diff is proportional to how much work it needs. Code reviews that are within the normal bounds of “needs mentorship” don’t cost that much. Productivity is noticeably down across the board during intern season, though.

It’s more than a full time job to push back on all of a bad hire’s output, and people are accountable for their own projects as well. Things inevitably get to “fuck it, good enough.”