Why I hate interviewing Microsofties

File this post under "why not to use your real name when blogging." This has very little to do with agile development transformation, but a lot to do with who I want to hire on to my team. So many of the resumes I see are from people at or just coming out of Microsoft. I have to say that (globally generalizing) they are some of the WORST software engineers I come in touch with. While being at MS doesn't necessarily breed stupidity, it definitely breeds laziness (not the good kind) and tunnel vision. I've had at least three candidates tell me that the way to navigate from one web page to another is create a linkbutton and use its server onclick event.

Jesus F**#@#$#$#ING CHRIST! Would you people pull your heads out of your asses. Please.

The problem with Microsoft people is they fall under the Microsoft Spell. What I mean is that they start to believe that everything in the realm of software, software engineering, and software tools begins and ends at Microsoft. The mothership is the Alpha and the Omega. What a crock. Three years ago when I was (cringe) working out there I casually asked about using something like NUnit, which I felt was fairly ubiquitous at the time. Nothing but blank stares. And this attitude is across the board.

Now don't get me wrong. They do some amazing things out there across the lake. Some of the internal tools would blow your mind. But often they're just re-inventing the wheel (at great expense) because they are so unaware of the world outside the MS walls that they don't know there are already five very serviceable solutions on the market or as open-source.


Another thing is the arrogance. Thankfully it's not like the old days, and there's less of it from those coming out than from those still there. God help you if you go interview out there, tho. Arrogance in full swing. And actually very difficult interviews. They'll dazzle you with all the latest tech you'll be working with. Here's a news flash: odds are at least 50/50 you'll be doing spreadsheets for marketing. And it will be very important, requiring lots of overtime. No shit-almost half their head count of engineers is just writing and linking up spreadsheets. Of course, they've got a lot of money to count, and that takes a lot of spreadsheets.

OK. Breathe. I feel better. Had to get that rant off my chest. But if I have to interview another ex-Microsoft person (spent any of the last 2 years over there), I may have to shoot myself.

Hiring, Staffing, and Drag

We're going through staffing management right now. The question, of late, has been how does this affect project velocity and our ability to deliver on current sprint items. Well, we've had a number of issues. First, we split our core team to a 1.1 and a 2.0 team. Then we experienced a temporary staff loss on 2.0. I've been trying for about a month to get the 2.0 project off the ground, but have come up against a brick wall it seems. Any time I get time to work on it, that time is eaten up
by operational needs, or more recently interviewing and hiring.

The decision I've been struggling with is: Do we re-channel efforts to 1.1 and abandon 2.0 being left with one guaranteed success and one guaranteed failure, or do we split the drag across 1.1 and 2.0 and end up with two struggling projects? So far I've opted for one guaranteed success. I'm hoping to get 1.1 far enough along that it will take off on its own and we can launch 2.0. Then we just have to play major catch-up for the rest of the year.

When development becomes operations

Into every developer's life a little operations must fall. At least if you're not a contractor that splits as soon as some JO calls the project code complete. So the question is how to handle this.

While I have done my obligatory stints at Microslop, most of my gigs have been at smaller shops that didn't have the luxury of an operational team or needed to compose one after the fact. In all cases the developers needed to provide at least some of the operational support immediately after release, and often into perpetuity.

Coming back to Agile, how do you effectively manage both this operational need and continue to move forward on development. One of the precepts of agile development is to focus on one product/problem at a time. It is well documented that task switching is incredibly wasteful, so we try and avoid this at all costs. The tack we've tried to take is rather than putting everyone on 50% time (50% dev, 50% operations) we've split the team to two developers purely tasked with moving forward on the next version, and two developers who are floaters (ex: 80% ops/20% dev).

In practice it has been somewhat effective. The next version is moving forward at a predictable (albeit slow) pace. Operations is being handled. There is some frustration within the dev team, although it's isolated to about half the team instead of everyone being stuck in the mud. And our task breakdown has become less 0/100 & 80/20 and more 10/90 & 80/20 for ops vs. development time allocation. Can't wait for our ops team to gell and come up to speed.