Category Archives: Books

Book Review – How Would You Move Mount Fuji?

Over the holiday break I decided to tackle some of the books that I have stacking up next to my bedside.  One of them was How Would You Move Mount Fuji by William Poundstone.  This was a book that I know some of my colleagues had read already, and they recommended it highly, so I decided it was my turn. 

The book was a quick read.  The author kept my interest with not only the topic, but also with his concise explanations and his witty comments. 

Poundstone describes the history of the intelligence tests, and how it was developed.  They were used by our military to determine qualification for different job roles.  This led to the popular use of intelligence tests in the corporate world, particularly in the use of Silicon Valley.  During the civil rights movement, intelligence tests were determined to have a racial bias in the questions, so were banned as a hiring practice by the federal government.

The ban of intelligence tests did not deter those types of questions from remaining in interviews, however.  Looking for more people with minds like Bill Gates, puzzles made their way into the interviews at Microsoft.  They have popularized the use of logic puzzles and impossible questions.  Poundstone also describes the grueling day-long series of interviews at Microsoft and how you are rated throughout the process. 

My most important takeaways from the book was these nuggets of golden advice –

  1. When the technology you use is changing rapidly, you must hire for problem-solving stills, not just for the technology.
  2. A bad hiring decision is likely to hurt the company more than a  good hiring decision will help it.
  3. If you ask puzzle questions in your interview, make sure they are worth the effort by asking yourself these two questions:
    1. Are you willing to hire someone because of a good answer to this question?
    2. Are you willing to reject someone because of a bad answer?

I highly recommend this book to any hiring manager who plans on asking any puzzle type questions.  I also think the book adds insight into the overall interview process, even if you don’t plan on asking them that type of question.

Have you read the book?  Do you have an opinion on puzzle questions in interviews?  Leave me your feedback and let me know what you think.

Advertisements

7 Resources that .Net Hiring Managers Can’t Live Without

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?

Book Notes – Peopleware – Productive Projects and Teams

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.

New Book – Web Analytics: An Hour A Day by Avinash Kaushik

Avinash Kaushik is a leading Web Analytics expert and practitioner. His first book has been highly anticipated and well received. You can go to the book’s web site at http://www.webanalyticshour.com/ , or read reviews and buy the book on Amazon at http://www.amazon.com/Web-Analytics-Hour-Avinash-Kaushik/dp/0470130652.

He is also the author of a famous Web Analytics bog called Occam’s Razor at http://www.kaushik.net/avinash. I plan on both getting the book, and subscribing to the blog.

New Book – Peopleware : Productive Projects and Teams, 2nd Ed.

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.