Slashdot Mirror
Why the New Guy Can't Code
theodp writes "'We've all lived the nightmare,' writes Jon Evans. 'A new developer shows up at work, and you try to be welcoming, but he can't seem to get up to speed; the questions he asks reveal basic ignorance; and his work, when it finally emerges, is so kludgey that it ultimately must be rewritten from scratch by more competent people.' Evans takes a stab at explaining why the new guy can't code when his interviewers and HR swear that they only hire above-average/A-level/top-1% people. Evans fingers the technical interview as the culprit, saying the skills required to pass today's industry-standard software interview are not those required to be a good software developer. Instead, Evans suggests: 'Don't interview anyone who hasn't accomplished anything. Ever. Certificates and degrees are not accomplishments; I mean real-world projects with real-world users. There is no excuse for software developers who don't have a site, app, or service they can point to and say, 'I did this, all by myself!' in a world where Google App Engine and Amazon Web Services have free service tiers, and it costs all of $25 to register as an Android developer and publish an app on the Android Market."
This reminds me of the old expression "I can't get the job because I don't have any experience, but how can I get experience if they don't give me a job?"
Yes, on your own, but it is still saying "don't hire someone directly out of school" without considering that there are some advantages to this, such as being able to integrate someone into your system, before they have had the chance to develop "bad habits".
Tequila: It's not just for breakfast anymore!
If you don't have experience we won't hire you ? I might be naive, but isn't by getting a job you get the experience? Yes I do agree that you don't hire someone who just got out of college to code for the next super secret OS, but you can't expect everyone to be the that good right away.
Firstly, why is this a nightmare? Who wants extra competition?
Secondly, "technical interview" is a misnomer. They're actually "potential colleague" interviews. Who is going to pick someone who is smarter than them, or who is going to give them competition for promotion?
Those who get through technical interviews are either smart enough to bluff to the interviewer that they're not quite as smart as the interviewer, but an ok guy to hang out with; or are genuinely not as smart or talented as the interviewer, but are an ok guy to hang out with.
Quick tip: when you attend a technical interview, answering the questions correctly doesn't get you the job. Being amazed at how much the interviewer knows does.
I usually say that it doesn't matter what you know, what matters is how fast you learn. Someone who you can teach and tell how to do things once, and they actually understand the message and do it right from then on is much more valuable in the long run then someone who has a (short and) static merit list in my opinion.
Life is Reality
There is no excuse for software developers who don't have a site, app, or service they can point to and say, 'I did this, all by myself!' in a world where Google App Engine and Amazon Web Services have free service tiers, and it costs all of $25 to register as an Android developer and publish an app on the Android Market."
There is no excuse for self-proclaimed software authorities who don't know that software development covers much more than just Web-related or mobile apps. I've been developing software since before the Web was invented and I still don't have a website, I don't write apps for Android and there's no service on the Internet that I can point to and say "I did that all by myself!" I'm a systems programmer and I make a nice living writing code for embedded systems that make it possible for this Evan guy to post his ridiculous rants on the Internet.
If someone who's clever enough and can program is still a drag on productivity then it sounds like a problem of technical management in providing appropriate tasks, guidance and training. If you're in need of urgent productive programming (and / or you're a small start-up - *maybe*) then, yes, hire someone with substantial experience so you get returns quickly. Otherwise, it's your job to train them in stuff they might not know. Industry used to be responsible for training and educating workers appropriately beyond their academic career.
New guys do not get senior pay. People with experience usually command higher wages.
You can get people out of school fairly priced to their abilities. That fair price can be significantly under what an accomplished senior engineer will make.
The best question is, "Who are you fishing for and why?"
Hopefully your company is willing to spend the coin for the experience implied by this article.
If not, your company may see the time slow down as worth it. From an investment side, management must consider timing of future cashflows and likelihood they will arrive (risk). Slow and steady can win the race, despite how frustrating it can be to 'bring someone else up to speed.'
Isn't this old hat? Doesn't everyone ask for a code sample?
I feel however that 'I did this, all by myself!' isn't the best metric.
I'd rather hire the kid who's code sample consists of fixing 5 memory leaks in 5 different open source libraries. He'll write solid code.
I'd rather not hire as a "coder" the kid who's website took him 40 hours in photoshop, several hours configuring Drupal, and another several hours writing a Drupal extension that should've taken him 20 min. He might be more artist than programmer.
In fact, that's a pretty good interview tactic : Ask them in advance to find & fix a memory leak in some open source C library so they can explain it at the interview. Hint : Find a crap library with many leaks.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
Wow, a footnote devoted to a dig about Hungarian Notation, with a link to Wikipedia, and a display of complete ignorance of the subject. The Wikipedia article that he went to the trouble of linking to, while deriding the inventor of the notation, tells you that there are two forms, Apps Hungarian and Systems Hungarian, and no doubt goes on to tell you that the person that he is deriding invented Apps Hungarian. The point of this notation is to include units in variable names. For example, you might prefix a length with m or ft to indicate the units, or an index with row or col. It's then completely obvious that an expression like mHeight -= ftDistance is wrong. This is a very sensible convention and eliminates some very expensive yet simple to fix bugs. The author of the article calls it 'probably the dumbest widely-promulgated idea in the history of the field', which makes me quite glad that I don't work with him.
He's probably thinking of Systems Hungarian, which is what happened when the systems group at Microsoft got ahold of the idea and started prefixing things with their types (language types, not semantic types), which is completely redundant information.
I am TheRaven on Soylent News
There are definitely some people out there who are annoyingly incapable and inept. Cert chasers and the like don't even realize they are what they are -- they were sold on the belief that if they attend and complete classes, that they will somehow have ability and knowledge. (I think I will take a class on weghtlifting and compete in Mr. Universe. or something...) Worse, I have never seen one of these people "become" a skilled and seasoned professional later on.
Success invariably hinges on a person's ability to think, learn and understand in the ways needed for their profession to be effective. Those are things that are difficult, if not impossible to measure by someone who doesn't have an in-depth understanding of the materials themselves. And yet, all too often, the people who are in charge of hiring such people are the very people who are completely unqualified to make such assessments. (Of course, this idealism ignores that politics can get many people around the requirements of skills, knowledge and understanding.)
Lack of shame is another problem that these unqualified employees display... or is lack of shame OUR perception? I know I would feel shame if I inserted myself into a situation where I was not qualified. But maybe that's just me and a bunch of other like-minded geeks here on slashdot. (Then again, when I insert my opinions here and someone with greater knowledge calls me an idiot, I don't often feel much shame... though some form of hate or anger results at times.)
I guess what I am getting at is that no matter what level you or another are at, someone else will be better or worse. There's a great thing about humans, as it turns out, though -- we are good at teaching each other things -- from what I have learned recently, that seems to be the "one thing" that humans have that other animals don't -- and we have the capacity to build on knowledge from our predecessors. But this knowledge is important for growth -- people with academic backgrounds have their place. ("Relevance" of academic knowledge is another matter though.)
I definitely identify with the problem and the solution(s) depends on the individuals with the problems. Sometimes "giving them enough rope" is the best answer. Other times, coaching them over their deficiencies is the best way. It's always a tough call.
No, I've managed and worked with many incompetent woman coders. I've also managed and worked with good women coders. They are just a much smaller percentage of the work force.
Unfortunately, unlike an artist or musician or copywriter, most programmers' finest work isn't intended to be publicly shown, since it may be regarded as a trade secret. Which puts both employers and coders in a bad position. And while a personal website may be useful to demonstrate certain talent, it won't help showcase work in proprietary languages for which one may be seeking employment.
..as a programmer?
That question is one of the best filtering questions around.
I'm god, but it's a bit of a drag really...
If you want to get a job programming, but have never written any software that you've published, then you are probably not worth hiring
This is just plain crap, I've been programming for almost 30yrs, proffesionally for the last 20. I don't have any published code to show anyone at an interview, and never have. The stuff I write in my own time is mainly so I can learn something new, once I have the gist of it I usually throw the code away. I've also interviewed ~100 programmers over the years and if you can't tell if someone knows their stuff just by talking to them for 5-10min, then I suggest you don't know yours.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
I think a lot of comments are lashing out at the "Don't Hire Inexperienced Developers" concept without really thinking about what's being said in the rest of the article.
What the author is really saying is "Don't hire developers fresh out of school who have nothing to show for themselves except coursework."
Why is this so important? It's important because it shows two things:
1) The developer only has theoretical, academic knowledge of programming
2) The developer isn't passionate about developing.
The first is a huge problem for any company hiring said developer. I don't know a single instance where what I have encountered in the working world matched closely at all to how my textbooks or professors told me things "should be". The mental shift required between school and work is large and can be very difficult to overcome for many.
The second point is a critical thing to consider especially if you're a small company or a startup. A-level developers and other IT folks are passionate about what they do. They have side projects. They have little tools and such that they create to help solve whatever task they're focusing on at the moment. Coming out of school with absolutely nothing beyond class assignments is a strong indicator that the developer is only interested in the bare-minimum requirements to get by. That's not to say they're not talented, just that they're looking for a 9-5 job where they're in at 9:00 and out at 5:00 and aren't interested in going the extra mile. These guys are terrific coders for large companies where there's a lot of maintenance type work to be done. They're productivity vampires though for small companies that need every member of the team to be highly efficient and high producing.
The article points out how easy it is to have side projects. To turn out a little app on a website or on a mobile platform that you can point back to and say "I did this."
To those who argue that there's just no time in a 4 year degree to do side projects like that... Where the hell did you go to school? Did you have a full-time 40hr/wk job totally outside of CS/IT during the same period that left you with only enough time outside of class to sleep? If MIT students can get through in 4 years and manage massively complex pranks, contribute to OSS projects and still graduate with high grades, what's everyone elses excuse?
Those who have written something for their own amusement or curiosity, something not part of work or a class assignment.
Are interviewees permitted to bring in their own laptop computers on which to demonstrate "something [written] for their own amusement or curiosity"?
For me, no. I don't want to see the code. I want to have a conversation about the code. How were things implemented, what problems came up, anything particularly cool about the implementation, what was fun, what was not fun? I think the conversation is more revealing, code can be someone else's. Or if written purely for your own amusement it might be crudely slapped together and not truly representative of a person's professional efforts.
I once ran an employment ad "Send us a thousand lines of C++ that you're proud of". Very few people submitted code. Lots of excuses, though. What I was looking for in code, incidentally, was proper paranoia. This was an embedded project for a large machine, and I wanted to see conservative code that would clearly not do bad things. I actually sent one application back with "Your application has been received. Your first buffer overflow is on line 22. Thank you for your interest."
I once encountered an applicant who claimed to be an experienced C++ programmer, and sounded convincing. I sat him down at a computer, demonstrated how to type in, edit, and compile "Hello World" in that environment, and asked him to code something. Anything. He got stuck at "int main...".
Replace "New Guy" with "applicant" ("experienced" or otherwise) in the title and you will basically have something that tech company interviewers have been noticing for a while:
The article is good reading, and links to the even more controversial supposition: a large percentage of people *cannot* be taught to program. Highly recommended reading; both of those links would make for good slashdot fodder, if they haven't been posted already.
Nathan's blog
Apprenticeship is dead. How dare someone with a degree and a few certs look for a job.