Land the Tech Job You Love turned out to be a good read full of actionable advice for job seekers who just happen to be techies. It covers everything from creating three versions of your resume to preparing a portfolio of work products to take with you to the interview. All of this is good advice.
The hidden gem in the book is the great guidelines for technical managers on how to conduct the recruiting process:
“A hiring manager who wants to get a real feel for her candidates’ skills will ask for examples of work. When I was hiring programmers, I told every candidate that I called in for a face-to-face interview to bring in code samples, printed on paper, so that we could discuss them during the interview. Unfortunately I was definitely in the minority. Ilya Talman, on o the top technical recruiters in Chicago, to me that he estimates only 15% of hiring managers ask to see samples of work.”
For developers bringing in their code and going over it gives you a much deeper feel for a person’s development skills than any single behavioral question.
Code samples give you a sense of how the developer looks and how important code hygiene is to them. You can ask about decisions as to why they didn’t refactor a longer method or why they named a class a particular way. In many technical interviews you’re never asked to go through code at all.
If you’re not already requiring code samples for prospective developers I’d suggest trying it out at the next opportunity. You’ll be surprised at the insights.
As a hiring manager the world has gotten easier with respect to getting some independent information on a given developer candidate. For many years now I’ve taken to doing a bit of googling for any candidate that passed the initial resume screening test.
Back in the early to mid 2000s this search often didn’t yield too much information. Back then Facebook and LinkedIn either didn’t exist or were just getting started. Blogging was popular, but still relatively rare, and Twitter was still waiting for ODEO to fail first. I often found the only relevant hits in some old USENET posts, but they were often at a time when the candidate may have been in college. I can’t even remember getting a candidate who had a blog or one who worked on an open source project. Today the picture is different.
Assuming the candidate doesn’t have a very common name you’re about 80-90% likely they at least have a LinkedIn page and very often Facebook or twitter accounts show up. I get really excited if I can find a blog for there or even better some source code from an open source project or so. As a hiring manager this stuff is golden as you can get a lot of background on a candidate to help decide if they’re meeting the bar for at least a technical phone screen:
- Consistency: Does the LinkedIn or other information line up with the submitted resume. You don’t want to see a candidate who reports their job experience very differently online. Slightly out of date is fine, but when the employed dates are off by years, you’re probably not going to make the phone screen cutoff.
- Passion: This is a critical factor in any hire. Do you really enjoy the career you’re in or trying to break into. Blogs and open source here are easy ways to see this in a candidate. If they contribute maven plugins or work on a build tool you can see they really care about automation and release management. Negative opinions of certain technologies aren’t bad here, techies are passionate about what they don’t like as well, but I like to see reasoned arguments and a passion for some alternative.
- Learning: I only want to hire candidates who excel at picking up new technologies, tools, business domains, and practices. Seeing some tutorials, reading your twitter posts about messing with Clojure, or even seeing a list of books you’re currently reading along the side of your personal site can present compelling evidence that you enjoy keeping up with the software development field.
- Communication: Written content helps evaluate how someone communicates and blogs are especially helpful here. Even tweets can give you a sense of how someone can string together punchy short sentences. Often all you can find are posts in forums asking for help with a product issue, but the person’s skill at asking for help and describing the issue can give you a feel for their abilities.
I haven’t mentioned other items that you come across like that their kid sister had breast cancer or that their favorite hobby is Ultimate Frisbee. Those facts aren’t relevant to how they perform on the job. I try to ignore them altogether when doing research.
Finally, I’d suggest that if you’re on the market, and a many developers are currently you might want to at least look at your online profile. As credit checks and drug tests have become regular screening items for a number of employers an online search of your name is certainly becoming almost a standard item. There’s not much you can do if there’s something unfortunate out there that shows up at the top of Google searches. By enhancing your online presence with relevant blogs, twitter, or other publishing sites you can build up a more recent history that’s relevant to hiring managers out there who google your name. You might want to just go ahead and include it on your resume as long as the majority of the content is relevant. And contributing to an open source project is a great way to stand out from many other candidates and worth pointing out on a resume.
I took an opportunity to head down to OSCON a week or so ago on a free expo pass. I always wanted to attend OSCON up in Portland, but I never had the opportunity to go. Anyway I invited another developer along and made the morning drive down to San Jose amid unusually light traffic. Reminded me of the times I drove around during the dotcom bust.
As an expo attendee there were a number of free things to do beyond walking around looking at vendors. The bulk of these involved attending OSCamp which initially looked sort of like it might be an Open Space type offering, but ended up being more of a loosely organized mini conference. I listened to three different speakers.
Bill Shupp from digg.com gave a talk on the PHP PEAR proposal process works. The key takeaways were that it helped to bring PHP coders into a more formal process where you follow some coding standards, are expected to have unit tests, and go through a code review process. He explained that digg.com had really gotten into unit testing and TDD including hiring the author of PHPUnit to help them with the adoption. They are also running a CI server and a nice 52 inch monitor with red or green for each currently running sprint.
I didn’t catch the name of a speaker who explained how he got into open source through the PHPbb bulletin board software, but it was nice to see a high school student who really felt empowered by contributing to software that’s used by thousands of sites.
Overall I enjoyed the free expo day at OSCON, and if I get the chance to be sponsored by my employer in the future I’d put it on my short list of potential conferences.
About half my career has been inside professional service firms. The work has quite a few perks and you’re constantly pushed to learn new things. Having spent quite a bit of time within IT departments as a manager I did sometimes missed the wealth of different clients and projects you’re exposed to as a consultant.
I’m not sure how common the practice is, but after leaving my last professional services firm about five years ago they let me know they considered me part of the alumni network. I remember thinking it was a novel way to approach employees who leave your company on good terms. I’m not sure how common the approach is, but I think it pays significant dividends. Over a few years I got a few little goodies in the mail including a USB key at one point and I ended up doing a few very short engagements to help out the local office.
For the professional services firm this sort of practice is a little extra effort, but pays particular dividends:
- You maintain a good relationship with former employees which helps in a small way your overall brand.
- Those employees may send prospective new employees your way who are already well recommended.
- Former employees may need some professional services and you’re often invited to compete for work.
- The alumni member may throw some leads your way when they find out about potential projects.
- Those alumni members may someday return to your firm bringing back valuable experiences from their time outside the firm.
As I now find myself returning to the fold with my former firm, I’m impressed with the little extra effort they took to stay in touch.
Unit testing is a practice that takes years to sink in. For many the first experience with the green/red bar is interesting, but not life altering. Maybe it was just a quick demo. They go back to the normal debugging patterns in the IDE or with printing output to the terminal. They try testing for a bit and find battling with legacy code just doesn’t feel like its worth the effort.
How do you effect change here? After experience with several groups I’ve found a gradual approach to work better than total immersion:
- Exposing the team to the concepts, especially if they haven’t really seen a true TDD session.
- Explaining the benefits to them as developers with reduction in defects, better code that’s easier to refactor, and knowing that when you get asked to work on a legacy codebase with a decent test harness that you won’t have to cross your fingers that the new feature you added didn’t break some other code.
- Continuing the conversation through one on ones and other means of how testing is going and where they’re having trouble writing tests or how writing the tests first might work a little better, or even starting with just some larger integration tests. With one team I asked the question of all the developers every week, ‘How many tests did you write this week?’
- Celebrating as code coverage metrics start climbing and pointing back at the reduction in defects.
While I often hoped the process of becoming real TDD style developers would take people a few months, it often took years. I never saw overnight success with adoption, but after time I started to see ‘aha’ moments among many of the developers:
- A developer who was dedicated to testing let about 20 unit tests start failing because he’d made some changes to the domain model. He knew he needed to get back to them, but had prioritized some other work. As the tech lead on the project who I’d worked with for years saw the failure email from the CI server he rushed over right away and got the developer refocused on fixing the tests first.
- Another developer finished off a recent project release and had zero real defects. The code coverage was well over 80% and among the best tested code in the organization. I’d started introducing testing to that developer over 6 years ago, but now he feels bad not writing tests.
As a manager and a person I treasure these stories as I hear them even if it they were years in the making. They’re more important than any kudos on an annual review or a big end of year bonus.