posted Feb 3, 2014, 12:15 AM by Jerry Dawson
I made a pig's ear of an interview the other day. Asked what SOA is, I waffled unconvincingly for a few minutes, sounding apparently like I'd just read about it on Wikipedia. Pretty hopeless, given that I've been implementing SOA's for a decade now.
Now partly this was because I was a bit nervous; it was the first time I've been that side of an interview for 18 months. But partly it was because I'm becoming increasingly disenchanted with spouting theory that's divorced from practicality. I've hired quite a few people in recent years who have talked the talk very well, but when it comes to actually delivering, they are unable to apply theory to practice. This can apply to developers as well as architects; the difference being that an architect can often pull the wool over enough senior eyes to convince the folks who sign the payslips.An incompetent developer will usually get found out quicker. The dev who struggles to make the compromises between theory and practice will often get frustrated. But the architect who only understands theory and doesn't know how to make an implementable design will drag others down with them. There are anyway a shockingly high proportion of incompetent architects around; my guess would be in the region of 50% of the architects I've met have been pretty much a waste of space. That's nearly as high a percentage as Project Managers! Some of the flavours of hopeless architects out there: those who simply don't know what they're doing; frauds and charlatans who call themselves EA's without any grounds; developers who think being a dev is "beneath" them; middle managers who are grasping at a fashionable label; those who remain stuck in ancient concepts and technologies; and many more. You've probably met some. I think the most damaging type of all though are those who have a good grasp of the theory and can sell the dream to an organisation. Persuaded of the architectural vision, they can prise millions for projects and programs which they are then incapable of delivering. Perhaps the vision was flawed, or perhaps the design was poor. But mostly it will be this: that the architect just has no idea of the operational realities, technical compromises and various constraints that reality throws up which will all scuttle any attempt to implement pure theory. Ask any screenwriter - the finished product on film will bear little resemblance to the film that spooled through the writer's mind during the original creation. A good architectural implementation will be the same: never perfect and never finished, but offering enough function and foundation to grow and improve. So in an interview, how to avoid hiring the architect who's all mouth and no trousers? Well, don't ask a general waffle question like "What is SOA?" or "What is Big Data?" If you're asking a practically-oriented question, let it illustrate the application of theory. (But not too dumb! I was once asked how I'd connect two systems. Convinced there must be a catch in the question I came across as truly stupid as I fumbled for a sophisticated answer. But no, the answer he wanted was "with web services". Needless to say, I didn't get that gig either...) I think one thing I shall try next time I'm sitting on the more comfortable side of an interview, will be to ask them to write a half a page answer to some pratical type question. One common denominator I've found amongst those who can talk the talk is that they frequently express their true ability in the written word. |
|