On my last night in Shanghai, we had dinner with a fellow who’s getting deeply embedded in the .NET community there. I’ll be running an article based on an interview with him in the next month or so, but some of the most interesting insights he shared came after the recording device was turned off.
Since he’s in the business of hiring developers and he doesn’t always trust what the resumes say, he’s worked up a technique for evaluating skills that’s pretty nifty.
When somebody wants a job, he gives them work — unpaid. He’ll feed them the specs for some tiny aspect of a project that he’s involved in. For example, he might need a component that handles scheduling of meetings for people located in three sites around the world — all, obviously, on different time zones.
As the developer works on the test project, he’s expected (it is always a "he" apparently) to write a daily blog entry about obstacles and potential solutions as they surface in the work. That gives our guy in Shanghai a chance to evaluate the person’s skills in communicating with the team and shows how the prospective hire approaches a programming problem. Not solving it isn’t cause for losing out on the job; it simply provides awareness for areas of strengths and weaknesses: ability to research tools; English language skills; willingness to share knowledge or questions with others on the team…
I like this approach because it gives the candidate a taste for working with the team and it gives the hiring person a real-world snapshot of an applicant’s potential and willingness to do what it takes to get the work done.
