Stories about Software


Killer CEO Interview Questions

I’d like to have a little fun for this Friday post.  I’m sitting on a plane, where I paid for wifi to take care of a few late in the day items.  Those took less time than I was expecting, so instead of the cross-post I was planning, I’m going to do this post.

Someone on twitter linked to this article, and Rands had previously linked to it, so I thought it must be worth a read.  It’s titled, “We got 10 CEOs to tell us their one killer interview question for new hires,” so I immediately thought, “Rands… why?!”  Off the cuff, it seemed like a standard Buzzfeed piece, filled with typical interview mythology where we’re asked to assume that something is profound because Warren Buffet asked it, or something.

As I read through it, though, something struck me.  Most articles like this are written by corporate pragmatists, for corporate pragmatists.  As such, they are ispo facto not interesting from a realpolitik perspective.  They are, to draw on Gervais Principle lexicon, gametalk.  “‘What’s your greatest weakness,’ should be answered with, ‘well, try to find a way to describe a strength as if it were a weakness!'”  Thanks for that insight, Dale Carnegie!

But as I read the article, it dawned on me that there were potentially non-zero stakes, and that these were actually questions that opportunists might gamely pose to other opportunists.  In other words, this isn’t “CEO says that these are questions grunts should be prepared to answer when asked by grunt-managers.”  Instead, it’s, “this is something I would ask a C-level person because I would find the answer interesting.”  (And finding the answer interesting might be entirely orthogonal to a hiring decision).


So here are the questions, along with what I’d posit as the right answer from any self-respecting opportunist (answers in normal print, commentary in italics).

Read More


Is Unlimited PTO a Good Deal for Me?

True to my promise from last week, I am making a more concerted effort to bun down the queue of reader questions on my blog topics Trello board.  Thus, today brings you another answer to a reader question (one of these days, I may get around to doing video answers).  I am actually obfuscating this question somewhat, as the verbatim question could potentially be specific enough to identify the parties involved.  But here’s the thrust of it.

I recently received a job offer from a company that I’d been interviewing with, and it made no mention of PTO/vacation or time off in any form.  Assuming it must have been an oversight, I asked about it on the phone when discussing the offer, and they said they don’t track time off — it’s unlimited.  As long as various stakeholders are happy with their work, they don’t care how much time people take.  Is this a red flag for my prospects of working for this company?

My gut reaction to this, upon reading, was, “no, that’s awesome!”  In a corporate world whose defining feature may be treating adults like children (I have this slated in my backlog as a future post), this seems refreshingly adult.  Get your stuff done and we’re not going to bean-count how you spend your days.  It reminded me of something I once said to a person reporting to me when she asked if it’d be alright to duck out an hour early if she worked an extra hour the next day: “I don’t care how many hours you work in a day if you’re doing good work, so please don’t make when you come and go from the office something I have to care about.”

My secondary reaction was to start and think, “get that language written into the offer letter; have them amend it to state explicitly that they offer a discretionary amount of time off.”  That was the core of the message that I conveyed privately to the submitter, without going too far into detail.  So, over and done with, I suppose.

But this got me to ruminating a bit more on the topic in general and about the strange nature of the corporate vacation concept.  Does this nameless company have it right, following orgs like Netflix that famously buck the convention of tracking PTO?  Is this a good way to reward awesome, trustworthy folks with appropriate trust?  Or is this a trick to seem generous, or even to sneakily save money while knowing that social pressure will actually prevent employees from taking all that much time?


Unlimited?  Really?

Before anything else, let’s get a little more precise about terminology.  Unlimited vacation sounds like just the kind of thing that they’d offer at a Shangri La organization far too selective for the likes of you, thus creating a Catch-22.  If you’re good enough to work somewhere that “adequate performance gets a generous severance package,” then you’re not the kind of slacker that would take advantage of unlimited vacation, anyway.

Read More


We’re Not Beasts, So Let’s Not Act Like It

If I were in the kind of blogger that sought readers via click gimmicks, I might title this post, “In Business, You’re Either a Partner or an Asset.”  Actually, on reading that, it still wouldn’t exactly be juicy click bait, but it’d at least be less nuanced and more provocative than my actual point here.  Maybe.

On Cats and Humans

Rather than get to the point, I’ll lead with a parable of sorts.  Let’s say that I were an aspiring entrepreneur in the death market, and that I were interested in “niche-ing down.”  I wanted to start an extermination business, and, specifically, a mouse extermination business.  You’ve got mice?  Call Erik — the mouse-killer.

Toward this end, I establish two distinct service products.  The first is that I’ll dispatch a mouse-removal expert to your house to take a more-or-less scientific approach to mouse removal.  This person will wander around your house, doing whatever it is that exterminators normally do, dispatching poison and such.  This will cost you $100 per hour.  The second service product is that I’ll rent you a cat for $15 per day.  The cat will wander around your house, doing whatever it is that cats normally do, which presumably includes chasing and sometimes killing mice.

The difference in price is significant, but it also makes sense.  The exterminator, while onsite, will focus in laser fashion on your mouse problem.  He’s basically a consultant, dedicated to helping you with your mouse problem.  His time is valuable.

The cat, on the other hand, will do whatever it wants.  It will arrive onsite and most likely take a nap.  It will then wake up, meow for food, wander around the house, purr and put its anus near your face, spend a weird amount of time sniffing a couch cushion, and then, maybe, take an interest in the scrabbling sound in your wall that represents the mouse problem.  Or, maybe it won’t.  Maybe you’ll just have to wait until tomorrow or the next day.  Eventually, the cat will be sufficiently interested to do something about the mice, but that’s clearly going to proceed according to the cat’s calendar and not yours.


Read More


BDD in .NET for Complete Initiates

Editorial Note: I originally wrote this post for the Infragistics blog.  You can check out the original here at their site.  Go on over there for content from me and a bunch of other authors as well.

It’s pretty likely that you’ve heard of behavior-driven development, or BDD.  Maybe it’s just in the context of buzzword fatigue and wondering “how many different approaches to software have acronyms that end with DD?”  Whatever your level of cynicism, or lack thereof, BDD is worth a look.

A lot of my work over the last few years has involved coaching and mentoring on the subject of writing clean code, and I often tell initially skeptical developers that they should be writing methods that BAs and managers could more or less read (in places pertaining to business logic, anyway).  This isn’t as far-fetched as it sounds.  Think of a bit of code that looked like this.

Would it really be such a stretch to imagine a non-technical person being able to look at this and understand what was happening? Take an order to be evaluated, look through each of its line items, and check to see if the product they contain is in stock. You don’t need to be a programmer to have an idea of what’s happening here.

BDD From 10,000 Feet

BDD in essence, is taking this idea and expanding upon it by making domain-oriented conversation a part of software acceptance.  Don’t worry about “how” just yet.  Suffice it to say that you and various non-technical stakeholders can sit down together and write tests, in plain English, that can be run to demonstrate that system requirements are being met.  That’s pretty powerful.


Read More


The Architect Title Over-Specialization

Sometimes in the month or so after New Years, things pop into my head as “micro-resolutions.” Basically, it’s stuff that I ought to start doing that doesn’t rise to the level of importance of altering my life. One such thing is balancing the sorts of posts that I make here. I want to start getting a little more even between how-to/coding, “life of a programmer” posts, and answering reader questions. Toward that end, here’s a reader question.

You’ve mentioned the fact that you don’t like the title “architect”. I agree with you because architect has different meanings for different organizations.

I have [seen] that it can involve writing code, designing UML diagrams or just write Word documents.

Don’t you think that a developer should be [a] programmer who is also an architect and a problem solver?

In my career, I’ve held all of these job titles, so it is with some degree of admitted hypocrisy that I offer my honest opinion.  This is certainly a subject that I’ve covered in the past, and covered from a variety of angles.  It’s no secret that I don’t put a lot of stock into job titles in general.  But I don’t know that I’ve ever, specifically, held forth on the difference between architects and developers, either in terms of what I perceive it to be or what I think that it should be.  The question here, as I read it a little between the lines, might be rephrased as, “shouldn’t every developer wear the architect hat” or, perhaps, “shouldn’t architecture be any developer’s responsibility?”

Simply put, my answer to that is, “yes.”

Yes, every developer should be a programmer should be an architect and problem solver.  Yes, every developer should wear the architect hat.  Yes, all developers should take responsibility for ‘architecture.’  Now, with that out of the way, I’d like to dissect the architect-programmer distinction a bit.  And in this dissection, I think we’ll get to why there’s so much of the fuzziness alluded to in the reader question around what the term actual means.

Consider programmer/software engineer versus architect as a study in contrasts (I used this post by Simon Brown as a research point for what people perceive to be the differences between architects and developers).

  • Focus scope: programmers focus on details while architects focus on “the big picture.”
  • Leadership: programmers are led and architects lead.
  • Seniority: architects have been doing it longer than programmers.
  • Cachet: architects are important visionaries while programmers do relative grunt work.
  • Tech Selection: architects choose while programmers live with the choices.
  • Skill: architects are more technically skilled than programmers.
  • Code: architects write less code on average than developers.
  • Organizational interaction: architects deal more with “the business” in meetings than programmers.
  • Pay: architects make more than programmers.
  • Value (status): see the last bullet and understand that an architect is more valuable than a programmer.

This is how the industry at large perceives this distinction.  Architects are more tenured, important, valuable technical people that are in high demand, but often too important to do the thing that earned them their stripes (writing code).  It’s confusing and even contradictory, and this intrinsic role-fuzziness is what leads to the lack of standard across the board.  It’s why architects in some organization churn out UML diagrams while architects in others are indistinguishable from software developers except by job title.


Read More