DaedTech

Stories about Software

By

What’s Your Greatest Weakness: The Employer-Candidate Impedance Mismatch

I recently posted about why you shouldn’t take interview rejection to heart.   I promised at least another post, if not more, to follow on that one, and here I am, making good.  This is where I question the value of interviews as we know them and describe what I consider to be vaguely depressing about the way we come into work.  Naturally, I’ll start this off with a non sequitur about circuitry.

In the world of circuitry, there’s a concept known as “impedance matching,” which, (over) simplified, says that you should match the output impedance of one component to the input impedance of the component into which the first one feeds. In this fashion, you prevent inefficiencies in or possible damage to the circuit that you’re constructing. The term was co-opted and inverted in the world of software (“impedance mismatch“) to describe the awkward transformations that occur when object oriented applications use relational databases to store information. Colloquially, you might say “you’ve got two puzzle pieces that don’t fit together quite right and you’re jamming them together.”

And so it goes, I would argue, with employee-employer matches in the corporate world. Of course, it doesn’t seem like it on the surface when you consider labor as a simple market transaction (or even when you factor in the middle-man, quasi-rent-seeking behavior of technical recruiters). A job seeker is selling labor and an employer demands labor, so the two negotiate on the price, with each trying to maximize its own interest (pay, but also benefits, days off, cultural perks, etc). Cut and dry, right?

Well, not so fast. Employers don’t make hires in a vacuum but rather they commonly hire people with some regularity and have a “general hiring strategy.” Employees do, on the other hand, get hired in a vacuum and their only strategy is maximizing their situation using rational self interest. So employees seek to maximize the perks with the best offer, but I would argue that companies in their hiring optimize for eliminating worst case scenarios rather than maximizing the upside of any individual hire. Put simply using examples and probability theory, consider the following scenario.

A company has a choice. They can hire Alice or Bob. Bob is a known commodity and a decent software developer. He’s not going to blow anyone’s socks off, but he’s not going to check in terrible code. Alice, on the other hand, is a divergent thinker and extremely creative. Based on her history, there’s a 75% chance that she will be a game-changing hire in a good way, delivering way more value than most people, improving those around her, and bringing true innovation to bear. But, there’s a 25% chance that all of the things that make her special will fail to mesh with the existing team, and there will be fireworks followed by a flameout in short order.

In my experience, most companies will tend toward hiring Bob, even though the expected value of offering the job to Alice is higher (calculated, say, by Bob having a 100% chance of delivering a 5 out of 10 and Alice having a 75% chance of delivering a 10 and a 25% chance of delivering a 0). Established companies favor avoiding disaster more than reaching for the stars. Bob has a zero percent chance of delivering a zero, so Bob it is. And so, we have an impedance mismatch between the zero sum games being played by both sides. Applicants operate in a world where each side is maximizing expected value, but companies play in a world where they are minimizing worst case scenarios.

This has a resulted in a depressing process by which job offers tend to happen — an interviewing process focused at every turn on “screening.” Take this test. Let’s do a phone screen. Come in for a first round interview. All of these activities are generally oriented around thinning the herd rather than finding the leader, and they’re also intrinsically tolerant of false negatives. Gotta break some eggs to make an omelette or, in other words, “sure, you’ll reject some qualified candidates, but you’ll (theoretically) guarantee that no complete duds will be hired.”

But once you make it past the “screening” hurdles, it switches gears and really does become a matter of selecting the preferred candidate.  That is, in most candidate searches, once all but a handful are screened, the question becomes “which of these do we like best?”  And this question is answered by talking to the candidates for a few hours and then choosing one (or perhaps more, depending on whether hiring is being done for a specific position or to compensate for attrition/allow growth).  So, let’s think about that — after a comparably objective filtering out process comes a largely subjective game of “based on a conversation of a few hours, let’s find someone to spend the next several years with.”

I have an operating hypothesis that I’m not really in any position to test for the time being.  So, be warned — here comes some frankly unsubstantiated conjecture.  My hypothesis is that this reductionist “pick the best of five” activity would be no different, statistically, than random selection of a candidate.  However much we might think that this personal interaction-based reading of the tea leaves brings the ‘best’ candidate to the top, it really doesn’t matter.  For every “bad attitude” candidate you successfully pass on, you’ll filter out “better attitude having bad day.”  For every candidate you hire because she nails the “what’s your greatest weakness” question due to cultural fit, you’ll hire someone whose greatest weakness is being a lying but convincing sociopath.  The “interview five, pick one” process strikes me as the same kind of process I go through when squinting at mutual funds for 10 or 15 minutes before deciding how to allocate my 401K.  I have no idea what I’m doing, so I just pick one and hope that everything works out.  My hasty “research” is entirely a self-administered placebo designed to make me feel better about some kind of due diligence.  And that’s how we, as a society, hire people.

So, the typical hiring process is one that is designed to first filter outliers and then secondarily to pick from the best of those still standing.  But there are two core problems.  Filtering outliers means filtering all outliers and not just the bad ones, meaning a potential drive toward mediocrity (or at least standard) and picking from among the best is essentially (axiomatically, here) window dressing on random choice.  So the candidate search, for all its clever questions, stress interviews, fancy clothes, synergies and whatever else we dream up really just boils down to “filter for slightly above average and pick at random.”  And I’m pretty sure that you could do that with submitted SAT scores and a dartboard, saving everyone time, money, and dry-cleaning bills.

Before you think I’m some kind of self-righteous voice from the clouds with everything figured out, I’m not.  I’ve conducted and participated in this process, willingly, from both sides.  I think everyone would agree that candidate selection is a reductionist activity with an insanely high margin for error and the fact that many companies have actual protocol in place for dealing with hiring misses attests to that very fact.  Gains made by introspection tend to be heuristic and not algorithmic, but I’ve played the good soldier with the rationale of “this is the worst way of doing it, except for all of the other ways I’ve considered.”

I still don’t have a particularly concrete solution, but I do have the beginnings of some ideas.  Github is quickly becoming an industry standard place to say, “look what I can do, left to my own devices.”  Stack Overflow is a place where not only can developers showcase their knowledge and accumulate points, but they can prove to would-be employers that their peers consider them to be knowledgeable.  Blogs are somewhere that interested employers can go to see whether a candidate would be a good fit in a waterfall shop. Coderbits pulls a lot of theses sources together into a single point of information.  These sources of information are freely available, asynchronous, and aggregate.  My life is summed up much better in these venues than it is by me sitting in a conference room, wearing a suit, and talking about a time I faced and overcame a challenge.

But I think there’s room for additional improvement as well.  How better to know whether a candidate will do well on a project than putting that candidate onto that project?  What I’m about to talk about is not currently tenable, but imagine if it were.  Imagine if there were a way that an organization could structure its work in such a way that onboarding time was virtually nil and so prospective developers could be tossed an assignment and get started on contract.  Is it working out after a week?  Great!  A month?  Great!  Now it’s been six months?  Great — let’s move to a more permanent W2 arrangement and thus from dating to marriage.

Employers could dispense with the prognostication games and tests and simply shuffle ‘candidates’ in and out, keeping the ones that were the best fit while passing on the ones that weren’t.  For candidates, this is great too.  You’d no longer be faced with these, “do I take this huge, life changing leap or pass and watch my situation deteriorate?” decisions and be able to generate income while shopping around.  A mutual feeling out period would allow a fit based on experience, rather than conjecture and games.

There are two enormous hurdles to this.  The first is the problem of benefits and the mind-numblingly unfortunate practice of health insurance being tied to employment.  If the USA has a spasm of collective sanity in this regard, perhaps that problem will go away at some point.  The second problem is actually making it viable for organizations to take on developers and have them go from unknown to “writing productive code” in a single day.  And solving that problem is also non-trivial.

But personally, I’d like to see more discussion around hiring processes that involve trial periods and shortening of obligatory worker-labor consumer relationships.  This isn’t to say that I think everyone should endure the stress of a job search on an almost constant basis, but rather that I think it should be easier for people and organizations to move seamlessly into arrangements that are better fits.  We should dispense with the pretense that indefinite stays are the norm and recognize that it’s going to vary widely by individual taste and personalities and projects involved.  In the end, moving in a direction like this could conceivably do wonders for morale across the industry and go a long way toward eliminating institutional knowledge hoarding in favor of beneficial cross pollination.

Update: This post has been in my drafts folder for a week, but I happened recently to stumble on this video:

“Pick the fourth resume from the top.” I’m not alone in my hypothesis that random selection would be a reasonable replacement for conversational interviews.

By

How to Prepare for Windows 8.1 Update Fail

I was going to publish the next Chess TDD post today, but I got caught up in the worst kind of yak-shaving where I was basically just trying to get my computer functional again. So, I didn’t get the audio recorded, and I have something different to talk about, to-boot.

Last night, I stayed up late programming and left my computer on. This morning, I got up and it had powered off for some reason or another. When I turned it on, it told me that it was installing updates. Whatever, new OS (for me), same difference on the updates. Except, this time it got to 99% installed, stayed there for a really long time, and then eventually came back with the message:

We couldn’t complete the updates
Undoing changes
Don’t turn off your computer

I let this go for around 45 minutes before figuring there must be something wrong. I did a hard reset, and it booted right back into that screen. Tried again, same result. Let it go for another half hour, nothing. At this point, I tried to boot into safe mode, but there are apparently six different ways to do it and three of them don’t work because Windows 8 is too fast or something. It appeared as though the only way to boot into safe mode was to launch the OS normally and enable it. Sigh.

I figured I could boot from some kind of media, but none shipped with the PC. I figured I could make one, but all of the guides about making Windows 8 recovery CDs/USB Drives all seemed to start with “boot into Windows 8 and…” Double sigh. So, pretty much everything you might do to recover the machine in light of an unexpected problem involves you having prepared ahead of time for such a problem. And, while it’s certainly good practice to do so, it hadn’t occurred to me that the source of instability would be an OS update. And, apparently, it’s a common problem with this update that has yet to be fully resolved for everyone.

To solve my problem, I eventually managed to mash F8 at just the right time, get the advanced startup menu, and find a restore point that had been set yesterday morning. After wasting a couple of hours of my life, I’m going to take steps to prevent this kind of nonsense and minimize headaches. If you’re running Windows 8.1, I’d suggest that you follow some of these relatively quick steps. They’ll take you little time and, since these updates seem rather issue-prone, they might save you a huge headache later.

So here’s what I’m doing.

Turn off automatic updates

The last thing I want is to go to bed tonight and have a repeat of this morning. If updates are going to be a source of problems, I want to be opting into them instead of having them pushed. To do that, go to the start screen and type “Windows Update,” which will return the Windows Update menu. Go to “Change Settings” and you can choose a less aggressive setting. I chose “check for updates but let me choose whether to download and install them.”

Updates

YMMV on how you want to handle this, but it might be a good idea if you don’t want some update bombing out and costing you a couple of hours.

Make Sure Safe Mode is Accessible

I lucked out in that I was able to get into safe mode, but having that be a crapshoot is silly (and, in my opinion, should absolutely not be the default setting). Here’s a guide for how to do this. You basically have to run a command line utility to make it happen. It might marginally slow down your boot. Whatever, this is a no-brainer, and shaving a few seconds off of boot time at the risk of not being able to launch the OS in safe mode is completely not worth it.

Create a recovery USB Drive

Here are instructions for doing this. I haven’t actually done this one yet, but I’ve ordered a USB drive for the purpose and will do it when it gets here. It never hurts to have options and since my computer didn’t ship with an OS disk, I think this is something I should have.

Here is an alternative method if you’d prefer to use a DVD.

Create a custom refresh image

Windows 8 has a refresh feature that will basically reinstall the OS while leaving your files and Metro apps alone. However, it will blow away your installed applications, which is a bummer. You can create your own refresh image that will include the things you’ve installed, though. Instructions for that are here. I believe you’ll still have to reconfigure your applications when you launch them, but it’s better than nothing.

Create a system restore point before updates

It probably never hurts to create system restore points to recover to (and you can actually use them if you do the F8 enabling). But, given the trouble with system updates, it might make sense to create them immediately prior to trying an update. Here’s a “dummy’s guide” if you’re so inclined, but if you just type “restore point” at the start screen, you can probably figure it out from there.

Remove any extraneous things plugged in

After I had started writing this post, I continued to try to update because I needed to upgrade to Windows 8.1 Pro and because I wanted the problem solved. In the end, I wound up doing a complete “refresh” and then unplugging various things from the USB ports, including a Fitbit and my USB web cam. After these steps were taken together, I was finally able to get through the offending update. I can’t say for sure, but I suspect the latter cause, particularly because at one point I’d found a blurb about someone having the same experience.

So as a good troubleshooting step, you might consider ripping out everything not strictly necessary (and perhaps disabling various applications that startup at boot and anything else not necessary).

Good Luck and Happy Computing

An ounce of prevention is worth a pound of cure… I learned the hard way, today. Hopefully this saves you some headaches, particularly if Microsoft belches out a problematic but ‘mandatory’ system update. I encourage you to do some of these things (at the very least, make sure you can run the OS in safe mode when it’s not critical) now before you’re panicked or furious.

By

The Secret to Avoiding Paralysis by Analysis

A while ago Scott Hanselman wrote a post about “paralysis by analysis” which I found to be an interesting read.  His blog is a treasure trove of not only technical information but also posts that humanize the developer experience, such as one of my all time favorites.  In this particular post, he quoted a stack overflow user who said:

Lately, I’ve been noticing that the more experience I gain, the longer it takes me to complete projects, or certain tasks in a project. I’m not going senile yet. It’s just that I’ve seen so many different ways in which things can go wrong. And the potential pitfalls and gotchas that I know about and remember are just getting more and more.

Trivial example: it used to be just “okay, write a file here”. Now I’m worrying about permissions, locking, concurrency, atomic operations, indirection/frameworks, different file systems, number of files in a directory, predictable temp file names, the quality of randomness in my PRNG, power shortages in the middle of any operation, an understandable API for what I’m doing, proper documentation, etc etc etc.

Scott’s take on this is the following:

This really hit me because THIS IS ME. I was wondering recently if it was age-related, but I’m just not that old to be senile. It’s too much experience combined with overthinking. I have more experience than many, but clearly not enough to keep me from suffering from Analysis Paralysis.

(emphasis his)

Paralysis by Lofty Expectations

The thing that struck out to me most about this post was reading Scott say, “THIS IS ME.” When I read the post about being a phony and so many other posts of his, I thought to myself, “THIS IS ME.” In reading this one, however, I thought to myself, “wow, fortunately, that’s really not me, although it easily could be.” I’ll come back to that.

Scott goes on to say that he combats this tendency largely through pairing and essentially relying on others to keep him more grounded in the task at hand. He says that, ironically, he’s able to help others do the same. With multiple minds at work, they’re able to reassure one another that they might be gold plating and worrying about too much at once. It’s a sanity check of sorts. At the end of the post, he invites readers to comment about how they avoid Paralysis by Analysis.

For me to answer this, I’d like to take a dime store psychology stab at why people might feel this pressure as they move along in their careers in the first place — pressure to “[worry] about permissions, locking, concurrency, atomic operations, indirection/frameworks, different file systems, number of files in a directory, predictable temp file names, the quality of randomness in my PRNG, power shortages in the middle of any operation, an understandable API for what I’m doing, proper documentation, etc etc etc.” Why was it so simple when you started out, but now it’s so complicated?

NervousTestTaker

I’d say it’s a matter not so much of diligence but of aversion to sharpshooting. What I mean is, I don’t think that people during their careers magically acquire some sort of burning need to make everything perfect if that didn’t exist from the beginning; I don’t think you grow into perfectionism. I think what actually happens is that you grow worried about the expectations of those around you. When you’re a programming neophyte, you’ll proudly announce that you successfully figured out how to write a file to disk and you’d imagine the reaction of your peers to be, “wow, good work figuring that out on your own!” When you’re 10 years in, you’ll announce that you wrote a file to disk and fear that someone will say, “what kind of amateur with 10 years of experience doesn’t guarantee atomicity in a file-write?”

The paralysis by analysis, I think, results from the opinion that every design decision you make should be utterly unimpeachable or else you’ll be exposed as a fraud. You fret that a maintenance programmer will come along and say, “wow, that guy sure sucks,” or that a bug will emerge in some kind of odd edge case and people will think, “how could he let that happen?!” This is what I mean about aversion to sharpshooting. It may even be personal sharpshooting and internal expectations, but I don’t think that the paralysis by analysis occurs as a proactive desire to do a good job but out of a reactive fear of doing a bad job.

(Please note: I have no idea whether this is true of Scott, the original Stack Overflow poster or anyone else individually; I’m just speculating about this general phenomenon that I have observed)

Regaining Your Movement

So, why doesn’t this happen to me? And how might you avoid it? Well my hope is that the answer to the first question is the answer to the second question for you. This doesn’t happen to me for two reasons:

  1. I pride myself not on what value I’ve already added, but what value I can quickly add from here forward.
  2. I make it a point of pride that I only solve problems when they become actual problems (sort of like YAGNI, but not exactly).

Let’s consider the first point as it pertains to the SO poster’s example. Someone tells me that they need an application that, among other things, dumps a file to disk. So, I spend a few minutes calling File.Create() and, hey, look at that — a file is written! Now, if someone comes to me and says, “Erik, this is awful because whenever there are two running processes one of them crashes.” My thought at this point isn’t, “what kind of programmer am I that I wrote this code that has this problem when someone might have been able to foresee this?!?” It’s, “oh, I guess that makes sense — I can definitely fix it pretty quickly.” Expanding to a broader and perhaps less obtuse scope, I don’t worry about the fact that I really don’t think of half of that stuff when dumping something to a file. I feel that I add value as a technologist since even if I don’t know what a random number generator has to do with writing files, I’ll figure it out pretty quickly if I have to. My ability to know what to do next is what sells.

For the second point, let’s consider the same situation slightly differently. I write a file to disk and I don’t think about concurrent access or what on Earth random number generation has to do with what I’m doing. Now if someone offers me the same, “Erik, this is awful because whenever there are two running processes…” I also might respond by saying, “sure, because that’s never been a problem until this moment, but hey, let’s solve it.” This is something I often try to impress upon less experienced developers, particularly about performance. And I’m not alone. I counsel them that performance isn’t an issue until it is — write code that’s clean, clear, and concise and that gets the job done. If at some point users want/need it to be faster, solve that problem then.

This isn’t YAGNI, per se, which is a general philosophy that counsels against writing abstractions and other forms of gold plating because you think that you’ll be glad you did later when they’re needed. What I’m talking about here is more on par with the philosophy that drives TDD. You can only solve one problem at a time when you get granular enough. So pick a problem and solve it while not causing regressions. Once it’s solved, move on to the next. Keep doing this until the software satisfies all current requirements. If a new one comes up later, address it the same as all previous ones — one at a time, as needed. At any given time, all problems related to the code base are either problems that you’ve already solved or problems on a todo list for prioritization and execution. There’s nothing wrong with you or the code if the software doesn’t address X; it simply has yet to be enough of a priority for you to do it. You’ll get to it later and do it well.

There’s a motivational expression that comes to mind about a journey of a thousand miles beginning with a single step (though I’m really more of a despair.com guy, myself). There’s no real advantage in standing still and thinking about how many millions of steps you’re going to need to take. Pick a comfortable pair of shoes, grab some provisions, and go. As long as you pride yourself in the ability to make sure your next step is a good one, you’ll get to where you need to be sooner or later.

By

Happy Independence Day

Here in the United States, the 4th of July is Independence Day. Traditionally, this holiday is celebrated with barbecues, warm weather activities, beer, and blowing things up, generally in the form of fireworks both professional and amateur. Given that it occurs on a Friday this year, it’s a big 3 day weekend here for most (though as of last Friday, my life is kind of a constant semi-weekend where I work on weekends), so I anticipate readership being a lot slower than normal as people are going to be at pool parties rather than browsing their RSS feeds.

While I do have several posts that are ready to go, I’m going to save those for next week and just wish all of my fellow American readers a happy 4th, and all of my other readers a happy weekend. To celebrate, please enjoy this picture of a bald eagle holding a sparkler:

PatrioticEagle

By

On My Own as a Free Agent: DaedTech Grows Up

In 2013, I made a mildly rambling life update post. In it, I described that I had decided to leave the job I had at the time with the intention of job seeking and blogging about it all the while (and also possibly striking out on my own). Things passed in something of a whirlwind and, when the dust settled, I had an offer and was back to W2 employment the Monday following my last Friday at the previous job. So many lost opportunities for interview anecdotes and “holy crap I’m actually on my own” posts about what it’s like to be a freelancer.

Well, the good news is that I’ve managed to double back after taking the commonly traveled road and set out this time on the one less traveled. Take that Robert Frost; I’ve now taken both roads and it has made all of the difference. Anyway, my point here isn’t to antagonize icons of poetry, but to announce that, starting this week, I am now in business for myself.

FakeItTilYouMakeIt

Like last time, my situation is somewhat fluid. I’ve agreed to consult with my now-former company on an extended basis and will continue my work with Pluralsight and on the blog and in the community in general. I have a few engagements lined up, both potential and scheduled, and the aim at this point is to start building and broadening my book of business. But there are also a few companies I’ve had conversations with about various intriguing full time opportunities. So the next month or two will probably be a busy, marginally confusing and formative time for me that is likely to determine the course of my career in the near term future, depending what I decide to do.

If you’re interested in working with me in some capacity, look for updates to the site’s menu soon to formalize and organize my thoughts, but I’ll speak to it a little bit here in the shorter term.  I’m willing to do some software application delivery work — essentially implementing applications needed by prospective clients.  But two areas in which I see myself as a fairly high value add, given my experience, are true consulting and what I’ll loosely describe as coaching and related delivery.

In the capacity of “true consulting,” I can bring a variety of experience to bear, ranging from line level development to C-level departmental management.  If your firm needs advice on implementation or architecture, I can certainly supply that, but I can also help provide gap analysis, recommendations for technical strategy, ROI calculations for software initiatives, help selecting and evaluating candidates/staff developers and plenty more.  Under the heading of coaching, I can help your group out with agile transformations, implementing and selling external stakeholders on accepted best practices (automated testing, continuous integration, TDD, automated builds and deployments, etc), mentoring/teaching developers, performing code reviews, speaking to your group etc.  But beyond that, I’m happy to put my money where my mouth is beyond just coaching; if you want to hire me to clean up your group’s build, move you over to a new source control scheme, refine your ALM tooling, etc, that’s an excellent fit for me.  And, if any of you reading are not in a decision-making position but would like to see these changes implemented in your group, I have a knack for selling management on change and sidestepping Expert Beginners.  We can talk and see if maybe we can’t get a meeting with your management and the winds of positive change blowing through your company’s halls.

Those are the arenas in which I see myself being most valuable to prospective clients, and I really enjoy working with developers and people in the industry, so I’d be happy doing that sort of work.  But really, I’m open to anything that sounds interesting.  If you have an idea for a project you’d like to work on with me, a pitch for a startup, a full time position you need filled (I’d probably really only be looking for leadership roles if I were going to consider W2 work), some writing or developer evangelism (but only if I believe in the product) that you need help with, or really anything you can think of at all, please don’t hesitate to reach out.  I’m always up for a discussion.

I don’t doubt that I’ll have more refined messages about what I’m doing later, and certainly I’ll have posts about my experiences, struggles, and learning moments.  My goal here was just to make a quick announcement of what I was doing and invite those interested in possible arrangements to reach out so that as many interesting opportunities as possible presented themselves.  Someone recently asked me what kind of working I was looking to do, and my eyes sort of widened and a really obtuse response came out before I could stop myself: “interesting work.”  This was actually an intense bout of honesty, though, and I don’t know that I’m looking for too much more than that, in terms of the work.  I’m looking for an opportunity to be autonomous, diligent and creative, and to solve challenging problems.  Beyond that, I kind of grow where I’m planted.  I could be happy working on implementing programming language, detangling a nasty legacy code base, selling your management on the virtues of iterative approaches, cranking out code for a product idea, writing an interesting story about a compelling developer tool, and just about anything in between.  So please don’t hesitate to reach out with anything that you think might be interesting, fun or challenging, and I promise in return, I won’t hold back on relating anything interesting about my experience, even if it’s lessons that I learn from embarrassingly stupid or naive things that I do as a fledgling business owner.