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.

Marcus Westin from Meebo gave a talk on Javascript best practices which included a mention of HTML 5. It was compelling enough to make me think I should look into it. Meebo is essentially a giant javascript application and Marcus explained that he’s a full time Javascript engineer. I hadn’t really thought of the idea of full time javascript developers, but Meebo is actually hiring even in the bad economy. He talked about how they’d been cleaning up the codebase over time, but there was still some 8000 line Javascript file that was too hairy to refactor. Sounds like a great challenge to get some test harness around.

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.

The picture pretty much speaks for itself. I haven’t had to make business cards on my own in years, but Zazzle made it pretty simple to do online. I created the logo at faceyourmanga.it. Even in the days of the web a card can have some impact.