Our department has gone through some changes lately; some changes have affected the process we follow when interviewing. Since I know I will be doing lots of interviewing this month, I have been thinking a lot about what we have done right in our process, and what can be improved. Here is the process that we go through in our department to prepare for interviews.

1. Define a Process

As an interviewer, one of my objectives throughout the interviewing process is to provide as much consistency as possible. Define a process that is consistent and repeatable. Then, when comparing one candidate to another, you will be comparing them win the same questions, with the same process. It will also mean that you are always prepared for the next interview cycle with little effort.

2. Write A Great Job Description

The Job Description that you write is what will let your recruiters, consulting companies, and candidates know exactly what you are looking for. It is important to list everything that you are looking for:

• Technical skills (i.e. – Visual Studio .Net 2005, ASP.Net Ajax, SQL Server 2005, etc.)
• Specific Education Requirements (i.e. – Bachelor’s Degree Preferred, etc.)
• Certifications (i.e. MCSD, PMP, etc)
• Methodologies (i.e. – SDLC, Agile, SCRUM, etc.)
• Years of Experience (i.e. – Junior level with 2 years experience or less, etc.)
• Project Management Skills (i.e. – 3 years managing projects with a budget of $1M or greater)
• Communication Skills (i.e. – Written, Verbal, Able to work with clients to collect detailed requirements, etc.)
• Other Intangibles – (i.e. – Energetic, “Do It Right” over “Get It Done”, able to work on multiple projects, etc.)

3. Offer A Competitive Rate

You need to know what the people you are looking to hire are worth. If you are not offering a competitive rate, then you will not be able to attract, obtain, and retain the talent you are looking for. If you can, research market rates for your open position, particularly with your competitors.

4. Follow A Proven Recruitment Process

Whether you have a business process for recruitment, have a third party company that manages it, work with recruitment and consulting companies, or post resumes on Dice and Monster, you need to get the work out about your open position and collect those resumes. These sources need to align with the types of candidates you are looking for. Some sources are for specific technologies or skills, so be sure what you are looking for and what your source can offer match.

5. Screen Your Candidates

Once your open position is posted, you will be flooded with resumes. With all the other things you are busy doing, it will be difficult to keep up with the influx. You will not be able to schedule face-to-face interviews with everyone. The best way to whittle down your pile of prospective candidates is to phone screen the candidates. Prioritize your candidates in the order in which you want to interview them. Then you phone screen them in groups of three to five at a time. The phone screens should be short, ask a wide variety of questions, and be sure the candidate meets the minimum qualifications. Be sure you stay consistent – ask the same questions, and stay with the same people screening the candidates. As you find candidates you want to see more of, schedule them for a face-to-face interview.

6. Script Your Face to Face Interview

You should have a planned script that outlines your face-to-face interviews. Knowing exactly what you want to cover in advance and following the script will keep the process consistent and make it easier to rate the candidates. The steps we follow to conduct an interview will be the topic of another post.

7. Plan your Questions in Advance

In the interview process, it is a good idea to have more than one person interview the candidate (it would be even better if you can interview your candidate all together). Write down your questions in advance and assigning certain sections of questions to each person. You can compile your questions from my .Net Hiring Managers Resource, or from your own resources. Make a worksheet of the questions, with space to jot down notes about their answers and your thoughts during the interview. It might help to come up with a rating scale of 1 to 10 to rate the answers you get. Again, this will make rating the candidate objective, consistent, and easy to gather and summarize the opinions of all the interviewers.

Have I missed anything? Do you disagree with anything here? What process do you follow? Do you have a best practice that you depend on that is not in these steps?

Hiring quality developers is the key to any great application development organization. In our department we have experienced the joys of a great team that has jelled to produce high quality projects, and experienced the pains of bad coding practices, bad spaghetti code, and bad attitudes. Our team has very high standards, and our interviewing process is rigorous (and will be the subject of another blog post later). These resources are some of the tools we use to ensure that we get a candidate who can do the job and do it right, whether they be Junior, Mid, Senior, or Architect level developer.

1 and 2 – From Scott Hanselman

Scott Hanselman has two fantastic articles on .Net interview questions. One is called ASP.Net Interview Questions, and the other is called What Great .Net Developer Ought To Know, and the subsequently posted list of answers. This is basically version 1 and version 2 of the same idea. His second post breaks out his question ideas into increasing degrees of complexity and different job function specializations. The comments on these posts are almost as valuable (and some more so) than the articles themselves.

3 – From Marc Andreessen

If you are opposed to the idea of a list of technical (trivia) questions, here is a great article by Marc Andreessen called How to hire the best people you’ve ever worked with. If the name sounds familiar, it should… in 1992 while at NCSA he co-authored Mosaic (the first widely used web browser), and in 1994 he co-founded Netscape Communications. Marc focuses on the less technical traits that make a good candidate great. He discusses the importance of drive, curiosity, and ethics. He then discusses the importance of a process for hiring, and outlines six steps to find great candidates. This is an article you should read, re-read, and re-read again.

4 – Worse Than Failure

Worse Than Failure is a web site that collects, “Curious Perversions in Information Technology.” It houses a collection of really bad code snippets, bizarre error messages, and best of all – accounts of really bad interviews. Reading these continues to remind me why we have such a complex interviewing process. So far, my most favorite is this account of a telephone tech screening. The shame of it all is that this has happened to us in our department. A lot.

5 and 6 – From Amazon.com

Here are two great books that cover the gamut of good, hard, uncomfortable interview questions, and the kind of answers you might expect to see. The first is 101 Great Answers to the Toughest Interview Questions. The second is Best Answers to the 201 Most Frequently Asked Interview Questions. I have chosen some great questions from these books when I was the interviewer, and have reviewed these books myself to prepare for an interview when I was the interviewee too.

7 – Brain Benders

Sometimes, depending on the type of candidate we are looking for, we like to ask the candidate to solve a number of puzzles or riddles. This is (or was) a common practice at Microsoft and Google. If done right, it can shed some light on the thought process of your candidate, even if they do not get the puzzle solved correctly. One source of these types of questions is a really great book called How Would You Move Mount Fuji? Microsoft’s Cult of the Puzzle – How the World’s Smartest Company Selects the Most Creative Thinkers. There are lots of other sources for this kind of material, both online and in print.

Which ones did I miss?

These are not the only good resources for interviewing by any means. These just happen to be the ones that our team and I can’t live without. What resources do you rely on to find a matching candidate for your needs?

So, while I was at the beach this week, I finally finished “Peopleware – Productive Projects and Teams” by Tom DeMarco and Timothy Lister. As I read through the book, I kept having these moments where I thought that the two authors were walking with me through my days at work. There were some major themes that were threaded throughout the book, and I think we all need to keep them in mind. This is a summary of the starred sections, underlined bits, and notes that I took while reading. Keep in mind that these are short clips from the book. The book goes into much greater detail and explains the arrival at each of their points. Also, this is a summary of the points that the author has made, and are not necessarily a reflection of my position, opinion, or belief.

• Managing the Human Resource
  • Development is not a production line, and the people who do development work are not replaceable parts
  • Most times, when management talks about productivity, the actual result is getting more out of each dollar spent, not each hour worked.
  • The quality standard of the Client and the End user is typically much lower than that of the Developer. The Client needs to pay for development time, and is willing to sacrifice quality for time to market.
  • Taking the time for high quality means less defects, and higher productivity.
  • The development team, who takes pride in their work, will typically set a standard of quality that will result in productivity gains that will offset the increase in cost.
  • Parkinson’s Law – Work expands to fill time allocated for it. Complete silliness. Organizational busy work expands to filled your time. It is the job of managers to remove that busy work.
• The Office Environment
  • Comments like “I get my best work done in the early morning before anyone else arrives”, or “in one late evening, I can do two or three days work”, or “I’m staying home to get some important work done” mean that the office is not conducive to productive work.
  • Research at IBM has shown that 100 square feet of space, 30 feet of work surface, and either enclosed spaces or 6ft walls per person is optimal for optimal performance.
  • Developers who think that their workplace is acceptably quiet are one third more likely to deliver zero defect work
  • Thirty percent of the time, people are noise sensitive (they are working alone) and the rest of the time they are noise generators
  • Flow is a condition of deep, almost meditative state achieved during single-minded work time that provides a gentle sense of euphoria and minimizes the passage of time. “I was in the zone, and looked up and it was 3 hours later!”
  • It takes an average of 15 minutes of undisturbed quiet time to enter flow time.
  • What matters is not the amount of time you are present at work, but the amount of time you are working at your full potential (flow time).
  • We need to ask ourselves “Does a phone call that will interrupt someone warrant the interruption, or can I send an email that someone can deal with at their convenience?”
  • Methods to drown out noise, like background music, occupy the right brain, which is used less during cognitive thinking. But it also diminishes the creative processes of coding, which decreases the “Aha!” spark of creative leaps.
  • Other environmental features, such as windows and outdoor spaces, have been shown to significantly increase focus, performance, and productivity.
• The Right People
  • Most hiring mistakes result from too much attention to appearances and not enough to capabilities
  • Sometimes dress codes are just a way for managers to demonstrate they are in charge
  • A good manager knows when to shake up the local entropy and let their developers be themselves
  • Good ways to analyze possible candidates is through a portfolio, code samples, auditions (such as a presentation on a specific topic), and aptitude tests. Aptitude tests, however, are more suited for short term hiring and self assessments.
  • By the time the person leaving documents everything, the new person starts, gets their PC, the team helps get them up to speed, a new hire or turnover will cost the company between four and six work months.
  • Turnover engenders more turnover
  • The best companies are not noted for their similarities, but for their differences. People stay at these kinds of companies because there is a widespread sense that you are expected to stay.
  • Retraining is a common feature of companies with low turnover.
  • Big M Methodologies are an attempt to centralize thinking, and remove decisions from the development team. They typically encourage people to build documentation rather than do work and have resulted from paranoid defensive thinking and to try to cover every possible scenario. Small m methodologies are a basic approach one takes to getting a job done, and leaves tailoring the methodology to the development team.
  • Convergence of method is a good thing. But Big M Methodologies are not the only way to achieve convergence. Better ways to achieve convergence of methods are training, tools, and peer review among other methods.
  • The Hawthorne Effect – people perform better when they are trying something new. The change itself was not as important as the act of changing
• Growing Productive Teams
  • A jelled team is a group of people so strongly knit that the whole is greater than the sum of the parts. They don’t need to be managed in the traditional sense. and they don’t need to be motivated. They have momentum.
  • The purpose of a team is not goal attainment but goal alignment.
  • You do not build a jelled team, you try to grow one
  • A jelled team is easy to identify – it has low turnover, a strong sense of identity, a sense of eliteness, joint ownership of the product, and obvious enjoyment in their work.
  • Teamicide – You cant make teams jell, but there are things you can stop doing that prevent teams from jelling: defensive management, bureaucracy, physical separation, fragmentation of people’s time, quality reduction of the product, phoney deadlines, clique control
  • A great way to get a team to jell is to give them a small victory, such as creating a spaghetti dinner together
  • Follow an Open Kimono attitude – trust the people that work for you
  • If you have decent people under you, the easiest way to improve their chances is to get out of their hair and out of their way.
  • Visual supervision is almost useless for development workers
  • Skunkworks projects are a corporate form of insubordination that if used properly could benefit the team and the organization
  • Some companies have the right chemistry for growing jelled teams. Some elements that create the right chemistry are: making a cult of quality, providing lots of satisfying closure, building a sense of eliteness, allowing and encouraging heterogeneity, preserving and protecting successfully teams, providing strategic but not tactical direction
• It’s Supposed to be Fun to Work Here
  • It is part of the human condition to provide order to Chaos. It is the job of a good manager to break up and parcel out small packets of chaos to each of their direct reports.
  • Ways to re-introduce constructive chaos to the workplace are: pilot projects, war games, brainstorming, provocative training experiences, trips, conferences, celebrations, retreats
  • Free Electrons – Free spirits with perspective and maturity are given a loose charter to explore cutting edge projects in the best interest of the company, and then get out of their way
  • Holgar Dansk – the Sleeping Giant – sleeps in your organization too, waiting for too much entropy, too little common sense, and will wake up and step in to save the day… as long as you let them.
• Son of Peopleware
  • Motivational accessories, the inspirational posters and coffee mugs, are belittling and humiliating and do more damage than good.
  • Sustained overtime prevents well jelled teams as well as lowering the actual productivity of your individual developers
  • A well-knit team, one where there is trust and safety and no competition, will foster peer coaching between its members to transfer knowledge across a range of topics. The learner and the teacher will be interchangeable without threat.
  • Internal competition can be a cause of Teamicide as well. Some sources of competition are: annual salary or merit reviews, management by objectives, praise for extraordinary accomplishments, awards, prizes, performance bonuses, performance measurements in any form. These sources must be counteracted to prevent the feelings of competition.
  • Process Improvement methodologies, such as Carnegie Mellon’s Software Engineering Institute (SEI) Capability Maturity Model (CMM), are Big M Methodologies reborn. Focusing on the Key Process Areas(KPA), but turn off the institutional score keeping.
  • People truly hate change. They are not rejecting a particular change on its merits, they are rejecting ANY change.
  • You should focus on converting the “Believers but Questioners” of the change.
  • The fundamental response to change is not logical, but emotional.
  • An expense is money that gets used up. An investment is the use of an asset to purchase another asset. Training should be considered an investment, not an expense.
  • Experience gets turned into organizational learning when an organization alters itself to take account of what experience has shown. This can happen by instilling new skills and approaches in its people, or by redesigning itself to operate in a different manner.
  • Middle management is where the organizational learning happens. Removing middle management layers will ensure the loss of organizational learning, but holding on to middle management doesn’t make learning more likely to prosper. Middle managers must communicate with each other and learn to work together in effective harmony.
  • The ultimate management sin is wasting people’s time.

So… what do you think of the ideas that the authors present? Which do you agree with? Which do you disagree with? Leave me some feedback and let me know what you think.

The review from amazon.com looks like it would be a great read for an airplane ride:

Peopleware asserts that most software development projects fail because of failures within the team running them. This strikingly clear, direct book is written for software development-team leaders and managers, but it’s filled with enough commonsense wisdom to appeal to anyone working in technology. Authors Tom DeMarco and Timothy Lister include plenty of illustrative, often amusing anecdotes; their writing is light, conversational, and filled with equal portions of humor and wisdom, and there is a refreshing absence of “new age” terms and multistep programs. The advice is presented straightforwardly and ranges from simple issues of prioritization to complex ways of engendering harmony and productivity in your team. Peopleware is a short read that delivers more than many books on the subject twice its size.

Link to Amazon – Peopleware : Productive Projects and Teams, 2nd Ed.