Live data from Hacker News

Programmer's Dilemma

medium.com

21–30 of 113 posts

Re: Programmer's Dilemma

#21
post #11

I applaud the author for bringing up this point, however, there is only so many hours in a day. The developers in question are probably not 30 years old anymore. They were cool once too ya know. Instead of bashing them for not coding and drinking Mountain Dew till dawn, why not see if they are willing to learn again ... on the job ? Be careful young bucks ... you're looking at yourself in 10 years. The fix to this is…

I can only speak to US-based IT jobs, but there's a really distinct problem with the industry here. There is a decent supply of bright young things coming out of school who don't know things, but know that they don't know things, and study and bust ass on stimulants to make up for it -- coding all night on Dew. By the time those bright young things are 30, they have probably given up the Dew because they have high bl…

[deleted]

Re: Programmer's Dilemma

#22
post #17

Earlier quoted context omitted.

A simple LRU cache is not very much code (certainly less than 100 lines even in C). Assuming the hash function in question has a sensible API, getting something that works but has a few bugs and performs suboptimally should not be at all difficult for an experienced programmer who knows what an LRU cache is.

I totally agree. This should not be a hard problem to conquer since the hash table is provided by library. I just want to see if the candidate is a competent coder and a fast learner.

Okay, yeah, I guess I was overthinking it a bit. It does seem relatively straightforward now that I reflect on it some more.

Re: Programmer's Dilemma

#23
post #21

Earlier quoted context omitted.

I can only speak to US-based IT jobs, but there's a really distinct problem with the industry here. There is a decent supply of bright young things coming out of school who don't know things, but know that they don't know things, and study and bust ass on stimulants to make up for it -- coding all night on Dew. By the time those bright young things are 30, they have probably given up the Dew because they have high bl…

[deleted]

To me the most valuable programmer is a full-stack developer

That's because of the type of problems you work with. I have seen a embedded programmer literally create over 10 million in value in less than 8 months by rewriting someone else assembly code. His code did error correction, and cooperative multitasking on a 32khz embedded system which allowed the company to avoid ripping out a lot of deployed hardware by added new capability's and fixing a range of issues relating to cosmic radiation flipping bits. (You deploy enough sensors and it's an issue.)

Re: Programmer's Dilemma

#24
post #9

Although the article as a whole makes very good suggestions about keeping your skills fresh, I think his standards for the candidates he interviewed are impossibly high. Expecting an understanding of what the kernel does when malloc is called is probably fair (actually I think this is a trick question, as I believe the kernel doesn't actually page in any memory until it is accessed for the first time). But I don't th…

I think the difficulty of the malloc question is a bit hard to assess for non-kernel programmers. Best I could do is some educated guesses that would probably be wrong. But then I am not a kernel/systems programmer

The LRU cache on the other hand sounds trivial.

Re: Programmer's Dilemma

#25

Earlier quoted context omitted.

A simple LRU cache is not very much code (certainly less than 100 lines even in C). Assuming the hash function in question has a sensible API, getting something that works but has a few bugs and performs suboptimally should not be at all difficult for an experienced programmer who knows what an LRU cache is.

While I agree with you, writing a crappy LRU will be a poor indicator of skill for a senior developer or architect. It will be just a pointless and useless piece of code. My guess is that the author asked for production-ready high quality code. I know that I've been asked many times for production quality code in interviews.

If I was the interviewer I'd just check how they go about it - do they just start typing or do they read the docs, that's a big one right there. I wouldn't expect bug free code, just a reasonable attempt, clean code, and something that generally works because a LRU cache is really simple.

I disagree it's useless - if I have a senior developer, they better know how to do the basics. Otherwise what are they good for?

Re: Programmer's Dilemma

#26
Two observations:

- The worst programmers work for big corporations. Because there the overall level of competence is so low they can scrape by barely doing anything.

- Very true about keeping skills sharp and developing new skills. It's hard to do and hard to keep up but always worth it.

Re: Programmer's Dilemma

#28
He's abrasive, but I really think michaelochurch is on to something here. Why are programmers old hat at 40, but not doctors? Answer: because it's accepted that doctors have to spend time sharpening their skills: reading journals, attending conferences, etc. This is not true at all of programmers ("The book said you could learn it in seven days. How hard can it be?").

Programmers sell themselves short.

Re: Programmer's Dilemma

#29
post #9

Although the article as a whole makes very good suggestions about keeping your skills fresh, I think his standards for the candidates he interviewed are impossibly high. Expecting an understanding of what the kernel does when malloc is called is probably fair (actually I think this is a trick question, as I believe the kernel doesn't actually page in any memory until it is accessed for the first time). But I don't th…

[deleted]

Re: Programmer's Dilemma

#30
post #26

Two observations: - The worst programmers work for big corporations. Because there the overall level of competence is so low they can scrape by barely doing anything. - Very true about keeping skills sharp and developing new skills. It's hard to do and hard to keep up but always worth it.

MORE programmers work for big companies, so you get a full normal distribution, and I would imagine there's a bias toward interviewing more of the ones who got fired or poor performance reviews. You only see the tail.
Post reply on HN