11 ms·

Programmer's Dilemma

134 points by CoryG89 13y ago

nikster 13y ago
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.
- mdkess 13y ago
  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.
- corresation 13y ago
  The worst programmers also work for small companies, because it's easy be a big fish in a small pond, etc. Or maybe there are varied workers at various levels in various organizations. No simple rule satisfies.
tled 13y ago
"We are captives of our own identities, living in prisons of our own creation" - a quote by T-Bag in Prison Break
c0deporn 13y ago
Interesting article. I actually have a talk that I give about this exact issue. I laugh at anyone [developers] who calls themselves an "expert" unless it's followed by a very specific, narrow topic. I dislike the title "Senior" when discussing developers because it's usually just a title given to those who have 1) been there there at least 3 years or 2) Have n years of development related experience on their resume. The problem is, the title is associated with level of assumed expertise. As the article says, these guys can barely answer a basic question. However, that's not to say that they don't know how to be productive or produce quality results. It wouldn't be so bad if developers just went out and read someone else's code or attended a code camp or user group, but they don't.
wyclif 13y ago
I wish people would use spell check when they write headlines for blog posts.
- jonnathanson 13y ago
  Google seems to indicate the author is (was?) in Beijing, and I'm guessing that English is not his first language (reading the post seems to bear this out). It's a valid point, but I'd give him a tiny bit of leeway in this case.
  - zhemao 13y ago
    You don't need to Google his name, even. He says he's in Beijing at the end of the first section. Presumably wyclif was so turned off by the spelling mistake in the title, he decided not to read any of the article itself.
    - wyclif 13y ago
      I read the article, and I knew it was Chinese in origin.
      - zhemao 13y ago
        Haha, sorry, I was just having a joke.
- 67726e 13y ago
  Cut him a break, English is clearly not his first language.
  - tzs 13y ago
    I don't see what that has to do with not using spell check. Wyclif is not criticizing the author for not knowing English spelling--he's criticizing him for not using spell check.
rogerbinns 13y ago
This is also the source for some of the fizzbuzz issues. It is astonishing how hard some people find it to make a computer print one through one hundred, never mind adding the flow control correctly.
zhemao 13y ago
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 think anyone without superhuman coding chops would be able to implement an LRU cache framework in one hour using a C library they have no experience with.
- nikster 13y ago
  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.
- plorkyeran 13y ago
  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.
  - vladimirralev 13y ago
    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.
    - nikster 13y ago
      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?
chidevguy 13y ago
Completely agree. The other problem I've seen with getting stuck on the same project for X years is that you'll have a very limited portfolio to show for it, unless you're working on side projects as well.
- kb19 13y ago
  If you are on a project for a few years (and aren't doing just maintenance, in which case I'd GTFO) you should be able to show a roadmap of where you took the project, its success etc. which might not be so bad.
pcunite 13y ago
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 company development programs ... not doing fake interviews (for real?) and switching teams.
- karlkatzke 13y ago
  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 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.
  - deleted 13y ago
    [deleted]
    - Retric 13y ago
      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.)
deleted 13y ago
[deleted]
mikeash 13y ago
This is part of why I just occasionally reimplement chunks of existing libraries. It's fun, gives me something to write about, and keeps me sharp. If 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.
invalidOrTaken 13y ago
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.
- borplk 13y ago
  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.
  - jerf 13y ago
    If you do it right, by the time you hit 40 you understand that programming doesn't actually move that fast. The superficialities are churning rapidly, but there's an underlying truths are quite stable. They are moving, too, but much more slowly. For instance, take JS frameworks. On the one hand, they're churning so fast that nobody could possibly keep up with them all. On the other hand... they're all just shuffling the same basic primitives around in various combinations, and exploring spaces hardly any different than their desktop brethren 20 years in the past. There have been cases where I've successfully predicted the failure case of the latest JS wonderthingy just by listening to how it works. For instance, five minutes after I heard Node described I knew about Callback Hell, even though the term as such did not enter the lexicon for about another year and half. I could also tell you exactly what the proposed solutions were going to be, what their advantages and disadvantages would be, and almost completely called what order they would be tried in, because it was all just a recapitulation of experiences had in other communities. From the surface it looks like Node has been in wild churn, with more understanding it's merely a turn of the wheel of history. As an example of the other side, DRY isn't going anywhere, and developing your DRY-vision is the work of a decade. (It goes way deeper than most people seem to realize.)
benjaminwootton 13y ago
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.)
VexXtreme 13y ago
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 http://www.halfsigma.com/2007/03/why_a_career_in.html
rvijapurapu 13y ago
Most good developers can barely remember a line of code, they usually have a general idea as to how you could implement aspects a concept and build on it as they go. Incremental changes
onan_barbarian 13y ago
There is a fundamental disconnect of reasoning here. What we are expected to believe is that these people at their "big, name-brand companies" are carrying on an elaborate hoax on their employers and their inability to do blank page coding exercises reveals their fundamental uselessness. Possibly, the truth might be that the majority of serious work is done under conditions where you are used to your framework and, frankly, can easily forget how exactly to fire up a editor and write code to solve a toy problem. One might say this reflects more poorly on the interview process than the interviewee. The idea that there is some special magic "creativity" involved in this kind of blank sheet programming that is never required when programming within a well-established framework is pure hokum. We have a lot of well-established practices in our code base that allow us to bust out a new and sophisticated graph analysis or transformation in precious few lines of code - meanwhile, the blank sheet guys are self-congratulating because they know how to call glib's hash functions in a clean sheet environment. B... F... D... (and I don't mean the library)
bcantrill 13y ago
I've done kernel implementation for 20 years, and this question is absolutely terrible -- unless the answer that one is looking for is an intelligent explanation of why this is such a terrible question. It's an awful question because the kernel may not be involved at all on a user-level call to malloc() (e.g., a caching allocator like libumem or a traditional allocator that needn't extend the break for a given allocation), may be involved in a minor capacity if the break must be extended (on most systems, a system call and some VM interaction), or could be involved substantially if the allocator is a mapping allocator and page faults are induced (text and data) or scheduling events or anything else that necessitates kernel involvement. For whatever it's worth, when I have historically interviewed university hires for kernel positions, the question I ask is much simpler; namely, what does "* ((int *)NULL)" do? Sadly, most university students -- even ones who have done very well in their university computer science courses -- don't get this right. And it's sad because it's not really the question, but rather just the segue to the actual question: when a candidate correctly answers that NULL is dereferenced and the program crashes[1], I ask them to write the program (statement, really) in an assembly of their choosing (most graduates have MIPS or SPARC on the resume) and I then ask for everything that happens between the execution of that instruction and the resulting core dump and return of control to the shell. With a qualified candidate, this could easily be a multi-hour jaunt through microprocessor architecture and operating systems implementation. All of that said: I don't really do that anymore, but rather look to a candidate's open source works. The last kernel engineer I hired had done open source work that was so impressive that my interview consisted only of me determining that he had done the work himself -- which took all of 30 seconds or so. (He had, I hired him and he's been an absolutely terrific engineer.) Easiest interview ever! [1] Except on AIX and any other asinine system that maps NULL.
- gizmo686 13y ago
  >what does "* ((int * )NULL)" do Technically speaking, that is undefined. "If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined...Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer,..."[1] [1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf page 79
rabino 13y ago
Maybe programmers rotating every 2 years is what drives companies to have more and more stable frameworks.
cptFalco 13y ago
It is kind of interesting seeing the difference between approaches that other tech interviewers use - the following was one that I saw today on linkedin: http://firstround.com/article/The-anatomy-of-the-perfect-technical-interview-from-a-former-Amazon-VP http://firstround.com/article/The-anatomy-of-the-perfect-tec... I think that it needs to be a combination of 1) what is on your resume as you become an expert in a fairly specialised piece of technology and on 2) general knowledge. I feel a bit sorry for the guy who had to write the LRU cache. I have been in unfamiliar surrounds before and come across as a blathering idiot, and I didn't feel it was 100% my fault. The interviewer has some responsibility in trying to understand the background of the person, and is not there to show how smart he is.

134 points by CoryG89 13y ago

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.

mdkess 13y ago
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.
corresation 13y ago
The worst programmers also work for small companies, because it's easy be a big fish in a small pond, etc. Or maybe there are varied workers at various levels in various organizations. No simple rule satisfies.

tled 13y ago

"We are captives of our own identities, living in prisons of our own creation" - a quote by T-Bag in Prison Break

c0deporn 13y ago

Interesting article. I actually have a talk that I give about this exact issue. I laugh at anyone [developers] who calls themselves an "expert" unless it's followed by a very specific, narrow topic. I dislike the title "Senior" when discussing developers because it's usually just a title given to those who have 1) been there there at least 3 years or 2) Have n years of development related experience on their resume. The problem is, the title is associated with level of assumed expertise. As the article says, these guys can barely answer a basic question. However, that's not to say that they don't know how to be productive or produce quality results. It wouldn't be so bad if developers just went out and read someone else's code or attended a code camp or user group, but they don't.

wyclif 13y ago

I wish people would use spell check when they write headlines for blog posts.

jonnathanson 13y ago
Google seems to indicate the author is (was?) in Beijing, and I'm guessing that English is not his first language (reading the post seems to bear this out). It's a valid point, but I'd give him a tiny bit of leeway in this case.
- zhemao 13y ago
  You don't need to Google his name, even. He says he's in Beijing at the end of the first section. Presumably wyclif was so turned off by the spelling mistake in the title, he decided not to read any of the article itself.
  - wyclif 13y ago
    I read the article, and I knew it was Chinese in origin.
    - zhemao 13y ago
      Haha, sorry, I was just having a joke.
67726e 13y ago
Cut him a break, English is clearly not his first language.
- tzs 13y ago
  I don't see what that has to do with not using spell check. Wyclif is not criticizing the author for not knowing English spelling--he's criticizing him for not using spell check.

rogerbinns 13y ago

This is also the source for some of the fizzbuzz issues. It is astonishing how hard some people find it to make a computer print one through one hundred, never mind adding the flow control correctly.

zhemao 13y ago

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 think anyone without superhuman coding chops would be able to implement an LRU cache framework in one hour using a C library they have no experience with.

nikster 13y ago
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.
plorkyeran 13y ago
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.
- vladimirralev 13y ago
  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.
  - nikster 13y ago
    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?

chidevguy 13y ago

Completely agree. The other problem I've seen with getting stuck on the same project for X years is that you'll have a very limited portfolio to show for it, unless you're working on side projects as well.

kb19 13y ago
If you are on a project for a few years (and aren't doing just maintenance, in which case I'd GTFO) you should be able to show a roadmap of where you took the project, its success etc. which might not be so bad.

pcunite 13y ago

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 company development programs ... not doing fake interviews (for real?) and switching teams.

karlkatzke 13y ago
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 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.
- deleted 13y ago
  [deleted]
  - Retric 13y ago
    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.)

deleted 13y ago

[deleted]

mikeash 13y ago

This is part of why I just occasionally reimplement chunks of existing libraries. It's fun, gives me something to write about, and keeps me sharp. If 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.

invalidOrTaken 13y ago

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.

borplk 13y ago
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.
- jerf 13y ago
  If you do it right, by the time you hit 40 you understand that programming doesn't actually move that fast. The superficialities are churning rapidly, but there's an underlying truths are quite stable. They are moving, too, but much more slowly. For instance, take JS frameworks. On the one hand, they're churning so fast that nobody could possibly keep up with them all. On the other hand... they're all just shuffling the same basic primitives around in various combinations, and exploring spaces hardly any different than their desktop brethren 20 years in the past. There have been cases where I've successfully predicted the failure case of the latest JS wonderthingy just by listening to how it works. For instance, five minutes after I heard Node described I knew about Callback Hell, even though the term as such did not enter the lexicon for about another year and half. I could also tell you exactly what the proposed solutions were going to be, what their advantages and disadvantages would be, and almost completely called what order they would be tried in, because it was all just a recapitulation of experiences had in other communities. From the surface it looks like Node has been in wild churn, with more understanding it's merely a turn of the wheel of history. As an example of the other side, DRY isn't going anywhere, and developing your DRY-vision is the work of a decade. (It goes way deeper than most people seem to realize.)

benjaminwootton 13y ago

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.)

VexXtreme 13y ago

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 http://www.halfsigma.com/2007/03/why_a_career_in.html

rvijapurapu 13y ago

Most good developers can barely remember a line of code, they usually have a general idea as to how you could implement aspects a concept and build on it as they go. Incremental changes

onan_barbarian 13y ago

There is a fundamental disconnect of reasoning here. What we are expected to believe is that these people at their "big, name-brand companies" are carrying on an elaborate hoax on their employers and their inability to do blank page coding exercises reveals their fundamental uselessness. Possibly, the truth might be that the majority of serious work is done under conditions where you are used to your framework and, frankly, can easily forget how exactly to fire up a editor and write code to solve a toy problem. One might say this reflects more poorly on the interview process than the interviewee. The idea that there is some special magic "creativity" involved in this kind of blank sheet programming that is never required when programming within a well-established framework is pure hokum. We have a lot of well-established practices in our code base that allow us to bust out a new and sophisticated graph analysis or transformation in precious few lines of code - meanwhile, the blank sheet guys are self-congratulating because they know how to call glib's hash functions in a clean sheet environment. B... F... D... (and I don't mean the library)

bcantrill 13y ago

I've done kernel implementation for 20 years, and this question is absolutely terrible -- unless the answer that one is looking for is an intelligent explanation of why this is such a terrible question. It's an awful question because the kernel may not be involved at all on a user-level call to malloc() (e.g., a caching allocator like libumem or a traditional allocator that needn't extend the break for a given allocation), may be involved in a minor capacity if the break must be extended (on most systems, a system call and some VM interaction), or could be involved substantially if the allocator is a mapping allocator and page faults are induced (text and data) or scheduling events or anything else that necessitates kernel involvement. For whatever it's worth, when I have historically interviewed university hires for kernel positions, the question I ask is much simpler; namely, what does "* ((int *)NULL)" do? Sadly, most university students -- even ones who have done very well in their university computer science courses -- don't get this right. And it's sad because it's not really the question, but rather just the segue to the actual question: when a candidate correctly answers that NULL is dereferenced and the program crashes[1], I ask them to write the program (statement, really) in an assembly of their choosing (most graduates have MIPS or SPARC on the resume) and I then ask for everything that happens between the execution of that instruction and the resulting core dump and return of control to the shell. With a qualified candidate, this could easily be a multi-hour jaunt through microprocessor architecture and operating systems implementation. All of that said: I don't really do that anymore, but rather look to a candidate's open source works. The last kernel engineer I hired had done open source work that was so impressive that my interview consisted only of me determining that he had done the work himself -- which took all of 30 seconds or so. (He had, I hired him and he's been an absolutely terrific engineer.) Easiest interview ever! [1] Except on AIX and any other asinine system that maps NULL.

gizmo686 13y ago
>what does "* ((int * )NULL)" do Technically speaking, that is undefined. "If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined...Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer,..."[1] [1]http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf page 79

rabino 13y ago

Maybe programmers rotating every 2 years is what drives companies to have more and more stable frameworks.

cptFalco 13y ago

It is kind of interesting seeing the difference between approaches that other tech interviewers use - the following was one that I saw today on linkedin: http://firstround.com/article/The-anatomy-of-the-perfect-technical-interview-from-a-former-Amazon-VP http://firstround.com/article/The-anatomy-of-the-perfect-tec... I think that it needs to be a combination of 1) what is on your resume as you become an expert in a fairly specialised piece of technology and on 2) general knowledge. I feel a bit sorry for the guy who had to write the LRU cache. I have been in unfamiliar surrounds before and come across as a blathering idiot, and I didn't feel it was 100% my fault. The interviewer has some responsibility in trying to understand the background of the person, and is not there to show how smart he is.