The time of year has rolled around once more where gift-giving is the order of the day. Sure, this is a shameless plug (have I ever claimed to be shameful?), but I can’t think of a better gift for your friend, spouse, colleague, or manager than my book – Design, Code, Test, Repeat. It’s probably the funniest book about software you’ll read, but it’s also informative. I introduce you to my friends’ and my best and worst experiences in over 20 years of software development and management.
Here’s just a sampling of the topics in the book:
- Interviewing – How to suck and how not to suck at it. In these times of job-hunting and layoffs, avoiding mistakes and steering interviews are invaluable skills.
- Handling yourself professionally on the job and dealing with process, projects, and people.
- Best practices for your projects.
- Best practices for your career.
Not only is there a wealth of information, but to keep things fun, it’s filled with small cartoons and drawings. For your perusal, I’m including another small excerpt. Here’s a story about a friend, Bob, who was interviewing a guy for a software position.
Bob was interviewing people for a position on his team and found a guy named Ivan who was about to graduate with a Ph.D. in computer science from a nearby university. In the past, they had had some very good luck hiring smart people who were lacking in some software experience and teaching them how to write software. If you have an engineering background, you’ve probably done a bit of programming in school anyway and the problem-solving skills are useful in both fields. This guy even had a background in computer science, so while his practical experience seemed to be lacking, he seemed promising.
They had Ivan come in for a half day of interviewing. He was polite and likeable, but clearly lacking in experience – pretty much what we expected. The problem was that for a guy who had very little practical experience, he had a philosophy about everything. He’d say things like, “My philosophy on starting a new coding project is to sit down and do some rough design work before starting a prototype.” It sounds reasonable enough doesn’t it? But since he’d never had a real job, it was a bit questionable. Additionally, his answers to most of the other questions were just vague philosophies as well. Now this guy had been a teaching assistant for a Java class, so he should have been able to come out with something concrete based on his work on a Ph.D. in computer science, right?
Unfortunately, they didn’t do a great job that day of really testing his Java coding skills. Instead, even though they had doubts, they hired him under the assumption that like our other people fresh from school that the equations:
Education = Brain
Brain + Mentoring = Future Valuable and Productive Employee
would hold true. It didn’t. The guy couldn’t code his way out of a paper bag. They tried to get his feet wet by having him check some code out of our source code repository, copy and paste some changes into the files, compile and test them, then check them back in. Believe it or not, he needed help with the copying and pasting part. Not how to use copy and paste tools, but finding the same code in the other files and putting the right code in there. After giving him several mentors, having him audit another Java course, and giving him 9 months (much too generous) to get up to speed, they had to give up and let him go. He went back into academia and is a Professor somewhere now. He was indeed a smart guy, but just wasn’t made for the kind of work they were doing.
In the end, if you have doubts, you’re better off passing on a candidate or perhaps having a short trial period, if that’s possible, to truly assess whether you have a winner on your hands. Better yet, try some of the suggestions below to remove the doubts and clarify the candidate’s true potential.
Have a great holiday.