←back to thread

Please stop the coding challenges

(blackentropy.bearblog.dev)
261 points CrazyEmi | 9 comments | | HN request time: 1.699s | source | bottom
Show context
agentultra ◴[] No.42149111[source]
> When was the last time you had to debug an ancient codebase without documentation or help from a team?

All the time. 300-400k SLOC in C++. Legacy in the sense that there were no tests of any kind. Little-to-no documentation. Solo developer at the tiny company. Fix bugs and add features while keeping the system available to the tens of thousands of users.

A more recent example: here’s a patch for a critical feature we need. It was written over a year ago. The original author isn’t available anymore. You can write the code from scratch or try to resurrect the patch against master.

Being able to jump into a project and lead people towards some goal is definitely a skill for senior developer positions. Yes, you generally have a team you can lean on and have the ability to do research and all that. But how do you show that you can do all that in an interview?

Agree with the conclusion that a good thing to test for is for problem-solving.

The tech side depends a lot on what you’re doing. Although it gets ridiculous and organizations get lazy with this part. You don’t need to be white boarding graph algorithms for a junior web developer role. If your application is a social networking role and you’re interviewing a senior developer or architect? Definitely. They’re going to be teaching this stuff and need to understand it at a deep level.

replies(25): >>42149161 #>>42149283 #>>42149381 #>>42149490 #>>42149504 #>>42149546 #>>42149679 #>>42150007 #>>42150216 #>>42150233 #>>42150322 #>>42150383 #>>42150537 #>>42151066 #>>42151233 #>>42151287 #>>42151513 #>>42152496 #>>42153372 #>>42153374 #>>42155334 #>>42155491 #>>42157152 #>>42162104 #>>42194406 #
zimpenfish ◴[] No.42149381[source]
+1 for "all the time". Today I have been debugging a critical piece of the system which is written in Python (none of the rest of the system is) and largely hasn't been updated since 2020 and, you'll not be surprised, has no comments, no documentation, and a fucked up deployment system which makes me cry every time I have to think about it.

Last week I was debugging some similarly uncommented, undocumented, Go code from 2020 written by lunatics that is also a critical piece of the system.

It hurts.

replies(2): >>42149719 #>>42149760 #
1. thatguysaguy ◴[] No.42149760[source]
Yeah from the title I thought this was going to be about leetcode problems, but this is truly something that comes up regularly.

Where are these dev jobs where _don't_ have to figure out some mysterious issue in a barely maintained GitHub repo semi-regularly?

replies(3): >>42149878 #>>42150281 #>>42152731 #
2. evoke4908 ◴[] No.42149878[source]
Yeah, I feel like jobs that don't require you to reverse engineer a bunch of stuff are the exception, not the inverse.

Hall, I do greenfield embedded programming. Most of the code I touch is completely new; the entire codebase has been replaced and rewritten by me over the last three years. Not one other developer has contributed any significant amount of code. Even then, in this scenario, I'm still reverse engineering some arcane undocumented code at least once a week. Nobody ever documents their libraries properly so I have to rip everything apart to see how it works. Or I need to adapt some vendor example code or a GitHub repo into a slightly different form. Even just existing in the ESP-IDF environment I have to dig into the core code to figure out what the hell it's doing and where these error messages come from.

If you can't read someone else's Gordian knot of undocumented code, I'd argue you are probably not very good at writing code. Reading bad code is a vital part of learning to write good code, and is generally just a fundamental core skill that every programmer needs to have.

replies(1): >>42150020 #
3. tayo42 ◴[] No.42150020[source]
How are you defining bad code?

Imo unreadable and undecipherabe code is one subset of bad code.

replies(1): >>42151882 #
4. VyseofArcadia ◴[] No.42150281[source]
> Where are these dev jobs where _don't_ have to figure out some mysterious issue in a barely maintained GitHub repo semi-regularly?

Oh, my job is one of those.

Our code is in Perforce.

replies(1): >>42153537 #
5. dahousecat ◴[] No.42151882{3}[source]
I would argue, that in that vast majority of cases, the readability of code is the single most important metric.
replies(1): >>42154515 #
6. icedchai ◴[] No.42152731[source]
A repo would be nice. I was recently given a 500 meg .zip of "backend stuff" and asked to figure out what's going on. No repository, no history, the read me is useless, the APIs look like they were built by rabid animals...
replies(1): >>42152873 #
7. dudleypippin ◴[] No.42152873[source]
My favorite description of this sort of setup is "coded by vandals".
8. anankaie ◴[] No.42153537[source]
This is the most Software Engineer answer. Emphasizing only the distinctions that make no difference :D
replies(1): >>42160002 #
9. amluto ◴[] No.42154515{4}[source]
If I encounter third party code that is terminally broken, I don’t really care how readable it is, except insofar as I can probably tell it’s terminally broken faster if it’s more readable.