TSQL Tuesday #93: The buzzword arms race


This month, T-SQL Tuesday, the monthly blog party started by Adam Machanic back in 2009 (!), is hosted by Kendra Little (b | t). Kendra’s choice of topic is Interviewing Patterns & Anti-Patterns, a “soft” subject I’d normally shy away from. But darn it, I’m going to play along for a paltry few paragraphs.

Out of the comfort zone

I guess I’m a classic geek who patiently takes the time to engage with code, but have my blind spots on the soft skills side. Be that as it may, some years ago I had to sit in to help with the technical side of a job interview. I prepared a list of straightforward and not-so-straightforward questions, and felt prepared to push only as hard as was sensible for the candidate, and to let him lead into his own comfort zone if required.

Things started out okay. I asked questions, we embroidered on his answers, and he came across as pretty confident. But I found myself straining to really follow some of his explanations. Not his command of language, but simply whether he was sure what he was talking about.

As I started working harder to parse his explanations, I think it turned into an arms race. Whether by devious design or an unfortunate style of communication, he came into focus as somebody experienced at constructing sentences which sound superficially impressive, while avoiding clear statements. So my manner probably got a bit more aggressive as I tried to poke holes in his answers, and his buzzword emission frequency increased in response.

In the end, I wasn’t convinced by him at all. But I can’t honestly say I would have been able to make a fair comparison between him and someone else by that point. Thing is, I was turned off by the defensive mechanism that didn’t allow him ever to say “I’m not sure” or “Not my area of expertise”, and the slickness of his technique smelled of bull to me.

Maybe that approach is a great survival mechanism for some people, and maybe they only play that overconfidence card in interviews, rather than on the job. Perhaps I handled him really badly – if I played it better, he wouldn’t be on that defensive footing, and he would have come across as a better candidate.

Oh well, it’s back to reading the subtext in source code for me.

#TSQL2SDAY: The string length server


It’s the second Tuesday of the month, and we all know what that means. T-SQL Tuesday, the brainchild of Adam Machanic, is hosted by Kennie Pontoppidan this month, and his chosen theme is The daily database-related WTF.

What could possibly go wrong?

The story

Basic algorithms are a bit passe when it comes to interview questions nowadays, but time was when it was reasonable to sound out a developer by asking them simple things like how to measure the length of a string. After all, edge cases lurk in unexpected places.

Of course, nobody rolls their own strlen() or String.length() anymore. It’s a solved problem, and we can spend our time on more interesting questions, like “how can we wrap up the string length puzzle in a suitably odd framework?” Enter the Universal Enterprise Form Workflow System, stage left.

Because developers are expensive

When you spend a reasonable amount of time churning out simple form-based UI workflows, you inevitably get bored. And you try and abstract away the drudgery of building forms into something the Common Folks can manage, by building a framework, because Lord knows you can’t buy this sort of thing off the shelf. Inevitably, the arcane knowledge of how to churn out expensive work without obviously doing expensive work can safely stay within an inner circle of senior developers who will be the only people ever allowed to try and configure a no-programming-needed workflow.

Never mind. Their hearts were in the right place.

Workflows were strung together by stored procedures following standard templates, bound to form inputs using some manner of configuration sacrament. The details are lost in the mists of time. But one thing was clear: a configured workflow could not involve any logic other than simple switch statements driven from the output of these stored procedures.

Then arrived the day when stone tablets carven with business requirements arrived from on high, and lo, there was a need for data validation of the form “Twenty shall be the length of the string, and the length of the string shall not exceed twenty.”

After the requisite number of arguments against sullying the purity of the framework by trying to make it measure strings, the solution was agreed upon. From this day hence, there shall be deployéd a stored procedure which, given a varchar parameter, wouldst return a result set containing one column. And the value of that column shall be as a sign unto the unbelieving masses, proclaiming the final judgement of an enterprise-class relational database management system upon the question “Was my input string no more than twenty characters long?”