Chapter 9 covers the topic of developer recruitment. The author makes an immediate claim that job board type sites with the traditional job description are a bad way to hire developers. Many job postings list an abundant amount of technologies that aren’t even required to do the specified job. This immediately filters out some really good candidates. Listing years of experience can also filter out good candidates because years is not necessarily a measurement of knowledge. The author goes on to say that many larger companies continue to get developers similar to their “bad” ones because they are relying on their poor recruitment process. Getting rid of generic job descriptions and avoiding the mistakes mentioned, gives access to a wider range of potential craftsmen. This can also remove any obscurity the recruiters have with not understanding the true technical aspects of the job and prevent keyword matching. Another piece of advice given is that companies should avoid financial compensation for employee referrals. It creates wrong motivation and incentive to recommend a potential employee. Working with talented people who improve the quality of the work environment should be compensation enough. It is suggested that companies should always be proactively recruiting. Getting involved in tech communities and user groups is a good and cheap way to gain exposure to potential talent. By building a pool of candidates for future employment, the hiring process can move much quicker. Lastly, the author suggests that you look for passion above all else when selecting a new developer. Someone who blogs, contributes to open source, or attends conferences will likely see the employment opportunity as more than just a job. In summary, if you are currently dealing with “bad developers” look to change the recruitment process to hire the people you really need.
After reading chapter 9 I found a lot of the author’s suggestions and advice to be helpful for my future. While I agree with his points, many companies still post job descriptions like the ones he called out. For people who are unemployed it’s not always easy to find the perfect place to work never mind go through a selection process for a company that isn’t even hiring right away. I strongly agree with the author’s comments about not listing years of experience on a job description. It can filter out people who are newer but more current with a technology and keep people who have done the same exact thing for “X” amount of years. One thing I have noticed looking for entry level software jobs is that companies post long lists of specific technologies for required skills. I think it’s more important that a candidate demonstrates the ability to learn new things. Having a coding assignment as part of the selection process can allow candidates to show their adaptiveness to new technologies as well as give a current sample of work. I have also seen job postings for entry level or junior developer positions that require a lot of experience or many technologies. I can’t imagine postings like this can get very many applications as they are not practical. While I agree with the ideas in this chapter, the hiring process in the United States is still far from adopting them as the new norm.
Chapter 10 covers the topic of interviewing from both the company and candidate side. The author gives a helpful reminder that an interview is not someone begging for a job. It is a business negotiation with the goal of creating a good partnership. As the demand for software developers is at an all-time high, candidates do not need to settle for anything less than a good partnership. From the perspective of the company giving an interview the author makes several points. In general it is best to focus on the candidate’s enthusiasm, projects, and achievements and not necessarily hard skills like a particular technology. He also says to favor those who ask questions showing genuine interest in the company and their role. Lastly it’s important to not only give a clear outline of the open position but to make sure it matches what the candidate is looking for. The author also gives advice from the perspective of the candidate. He suggests to take the time in the interview to analyze everything about the situation. Learn as much as possible about the work environment, hiring process, and actual role you’d be filling. A good interview should also have some key elements to it. For one, the interview should feel more conversational and not like a scripted test. You can’t truly show or find passion and talent with questions requiring yes and no. It is also suggested that some form of coding be part of the hiring process. This could be a pair programming session or a pre-interview coding assignment for filtering. A software developer should also be a part of the interview process at some point. Developers interviewing developers is beneficial for everyone. In conclusion a good interview will form a productive partnership that both sides are enthusiastic about.
After reading chapter 10 I strongly agree with the interview advice given by the author. In regards to asking questions in an interview, I can’t imagine I’d be very interested in a role that I didn’t want to know anything about. I also think it’s important to remember how much time you truly spend at work. Most of your time is spent on the job so I think the most important point is that you can see yourself being happy going to work every day. While I think it’s important to analyze the logistics of the interview, many times people can be very nervous going into an interview which can hinder the execution of their interview game plan. I believe a good interviewer will get the candidate comfortable in a conversation before getting to the important parts. Lastly, as a soon to be developer I think it’s important to remember the abundance of jobs there are in the field. I can’t settle for something that I won’t be truly excited about. It makes for a bad partnership and violates all the advice given by the author as a software craftsman.