Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmer's Dilemma

medium.com

Post reply on HN
Print view View original

31–40 of 113 posts

Re: Programmer's Dilemma

#31

Post by pacala »

vladimirralev wrote: post #20
plorkyeran wrote: post #12

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.

There is "crappy" as in buggy / overcomplicated and there is "crappy" as in lean, simple minded LRU that just works. The latter is production-ready high quality, even if it may be not tuned or optimized. You can tweak later, first can you actually ship some code?

Re: Programmer's Dilemma

#32

Post by zhemao »

[deleted] wrote: post #29
zhemao wrote: 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]

That's about it, except you have to keep track of the total size of your cache so you know when to start evicting. I didn't mean that it couldn't be done, I just thought that one hour was a bit short. I tried it myself and, after setting up tests for the common use cases and tracing down all of the memory errors, it took closer to an hour and 45 minutes. I suppose if the author wasn't looking for perfection, but for something quick and dirty, it wouldn't be so unreasonable.

Re: Programmer's Dilemma

#33

Post by zhemao »

pacala wrote: post #31
vladimirralev wrote: post #20

Earlier quoted context omitted.

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.

There is "crappy" as in buggy / overcomplicated and there is "crappy" as in lean, simple minded LRU that just works. The latter is production-ready high quality, even if it may be not tuned or optimized. You can tweak later, first can you actually ship some code?

I think it takes more than an hour to make something production-ready. Setting up test cases and tracing down memory errors and leaks is going to take a while, even (and I would think especially) for an experienced C programmer.

Re: Programmer's Dilemma

#34

Post by [deleted] »

nikster wrote: post #25
vladimirralev wrote: post #20

Earlier quoted context omitted.

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?

[deleted]

Re: Programmer's Dilemma

#35

Post by benjaminwootton »

Its hard not to fall into this situation even if you work for startups or small companies.

Say you arrive on day 1 on a greenfield project. You will soon be fitting in with other developers patterns and spending time digging into code thats not your own.

Even if you are the lucky one putting low level frameworks and architecture into place, that eventually stabilises too snd you move on to more typical work at a higher level of abstraction.

As time goes by, your knowledge of the code, product, domain, organisation, market etc continues to grow. In a matter of weeks, you then have outsized value to that particular organisation vs starting off as a generic code monkey somewhere else.

This is not a trap or a dillemna, its just the nature of team based software development. To not acheive this in each of your roles would be a bigger cause for concern!

I would say, if you are hiring someone to work on your big complex legacy system, you should probably attach some value to the fact that the candidate may have proven expert in exactly that scenario over the long haul in their previous role.

Succeeding in that environment takes a certain skillset, and its disingenuous to reject people for not knowing certain low level programming constructs that they wont even be using day to day. (Kernel work is one exception to this.)

Re: Programmer's Dilemma

#37

Post by [deleted] »

zhemao wrote: 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

#38

Post by VexXtreme »

When people tell me that I should "do projects in my own free time to keep my skills sharp", it throws me into a fit of rage and makes me want to tear them a new one. Do you see any other professions having to do that in order to stay employable? Can you imagine lawyers having to practice law in their free time to "keep their skills sharp"? Can you imagine civil engineers having to draft plans for bridges and buildings in order not to "destroy their ability to make a living"? Or doctors or any other high prestige professions doing anything like that?

If the answer is no, then WHY THE FUCK should I have to spend my free time maintaining a bunch of projects on Github just so I could keep providing for myself? Is what I do in my day job not good enough anymore? Now I can't even apply for a new job listing "backbone.js" as a requirement unless I have it listed in my resume or have a Github project utilizing it? Whatever happened to the notion of smart people being able to pick up and learn new technologies on the job? You think it's okay to try to offload the risk and the time necessary to pick up a new technology to an employee and their free time, vs. providing the time and the resources for learning on the job?

Tell you what OP, you can take that attitude elsewhere, I'm not buying it. I prefer spending my free time having great interactions with my friends and my girlfriend, enjoying traveling and getting new experiences and just making the most of this one life that I have. Now, If you believe that my system of values is incompatible with yours/your company's, then I don't want to work for you because you're an arrogant exploitative asshole with no respect for other people and their time/life.

This is the way you should do hiring, if you happen to have any semblance of fairness and intelligence:

If a senior person with a somewhat outdated skill set applies for a job, then you're not supposed to test them on the latest technologies, you are supposed to take a look at their track record and try to figure whether they are generally a smart person and whether they were able to get things done back in the day. If someone was a good programmer 20 years ago, then they will be just as good now, if not better, because it's ultimately a person's intelligence and attitude that determines how good a performer they are, not a list of buzzwords on their resume. If you don't get this, then I'm sorry to say, you probably aren't very bright.

Caveat: if you are moving extremely fast for some reason or need something done IMMEDIATELY, then it makes sense to hire someone who already has the skill set you're looking for. If it's a long term assignment/project, what technology they know/don't know has no bearing on how good they will ultimately perform.

PS. You have inadvertently confirmed everything another blogger wrote in a post about why a career in programming ultimately has low prestige:

http://www.halfsigma.com/2007/03/why_a_career_in.html

Re: Programmer's Dilemma

#39

Post by borplk »

invalidOrTaken wrote: post #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.

Although I partially agree, medicine and things that doctors deal with does not move nearly as fast as computig/software engineering.

I think the most important factor is the "virtual" nature of computing/software. In a relatively short period of time you can wipe everything and start from scratch.

Post reply on HN