Monthly Archives: February 2009

Death to the “Trivia Interview” or What is the Meaning of Irony?

As friends of mine who became victims of the recent US economic crisis start to look for jobs, I am often getting, usually over (a few) beers, very scary stories about what it is like interviewing today.  Sadly, it is reminding me that not much has changed since last time I interviewed during hard economic times, back in the early 2000s.

Lets face it, technical people are mostly horrible at technical screening.  We choose questions from lists, like a famous one Scott Hanselman put on his blog a few years back.  And then if someone knows a sufficiently high number of trivia questions, we assume they will be a good developer, and the next phase starts, which usually involves making sure they shower, shave, etc. – and are not a total psychopath.

The real issue here, of course, is that forming good technical interview questions extremely difficult.  Ideally, most companies would hire for aptitude, since we all know that good developers learn things very quickly – that is part of what being a good developer means.  Sadly, many still do not.

Let me illustrate through a story.  Lets say that, for sake of example, someone was hiring a developer to build something useful, like the i4o indexed Linq framework that I wrote a couple years ago – and continue to maintain to this day.  My guess is that if someone else were trying to build such a framework in 2007, given that in 2007 I had zero Linq experience – other than a vague idea of what it was for, I would have never been even granted an interview, much less passed it.

I, like most developers, learn things when I need to learn them, rather than just studying trivia just for fun.  Thus, I learned Linq – because I wanted to write an indexing framework.  On a Friday night.  During which time I wrote 500 lines of code.  By the end of that architectural spike, I had the essence of i4o working.  I then spent the next Saturday – another 8 hours or so, cleaning things up and handling some corner cases.  No experience to working software that – now – actual software companies like Component ONE are copying and selling for money (see LiveLinq).

The point isn’t that I was, or am, some sort of genius.  Actually, I am a rather ordinary software developer.  The thing is though that despite all the world’s APIs, I understand computer science.  In college, we had classes for:

  • Algorithms and learning the meaning of computational complexity (i.e. why a hashtable is faster than a linked list – and why the former takes up far more space)
  • Software Design – where you learn about the general value of reducing coupling and limiting scope of variables (the “fewer moving parts” bit of software engineering)
  • Compilers – so you understand what happens when you, well, compile from the language into native code
  • Language Paradigms – Procedural, OOP, Functional (F#, Haskell, etc.), Logic, and yes, God’s Language, Lisp
  • Operating Systems – so you understand the environment of most things you will write, what processes and threads are, etc.
  • Databases – so you understand how things generally get persisted, normal forms, and so forth

Frankly, everything important I know about software architecture is in one of these, or a small number of other more fundamental areas.  When I operate in a programmer role, I only decide to understand what I need to understand when I need to.  Lets put it this way, if I had to design a multi-threaded system in Java in 3 days, I probably could.  Not to take anything away from Java gurus, but given I know that Java is a language that generally runs on a JVM, that it probably has a thread system, that there are probably some libraries people use to manage that and not have to operate on thread primitives most of the time, I could be reasonably competent in not very much time.

But this is really the symptom of the larger problem.  The real issue is that some companies, when they hire software developers, hire them like contractors.  I understand testing for how well someone knows a given part of an API if all you are going to do is bring them as an expert in that API for a month.  In consulting, we run into that interview all the time, and expect it.

The problem is when companies who are hiring for long term – who should care about very different things, start with questions like “what are 4 methods supported by all delegates in .NET? (know 3… not good enough… gimme 4 you idiot!)”.  I am convinced that people who do this kind of interviewing really don’t care that much.  They want an easy screen that is easy to administer, makes them feel smart (because it is their own favorite API), and gives them plausible deniability if a hire fails (well, he passed the “hardest test we had”, not my fault he came in and messed up the group).

Real interviewing is hard.  I don’t know all the answers, but a a good starting place is Joel’s “Guerrilla Guide to Interviewing“.  And for the candidate, frankly, I would tell you, strongly consider whether you would want to work for an organization that relied on quiz show, trivia question interview techniques.  While not reliable, there is a pretty good unscientific correlation between “cultures of asshole” and places that use quiz show interviews.

How Technology Consulting Firms Die

I recently got an email from 4 former colleagues, all on the same day, that a firm I used to work for a long time ago had missed payroll. It was a very saddening thing, for sure – one of those things that make you ache for people that are stuck in companies that are falling apart. Because of the nature when bad consulting firms die (bad economies) rather than limp sickly along (good economies) – the death of a firm almost always happens at the worst time for the true believers who stuck through to the end.

How does this happen though? What is it that makes a firm die.

At one level, technology consulting is not that complex of a business. You have people, you bill them out on projects, and the difference between what they bill and what they cost is your profit. How can you possibly screw that up?

A healthy firm retains earnings during the good times, so it can carry at least some of it’s people through the lean times – at least to a point. There are firms that don’t do this, firing savagely exactly to demand (aka “zero bench”), but most of them quickly devolve into body shops since people generally figure out when they are being sold a consulting company when they really are working in a contracting company. If we are talking about consulting, then we have to assume one of the functions of the consulting firm is to smooth out demand so that consultants can be buffeted against the raw ups and downs of the markets. A firm that fails to put up these buffers does not die in the sense I am talking about, but rather, it simply morphs into a staffing company.

When a consulting firm dies, on the other hand, it is usually when whomever runs it decides to suspend reality and operate as though things are fine for far too long. Consulting firms who experience sales lulls will have to lay off consulting staff at some point. If demand goes down 20% over the course of a year, and it stays there, there will need to be adjustments to staff to meet the new lower level of demand. Cutting too slowly typically will cause utilization of the entire consultant base to slip below the minimum level to create any profit at all. Such a firm starts to take on debt to keep people, since there is no other source of money to make payroll.

What happens then? Well, taking on debt means that, all things being equal, getting to “even” will be harder. Since getting even is more difficult, riskier and risker projects have to be undertaken, or the cuts that do occur have to be of the much more savage variety. The action that gets taken, at this point – tends to be much more difficult, harmful to morale, and ultimately, hurts the chance of recovery in the first place.

By this time, if fear has not set in yet, it probably is now. Everything is high stakes. Every deal *has* to get done. Even if it means compromising the estimate, lying to the customer, or otherwise taking more risks. Round and round we go in the death spiral, until there is nothing left other than those few consultants who managed to survive despite the company – being sticky at their client – rather than because of the company.

Sadly, by this time, the number of billing consultants bringing in revenue is small, but the management overhead has not shrunk nearly enough, and even if you operate a zero bench, and paid off the debt, AND cut salaries significantly, it still can’t make money. Making payroll becomes an act of further and further desperation, until such time as things like receivables loans are being taken out. It is not long before bankruptcy ensues, and the only asset left are the aforementioned consultants who are on long term staff augmentation assignments. If that. Sometimes, nothing is left whatsoever.

How can a firm avoid this? It helps to make sure – no – make certain – that overhead is being managed aggressively. And by overhead, we mean managers who don’t bill, directors who don’t bill, IT departments that make internal tools, and so forth. You may need some of these things, but especially during a recession, you need to look at each of these positions, especially the high level ones that tend to try to build empires of other non-billables. Personally, the humane thing to do, in my opinion, is to try to use the network you generate in the firm to find external jobs for those folks, rather than just fire em. That way, instead of having a pissed off former executive, you have a guy grateful that you made a smart business decision and found them something else to do – and possibly a new *buyer*. While I am not a big fan of consulting firms acting as job placement firms, doing so for high level non-billable staff is a big exception, as far as I am concerned.

The next thing to avoid this is to be brutal about honestly. If the pipeline really looks terrible, you have to be honest with people, and you have to be honest with yourself. It might mean you have to let people go. Doing so carefully, and based on merit – i.e. actual skill relative to salary – to the degree you can backfill projects – is critical. If you are not transparent about why certain people stay or go, it will be assumed it is based on spurious political factors. If you are going to do it on trailing 12 month utilization, at least be honest about it, so people understand the reasons.

The third thing to avoid is to make sure you continue to invest in the people you intend to keep. This is not the time to stop investing in training, networking events, or god forbid, allowing your sales people to invest in developing the business. Bad times are when you need to distinguish your capabilities and be very smart about your investments, not simply stop.

Lastly, it is critical to think with your head, not with your heart, when confronted with bad times. I see more firms get in trouble because the decision makers make those decisions out of fear, rather than evidence and data. Fear spreads, causing people to react too harshly, cut too savagely, estimate too aggressively, over-promise, and under-deliver. Check your fear at the door – don’t make business decisions from the same place you run from tigers.

Recessions are awful times. However, they do have a useful function, in that they rightfully kill off firms that ride the tide up during good times – but have no foundation to survive bad times. The upside is that better firms can take up the old project portfolios, usually doing a lot of fixing of problems that the old firm caused. Thankfully, when better times return, those survivor firms are the first in a position to pick up the consultant/victims of the previous firm.

New i4o Release – Fluent Syntax, IIndexSpecification

Now that my book is largely done, I finally have time to focus on some things that have not received the attention they deserve lately.  Thankfully, Jason Jarett was kind enough to introduce some great new ideas to i4o, which after having mulled over them for far too long, I am releasing into the wild as of this weekend.

Details of the changes are nicely documented on his blog.

The jist of the changes though are to introduce a better way, leveraging lambdas, to specify an index (the new IIndexSpecification<T> interface).  Prior to this release, you either had to use attributes – something you can only really do with code you control, or you had to use strings to specify the property.  IIndexSpecification<T> is a nice seperation of those concerns, so that your classes can truly be not concerned about how they are being indexed (as we have done with the POCO changes from the previous release), while more easily being refactored (i.e. member name change refactoring will now work with indexes).

In addition, performance improvements to reduce the number of lookups using reflection have been introduced as well.

I really owe a huge debt of gratitude to Jason, who took it upon himself to introduce these features and share them with the world.  I am very excited about how this has evolved over the past year and a half.

As for where we go next, now that I am done with the book and have more time to work on open source projects, the next round of changes will (finally) widen the number of query types that can leverage the index, similar to the work Rocky and I did with indexing in CSLA.  Look for that sometime in April/May of this year.

Follow

Get every new post delivered to your Inbox.

Join 30 other followers