Be careful young bucks ... you're looking at yourself in 10 years. The fix to this is company development programs ... not doing fake interviews (for real?) and switching teams.
Programmer's Dilemma
11–20 of 113 posts
Re: Programmer's Dilemma
#12Although 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…
Re: Programmer's Dilemma
#13I wish people would use spell check when they write headlines for blog posts.
Cut him a break, English is clearly not his first language.
The situation seems quite analogous.
Re: Programmer's Dilemma
#14Re: Programmer's Dilemma
#15I 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…
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 blood pressure, and their evenings and nights are taken up with family duties.
It's an all-or-nothing approach; spend all your waking hours on your job, or have a life. One's healthy, one isn't. One will keep you employed in the IT industry past 40, the other won't.
And yet, we hear IT companies complaining that they don't have enough talent and trotting out the old "old programmers can't learn new tricks" schtick. Instead of developing the employees they have, they want more input into the front of the system while they shuffle the 90% of programmers who don't become "greybeards" and aren't "management material" off into suboptimal jobs doing 4-hour response hardware service.
Re: Programmer's Dilemma
#16Earlier quoted context omitted.
Cut him a break, English is clearly not his first language.
I'd be inclined to cut him a break, except that he doesn't seem to cut a break for developers parachuted into his milieu. The situation seems quite analogous.
Re: Programmer's Dilemma
#17Although 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…
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.
Re: Programmer's Dilemma
#18I wish people would use spell check when they write headlines for blog posts.
Re: Programmer's Dilemma
#19If the only goal is to push the current project out the door, then reimplementing a hash table or a chunk of printf is pointless. But that sort of thing from time to time keeps you from treating all these things as opaque black boxes.
Re: Programmer's Dilemma
#20Although 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…
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.