How To Find Bad Programmers 359
AmberShah writes "The job post is your potential programmer's first impression of your company, so make it count with these offputting features. There are plenty of articles about recruiting great developers, but what if you are only interested in the crappy ones?" I think much of the industry is already following these guidelines.
Re:Crappy programmers (Score:5, Interesting)
You got modded down for this, but it's true. You get what you pay for. Just low-ball the salary or billing rate. The people who are worth anything will be kept by the employers who know better. And you'll just end up bottom-feeding. There's a reason Indian programmers are cheap. I've worked with many. Some were awesome programmers. But by far, most were just cheap. And this is true regardless of whether they're Indian or not. Cheap people are cheap for a reason.
Re:How to Find Bad Programmers (Score:1, Interesting)
The author is clueless and the article is insulting. Like your self, I'm wondering the same thing. Actually what the fuck does is this shit doing on Slashdot?
Subtly different from how to scare aware good ones (Score:1, Interesting)
Similar to the acronyms, but not scaring away mediocre developers, is playing conceptual buzzword bingo. By this I mean buzzwords relating to ideas that can actually serve useful purpose in our work, but are more often warning flags of people with a fairly trendy and superficial understanding of software design. For instance, if I see a job listing that heavy in its enthusiasm for design patterns and extreme programming, that's a major warning flag to me. They may well be top-flight, but too often are essentially hipsters who haven't done their homework -- i.e., all the latest terms, but little of the math and algorithms the underpins everything we do.
Another red flag is rote memorization questions. If you're going to ask me what the signature is for a particular method in a particular API, I'm going to be looking at every other question you ask with a lot of scrutiny because odds are that you're terrible at hiring and have put together a crap team. One of my friends told me how he, a solid engineer and project manager, had to sit through an interview being asked the difference between String and StringBuffer. If you don't understand how degrading this is for an engineer with a grad school education and 20 years experience, please realize that you're embarrassing yourself in your current profession and humiliating the candidates you're meeting. You should have the capability of determining whether a candidate knows this kind of stuff without actually making them redo quizzes from first semester CS 101.
The best team I've worked on in any type of job was put together by a guy who asked me no direct questions about APIs, rote from the Gang of Four, or what a linked list was, but just a few things about projects I'd done. Of course, it takes talent and skill to be able to do that.
Re:I see lousy coders.... everywhere (Score:4, Interesting)
Re:I see lousy coders.... everywhere (Score:5, Interesting)
You want a good coder? Look at their code. Make them take some written tests and an oral exam. Have them write you something small for free.
Maybe that is specific to rent-a-coder. I do a lot of interviewing for technical positions, and I don't give code challenges. Anything beyond CS101 fodder is too time-consuming, and asking CS101 questions doesn't really tell me anything.
I'm a big fan of "what's the difference?" questions. I'll take two similar technologies from their resume and ask what's the difference between them. It tests both the candidate's level of experience, as well as the candidate's ability to think and articulate an answer.
I have to say, I've gotten some pretty (ahem) creative responses, too. And for all you job hunters out there, if you put "C/C++" on your resume, I guarantee my first technical question is going to be, "What's the difference between C and C++?" All the while knowing that there is a >50% chance I'm about to get a "creative" answer.
Re:Just ask my boss (Score:3, Interesting)
Good question...
I had one candidate who sold their self as an experienced Business Analyst. By googling them, I found a posting by somebody with the same name, location and contact number who listed their experience as Admin Assistant with relevant skills in typing, scheduling and filing. Hardly what they claimed on their resume.
In another case I flew a candidate out for an interview, only to find that they posted to their myspace how they 'jacked' a free trip out of some sucker and were heading to Mexico for a vacation after the interview since we flew them out here.
Neither one got my recommendation, hardly grounds for any lawsuit
Re:I see lousy coders.... everywhere (Score:5, Interesting)
I later interviewed at a large corporation as a Perl programmer. I passed all the interviews, and then they wanted me to write a Perl programme to show them I actually did know what I was talking about. I took their specs, which they said should take maybe an hour to finish. It took me 7 hours. I handed it in, along with my notes on where their specs were vague and why I'd taken the route I had. I got the job and they rewrote the test after that.
Maybe I'm a good programmer or maybe I'm not, but I'm with you that programmers will be more likely to take a test when the risk/reward balance is topped to the correct side.
Re:Crappy programmers (Score:3, Interesting)
And the REALLY good people aren't available, because they've gotten sick of the crap and found a new career doing something entirely different.
Re:for a real class act (Score:2, Interesting)
I once asked someone about this and how to get around it. Their answer was to take the number of years required in the technology, add 2 and let that be your "years of experience". This will get you past HR and (hopefully) in front of a hiring manager. If the manager points out that your 8 years of Ruby on Rails experience seems unlikely, tell him what you did. If the manager doesn't laugh then you do NOT want to work for him/her.
Re:Agism rears its ugly head again (Score:5, Interesting)
Proficiency matters more than years of experience, eventually. I haven't met a single fresh-from-the-mill coder with the architectural chops to lead a project or design major systems (though I know they exist), but I've also worked with plenty of 30-or-40-something senior devs who couldn't find their ass with a flashlight and two hours with Design Patterns (and, no, I don't think that the whole world lives in Design Patterns).
There isn't just one type of good programmer, just as there isn't just one type of bad one. When I was 19 and starting my first job, sure, I wrote terrible code. When I was 22, I architected major systems that were fairly well thought out and are still in use today (I'm 30). My improvement came from having my ass kicked by some truly talented older coders.
Of course, a good dev will look at what they wrote 2-3 years ago and say "who wrote this crap?!" Someone who thinks that any more than a few tiny gems of their prior code would be up to snuff today is a crappy coder.
Comment removed (Score:3, Interesting)
Re:Crappy programmers (Score:4, Interesting)
I've had a consistent problem with indian programmers.
Regardless of quality level, they say "yes" to the most insane requirements by executives.
We had a project which three groups had internally estimated at 2400 to 4000 hours (and a couple million in new hardware).
The VP said, "it's a 600 hour project without needing new hardware!"
They said yes.
They did about $600,000 work on it- and now everyone (including the executive) is quietly ignoring it. It will never see production. It's "complete".
The indians *never* stop the executives when this comes up.
And the executives are happy because
a) they were not told no.
b) the people who worked on the project are anonymous or gone/transferred elsewhere.
Meanwhile the company just dropped 2-3% of the annual budget down a hole.
Re:Resumes in Word not hard for Java/Unix people.. (Score:3, Interesting)
I always insist on Word format. I'm filtering out programmers who will refuse to follow simple, clear shop standards just because they personally disagree with them. You know, sometimes I don't care what your arguments are about whether we should drive on the right side of the road or the left - the important thing is that we all use the same standard!
Also, you'd be amazed how many places still OCR resumes and send the text around. Word's Times font is what all the OCR software (in this domain) expects, so you look better if you use that exact body font.
Re:Step 1 (Score:3, Interesting)
Re:Resumes in Word not hard for Java/Unix people.. (Score:3, Interesting)
If you're smart enough to recognize the problems inherent in Word, you're smart enough to preview your doc with WordPad and use only the two Microsoft ur-fonts (Arial headers over Times New Roman body). You can produce a very professional resume with just those two fonts (miserable as they may be), good use of white space, and moderate use of bullet lists. Man I'm tired of sans-serif resumes with tiny margins that are nothing but bullet points (usually for 8 pages, not that I ever read past page 2).
Re:Call Bill (Score:4, Interesting)
...judging by the Microsoft engineers i've met (who were nearly all from the Mac Business Unit), they really don't have a shortage of coding talent over there. What they have is a mind-boggling surplus of bad management, starting with Ballmer.
That's something that MS doesn't have a patent on.
One of my favorite examples, that gets knowing looks from lots of good programmers: Some years back, I was hired to implement a specific standard (which one isn't important here, but you'd recognize the name). When I started, I was bemused to see written orders that explicitly included not implementing a critical part of the standard, because "it isn't needed in our system". So I did the sensible thing: I implemented the entire standard, but included a switch that disabled the part they didn't want. I was also a bit annoyed by the fact that they explicitly denied me the use of a downloadable compliance test package (which was even free).
After a while, the project was working well enough that they delivered the first release to several customers. Among the bug reports, every customer included the fact that my part didn't pass their compliance test (which was the one I'd been denied access to), and they explicitly noted the one part that didn't work at all, which was of course the part I'd been ordered not to implement. Every customer said they wouldn't accept the product until that part was working. I got a "top priority" request asking how quickly I could implement the missing feature. I flipped the switch in my test setup, thoroughly tested it, and reported a few days later that it was ready for delivery. My managers were duly impressed by how quickly I'd done it, and the customers all accepted it.
A few months later, they were setting up for the product's "2.0" project. I noted that my standard was included, and that they again explicitly required that I not implement that one part that they "didn't need".
I sent my resume around, and a few weeks later, told them that I wouldn't be working on release 2.0.
It's interesting how many of the good programmers that I know have stories very similar to this. And most of them don't work for Microsoft.
Comment removed (Score:3, Interesting)
Re:I see lousy coders.... everywhere (Score:3, Interesting)
brilliant but unmaintainable code
I've read most of your comments in this thread and largely agree with you. However, there is no such thing as brilliant but unmaintainable code. Brilliant code is typically something you would never have thought of doing, but what it does and how to change it is immediately obvious when you look at it.
I worked with a guy who was very smart and could solve problems that most of the rest of the staff would have trouble with... and I advocating firing him because it was less of a time drain for me to help the other guys figure out a good way to solve the tough problems they ran into than it was to help them figure out what the hell genius boy had done. Most of his code required total rewrites in order to make useful changes. I suspect you meant that kind of coder. Solving difficult problems does not necessarily amount to brilliant code, and sometimes simple problems can have brilliant solutions.
Re:Crappy programmers (Score:3, Interesting)
This is true, and it's a problem which needs addressing. Keep in mind that they didn't say "yes" because they're ignorant, stupid, or bad coders. They may in fact be some or all of those things (which is a different issue), but those things are most likely not why they said "yes"; they did it because they're Indian.
Note that I say this not as an Indian but as an expat who's been in India for a bit more than a year now. There are ridiculously complex reasons why this behavior exists (it's a multi-thousand year-old culture with a billion people; nothing's simple), but the treatment of the summary of the precis of the cliff's notes (which is pretty much all a single year here will give you) is that the junior folks, especially those who have not worked for US companies before, make the assumption that if they're being asked to do something then it must be doable because the people in power asked them to do it. Or at the very least, they're not going to call out the people in power of for thinking that it's possible.
My advice? If you're working for a company which is running into this problem, make a very concerted effort to convince management to invest in Indian cultural training for your staff (both domestic and Indian) and ensure that management takes these classes as well. The cultural disconnect which exists between India and western countries in general (and the U.S. in particular) is huge, and throwing folks into a stewpot together and thinking things will just work is foolish.
Having been to India twice (once on short-term assignment with no cultural prep and now again on a long-term assignment with several days of cultural prep), I can tell you the training makes a world of difference.