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.

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.

Well, there are. Just look at Ubuntu. If you’re a non-power-user (i.e. the words “apt-get” mean nothing to you), you pop open the “Ubuntu Software Center”, and you’re instantly presented with a plethora of pre-approved packages sure to satisfy almost every need. Check, “Apply”, Use.

And to complete the “App Storishness”, today Canonical announced an approval process for 3rd-party apps. Voila! An Apple-style app store right on your desktop. It just so happens, every app in it is free.

True, the need to provide users easy access and installation to new apps was more dire on Linux than on Windows or MacOS, but it is not exclusive to Linux. There are more applications for Windows than for any other platform, but there is no prominent bundled central marketplace application to bring order to chaos. For the life of me, I cannot understand why. Why does Microsoft overlook the opportunity to collect a commission on every piece of software sold through this channel? Does it still fear being branded as a monopolist in a new world where everyone is a monopolist? Does it believe so fervently in “life without walls” that it looks past the droves of consumers clamoring for walls?

From a technical standpoint, an app store would be a goldmine in eliminating much of the Windows bashers’ fodder. By creating a direct marketing channel with strict technical requirements, it could mandate essential development best practices, such as respecting UAC and privilege separation, restricting memory-resident baddies, using the “suggested” directory structure, staying away from private APIs, etc. Users win convenience and stability. Vendors win access to users. Microsoft wins money.

So where the heck is my app store?

It doesn’t take expensive software either to “hack” a PDF. PDF Text Replace from A-PDF ($27 US) can do a search&replace (or search&destroy) on any number of text strings inside a PDF file.

That mistake you made on a 100,000 word document of which you lost the original? Gone. Your name on your creative work? Gone. Watermaks for copyright protection? Gone.

Take the good with the bad, but let’s not assume security where none is offered.

 Console.WriteLine(this == null);

…so that this statement will print “true”. Post your answer in the comments if you get one.

Hint: Do not try to create a context where Console or WriteLine will resolve to something other than what we’d normally expect – that’s not what this problem is about.

Signs of an “agile in denial” team:

• They write big or multiple functional specs, but keep changing them until the feature ships
• They have upfront scopes for each release, but end up dropping or modifying large chunks of the said scope as the iteration progresses.
• They designate “feature freeze” dates, each of which is preceded by a mad rush to implement as many features as possible, however shoddily, and put off quality control and/or bug fixing until after the feature freeze.

The detriments of the use of megaspecs to try to cement fluid requirements have been explored well enough – mostly teams end up losing valuable time and resources making (and committing to) plans they will end up not following. But when a team tries to maintain feature freeze dates while succumbing to variability of requirements and scoping, all hell breaks loose.

Let’s do a word problem together: Pretend you’ve entered a very expensive gourmet all-you-can-eat restaurant. Every delicacy you have ever dreamed of is spread out on the buffet line before you. Just a couple of snags: First, an hour from now the restaurant will close and you’ll have to end your meal. And second, ten minutes from now the buffet line will close, so you have only ten minutes to fill your table with all the food you plan to eat during the meal. Question: what percentage of the food brought to the table during the first ten minutes will be consumed by the end of the meal?

A delicious, if unnecessary parable. Feature freeze dates are great if the requirements are firm and the scoping is realistic. But when the scope is prone to change as the work progresses, a hungry PM will almost inevitably succumb to temptation to fill his table with many delicious features from the buffet line prior to the feature freeze, without thought as to whether the team will have time to eat and digest (debug and QA) the selection thoroughly before the release date.

And so we reach the fourth and most tragic sign of an agile team in denial:

• Their releases advertise many new features, but are full of bugs in aspects new and old. Releases often cannot be used to satisfaction until a patch or two has been provided.