Slashdot Mirror
How To Find Bad Programmers
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.
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.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
It is VERY rare, but I did run into one company that posted a sort of puzzle. It was a screen scrapping test with several layers. They did things like inserted hints in custom headers and if you didn't notice those, you would go on following the trail who knows how long to get to the end, which was a the email address to send your resume. So it only took about 30 min to do if you knew your stuff, it could take all day and more if not. It was FUN! btw I got the email address in about 2 hours, I did go down the wrong path for a bit and then went back and started looking at headers and cookies and found the clues.
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.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
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
Wherever You Go, There You Are
Early on in my career, I showed up for an interview. I drove 30 minutes to get there, was in my suit, and ready to rock. I got there, and the front desk person handed me a 10 page document, and told me to sit down and fill it in. I hadn't even met anybody else yet. It was a programming test. I filled in a page or two, decided I didn't want to work at a place like that, and walked out.
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.
www.clarke.ca
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.
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.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
...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.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
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.