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!
Even with a few Open-source projects under your belt for others to check out you might still be a crappy coder but at least they've got more chance to see what they're getting into.
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.
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.
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.
why the new guy can't code when his interviewers and HR swear that they only hire above-average/A-level/top-1% people.
Human Resources has nothing to do with filtering candidates, except possibly at the coarsest of levels. HR doesn't make decisions about hiring or firing. All they do is manage payroll and group benefits and stuff like that. What would they know about the skills and experience needed for being able to code well? Hiring and firing decisions are made by the head of the department. If he or she is winding up with people who can't code, then the blame belongs squarely with the interviewers and the interview process, not HR.
When our name is on the back of your car, we're behind you all the way!
Companies are consciously creating incompatible platforms (Android, iOS, WP7, Flash, Silverlight, ...) in order to make developer skills non-transferable. Nobody should be surprised to hear that it costs more time to train new developers.
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?
Applications you've made because of a school project will not count.
Why not? Because someone else provided the specifications? Isn't that what corporate software development is built around? Not to mention that school projects are done in teams, so your contribution to that team can show how well you will work in a dev team? Soloist codemonkeys do not good employees make.
Neither do people who went into programming because someone said it is a good career path. A certain curiosity and interest in the field is required. These personal projects don't need to be elaborate. Its just that a complete lack of anything written for personal amusement or curiosity also suggests a lack of interest in the field.
Also in team projects those with genuine interest tend to carry those on the career path. So all team projects and nothing personal can be worrisome.
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 think this is a good question, but I'm having a little bit of trouble answering it and I think this demonstrates a weakness of this particular question.
I'm a relatively new programmer, just out of college working at my first job. I have several past programming accomplishments that I could choose from, but I'm sort of ashamed of all of them. Why? I've been getting better and better as time goes on, so when I look back at my past work I'm extremely critical. My previous work sucked compared to my present work. That's not to say my past work wasn't valuable, as I had to work on these previous projects to learn what I know now. Also, my past work isn't objectively bad (or so I've heard from others). However, when asked this question I sit there and think about it for several minutes and eventually it becomes "what am I least ashamed of?" rather than "what am I proudest of?". I'm also tempted to answer with something like "getting through school" (which I am actually proud of due to all the hard work I put into it, and I see as programmer related)...but I bet this is one of the worst possible answers to give a recruiter.
I'm like an artist who has trouble putting together a portfolio because I want to sweep my entire learning process under the rug, but has little to no present work to stick in the portfolio. Even worse, anything I do now will probably end up being heavily criticized by my future self, putting me back in the same boat. I think it is likely that many skilled programmers that are just getting started have this issue, as programming is a creative endeavor and I see this all the time in other creative endeavors. It's sort of the inverse of the Dunning–Kruger effect...whereas the incompetent can't tell how awful their work is, the competent see all the itty-bitty problems in their work in gruesome detail. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
The weakness of this question is that it is not orthogonal. It is testing for skill, self-confidence, and a lack of perfectionism all at once. Unfortunately, slightly low self-confidence and a high degree of perfectionism can be positive attributes in a worker (as long as these attributes aren't so extreme as to be crippling). Too high a degree of self-confidence can lead to interpersonal conflict...or can lead to the situation where the person wastes a ton of time trying to do something themselves when it could have been easily resolved by talking to someone else. A degree of perfectionism prevents sloppy work being passed off as sufficient and leads to a constant drive for improvement (though of course it can also lead to irrational decisions about putting effort into something long after the law of diminishing returns kicks in).
It's still a good question, but you need to make sure that you account for people who would deal with this problem poorly precisely because they are skilled, otherwise you might let a gem slip through your hands.
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