Interview Process
Finding technically capable people that fit with an existing culture is tough. On one hand, having objective measures of a candidate helps to quickly filter a candidate pool. On the other hand, purely objective measurements don't capture the "soft" skills that help someone function in a team environment. We struggled with how to probe these areas effectively and efficiently. Our current interviewing model is a multi-stage process. The first step in our process is a phone screen. Phone screens give us a quick way to introduce our company to a candidate and to probe the candidate at a high level. In the phone screens, we cover some basic technical abilities, thoughts and understanding on agile development, and some level of personal introspection. By touching on these areas, we can tell if someone will not function in our environment. If the candidate isn't filtered out during the phone screen, we schedule an on-site interview. This interview is broken up into three segments: technical, process, personal. For each segment, we assign at least two team members so that a majority of the team gets to interact with the candidate. The technical portion of the interview focuses on raw technical ability and includes a hands-on programming exercise. The process portion gets into philosophies on testing, problem solving, and pair programming, among other topics. The personal section looks at conflict resolution, personal motivation, and general mental stability. We've found that this process works very well. If we get through all three segments and there is no hesitation about a candidate, the candidate will work well in our team.
Process Improvement
Process improvement is key to building a successful software development team. We look at process improvement not just from the processes used to write and deploy code, but also processes used to prioritize work and hire new employees. One mechanism that we use for improvement is what we call a "3x3" review. With the entire team gathered together, each team member must come up with something positive from the past three months, and something negative from the past three months. Each team member then gets three votes each for the positive group and the negative group. Those votes are distributed to each listed item. When the review is done, we have a high-level view of what the team sees as positive attributes and what the team sees as needing improvement. This perspective helps keep the team aligned with the stated team characteristics. Another area of process improvement for us has been the interview process. As our understanding of agile development techniques matured, so did our need to find people that were not only skilled technically, but skilled in functioning on a team. Over the course of about eighteen months, we refined and perfected our interview process to a point where we know we won't pass on a candidate that would not thrive in our environment. This improved process gives us a much greater confidence in the people that we hire. We have had to find a balance between executing our existing processes and continually improving the processes. Whenever we experience pain in our processes, we take a little time to evaluate the pain. If the pain looks systemic, we try to identify incremental changes we can make to improve our process. If the pain is not systemic, we usually take a wait-and-see approach before making any other changes.
Conclusion
Over a short span of time, we've learned some valuable lessons for building a successful agile development team. Establishing team values and adhering to them has helped us build a successful culture and refine our interview process. Facilitating good communication has removed obstacles that hinder many teams. Refining our interviewing process has helped us identify qualified developers that will mesh well with the existing team. Reviewing our existing processes has helped us to improve the team on a continual basis.
原文转自:http://www.cnblogs.com/Tcorner/archive/2010/04/01/1702668.html