How not to recruit engineers

Today, this gem of an advertisement graced the sidebar of my Facebook page:

Really? I wonder what kind of engineer this company wants. The kind with the same skills, aptitudes, and background that Google wants? If so, they’ll get only the ones Google turns down. And if this company is looking for different assets than Google, then its ideal candidate(s) may not have been interested in working for Google in the first place. Either way, this ad will not bring in the candidates this company wants.

Code smell of the day

The word “and” in the name of a method or class. Discuss…

Musing of the day

“There is no throwaway code, but there are throwaway coders”

The interview question no one asks

Everyone has a favorite interview question. I have mine. I have never been asked this question on any software engineering job interview I have ever attended. However, I firmly believe this question tells more about a candidate than all the good old standbys (e.g. “reverse a linked list” and “write a thread-safe singleton”) do put together. So… ready?

Describe all the unit tests you would write for an implementation of java.util.List<E> or your platform’s equivalent. No need to write out the test code – just list the test cases.

That’s it! The interface being tested can vary from candidate to candidate. The important thing is that this question shows you how good the candidate is at proactively anticipating bad inputs, boundary conditions, and special cases. It is a truly universal and essential skill for all engineers, even those not fortunate enough to work in a test-driven environment.

The Tradable Quality Hypothesis

Martin Fowler has written an excellent post on the fallacy that quality can be traded for expediency. A few days ago, I debated many of the points the article covers with an engineering manager at my company. Both of us are still convinced the other person is wrong. Except now, I have Martin Fowler on my side.