DaedTech

Stories about Software

Apr
28

By

Hiring is Broken… And It Isn’t Worth Fixing

Category: The Life of a Programmer Tags: , , | 52 Comments

Usually I fly home from client sites late in the day, but the whims of fate had me driving home instead, early (for me, anyway) this morning.  The end result was a pocket of uncommon free time this evening, before resuming long days and seemingly non-stop travel on the morrow.  Naturally, I wasted this free time poking around the internet.

My travels led me, via Twitter, to this blog post entitled, “F*** You, I Quit — Hiring Is Broken.”  Apparently, this led to some heated, sometimes-angsty debate on Hacker News, where the original piece earned a good number of points.  And, why wouldn’t it?  “Hiring is broken” would serve as a rallying cry for those who don’t play the interview game well, while seeming a shot across the bow of those who do and are now on the other side of it.

Read the article, please.  You need to for context, because when I reference it further, it’ll just be a reductionist tl;dr.  I’ll come back to that.  First, I’d like to address one of the few points that almost everyone seems to agree on, before they get down to armchair dissection of Sahat’s character and market worth.

The hiring process is imperfect deeply flawed (if not broken), but no one knows how to fix it.

Except, that’s not actually true, because I know how to fix the interview/hiring process.  It’s actually pretty easy.  Just stop doing it.  If the value proposition you’re offering to prospective laborers is so weak that you have to solicit and subsequently torture strangers, you should prioritize fixing your organizational mess above making the mess larger (or, in the case of attrition, before doing the same thing again).

Trivia Interview demonstrate why hiring is broken

I’m honestly not kidding, but let me come back to the mindless growth point later.

Read More

Jan
7

By

How to Detect Sucker Culture while Interviewing

Category: You Asked For It Tags: , , | 35 Comments

I had a reader question come in that was a bit sensitive and specific, so I won’t post it here.  It pertained to receiving a job offer that had some peculiarities around the “paid time off” (PTO) situation.  Given the time-sensitive nature of such a thing, rather than add it to my Trello backlog of post topics, I shot him an email offering a few quick thoughts.  This led to a brief discussion of hiring and PTO in general, and a more general question.

The problem is, I don’t know a way to figure out [whether they have a heavy overtime culture] before you join a company.  How do you ask ‘How many hours will I be working?’

This is a classic conundrum.  Job interviewing advice 101 says, “don’t talk about pay or vacation — impress them, secure the offer, and then negotiate once they like you.”  If you ask about hours or vacation during the interview, you might create the impression that you’re a loafer, causing the employer to pass on you.

In my popular post about “sucker culture” I suggested that you shouldn’t feel guilty for not pouring in extra hours for free.  I then offered a follow up post with ideas for escaping that culture when you’re in it.  But it occurs to me that I haven’t talked about avoiding it altogether.  And that’s really what’s being asked here: how do you avoid sucker culture in the first place, without torpedoing your chances during an interview?

WorkHarder

The advice I’m going to offer here is, for the most part, advice that errs on the side of caution and not hurting your chances during the interview process.  So, as you examine the following strategies, bear in mind that they may result in false negatives for exposing a sucker culture.

Read More

Dec
30

By

The Best Way to Hire Developers

Category: The Life of a Programmer Tags: , | 49 Comments

Editorial Note: I originally wrote this post for the Infragistics blog.  You can find the original here, at their site.  There’s a lot of good stuff over there, so go give it a look.

The other night, I was remembering what might have been my most impressive performance in the interview process.  What makes this performance particularly interesting, however, is not how well I did, but rather how I did well.  And the how left me feeling unsatisfied with myself and with the process.

I was interviewing for a software development position, and this particular organization’s interview process was (1) phone interview, (2) programming exercise, (3) in-person interview. The phone interview went pretty well, and the recruiter had told me that the company was excited about me – a mildly good sign, for whatever it was worth.

However accurate the recruiter’s assessment may or may not have been, the company’s feelings were positive enough to give me the programming exercise.  This all occurred back when I was in grad school, and, at the time of this particular interview, I was in a class called “Advanced Database Design,” in which we explored persistence options beyond the traditional, relational database.  This was a bit of an avant garde class, at the time, because the NoSQL movement had yet to gain a ton of steam.

When they handed me the programming exercise, I had just, in this very class, wrapped up a chapter in which we’d studied using R-Trees to store geographical information.  This unit of study included what they were, how they were used, and a bit of pseudocode to really drive the point home.  As fate would have it, the R-Tree happened to be an extremely elegant solution to the programming exercise for this interview.

BigPileOfMoney

Read More

Nov
4

By

My New Project and Dignity in Hiring

Category: Announcements Tags: , |

I saw this tweet tonight and thought of dignity in hiring.

I admittedly didn’t read through the site in a ton of detail, but notwithstanding that, I found myself feeling a little giddy. Apologies in advance for the spoiler, but one of the main things for which I’ll be advocating in my in-progress book, Developer Hegemony, is that software developers stop commoditizing their labor at pennies on the dollar. Instead, I think they/we should form organizational structures akin to law firms, and sell software expertise as a professional service. With this model, a rising tide will lift all boats. Even the odd staff developer at some non-software company will be paid more like staff counsel than like someone with 4 layers of middle management between them and people that make decisions.

But, I digress. I mention seeing this site because it was a hopeful reminder that better ways of marrying developers with automation needs are on the way.  And, for my part, I’ve been thinking about how to get there, and not just for the purpose of my book.

A bit under 2 years ago, I realized that I’d completely burned out on salaried, exempt (i.e. full time) employment.  At the core of this was the feeling that exclusive employment cedes entirely too much control over one’s circumstances to another entity.  On a long enough timeline, you’ll find yourself in a situation you don’t like, doing things that you think are stupid, and hoping for reprieve before you have to make the life-disrupting decision to go job hunting on the sly.

OppenheimerShady

So, I followed the advice that brings you continuous integration: if it hurts, do it more and more, until it’s painless.  I decided that, whether it be with employers, clients, or anything else, I’d never be completely able to prevent a situation from going sideways.  But what I can control is how easy it is for me to hit the eject button when it does.  And having a bunch of different clients and a whole ton of connections makes any single depression of the eject button relatively painless for me.  I was done putting all of my eggs in one basket.

That’s gone quite well.  These days I have more offers for work than I can take on, and a lot of different connections, contacts, and clients.  Life is good.  Maintaining my own pipeline is not without its drawbacks.  When you’re taking a break from your 9 to 5 gig on weekends, you might well find me invoicing or following up on prospective contracts.  But, I wouldn’t trade the relative freedom when it comes to controlling my working destiny.  I work more hours than most, but none of those hours are spent doing things that I think are stupid, at the behest of some megalomaniacal expert beginner.  And that has made all the difference. Read More

Oct
13

By

Scrum Master + Team Lead = Team Master?

Category: You Asked For It Tags: , , | 18 Comments

Last week, I gave the Scrum Guide a fresh read.  I did this for the simple purpose of making sure I was remembering the rules of the game correctly, and not just having conversations based on echoes of memories.  It turns out that my understanding and recollection had not drifted very far, which was good news.  But it also turns out that I still think of “Scrum Master” as somewhat silly.  I re-read the manifesto, had the same impression, and was somewhat gratified to learn that I have the same taste as myself.

What is a Scrum Master, Anyway?

There’s a lot to like in the Scrum guide, but Scrum Master, in my opinion, just isn’t in that bucket.  At best, it’s a built in sales role for Scrum, and one that should become unnecessary as time passes.  The guide itself is pretty unambiguous about this: “the Scrum Master is responsible for ensuring Scrum is understood and enacted.”  Presumably, once Scrum is “understood and enacted,” the role need not exist.  At its worst, “Scrum Master” is an escape hatch for non-technical project managers in an agile world that largely proclaims them unnecessary (unless re-cast as BAs, product owners, or line managers).

InterruptionCop

Unfortunately, and in far too many organizations, I think that Scrum Master winds up at its worst.  Scrum falls under the umbrella of agile methodologies, and it says something right there in the agile manifesto (or, at least, the principles behind it) about how to organize teams: “the best architectures, requirements, and designs emerge from self-organizing teams.”  This describes a scenario in which empowered and engaged technical folks figure out how to deliver value to interested stakeholders without relying on traditional command and control structures.

In other words, agile teams (and, by extension, Scrum teams) don’t need managers or masters.  They need a “product owner” to represent the interests of the business and… well, that’s it.  They need someone to explain to them what’s needed out of the software and then it’s up to them to go do it.  It’s refreshingly grass-roots.

Read More

« Older Posts
Newer Posts »