As I’ve hinted at once or twice, I’m recycling some answers I have written on Quora and updating them for my current line of thinking. But this is also dual-purpose, in the blog’s mission of making sure that I don’t answer someone’s question somewhere that won’t help my readers.

A casually dressed man being interviewed

This post is based on Why are good software engineers so hard to find?, which I originally answered on Sunday, May 18th, 2014. Obviously, it has been edited substantially to better fit the tone, format, and time of Entropy Arbitrage, in this case also combined with more recent discussion that I’ve had on how to coax prospective employees into taking job offers.

I’m writing this both because multiple hiring managers have asked me questions like this, and because I would like to spark the idea that everybody should have a list of questions like this, issues that are important to them, and use every good and bad job experience to refine that list.

Teasing out the Real Question

I don’t like to call myself “good” at things—as the original Quora question implies—if only because that invites people to try to prove the assertion wrong. Plus, I’ve had similar discussions many times, so I’d like to generalize the question from Quora to something closer to companies looking to hire someone who happens to be similar to your (occasionally) humble author.

If you’ll pardon the brief digression about hiring the actual me, rather than a hypothetical me-like candidate, I do sometimes make myself available for interesting projects. About the only task that I’ll reject outright—of the things that people would likely identify me as doing professionally, I mean—is copyright searches, because that is always going to be better handled by a lawyer who can easily visit the Library of Congress to look at the paper records. Other than that, the worst I can do with requests made through my company’s request form or otherwise is to say no and try to find a colleague who might be better suited. Unless it’s spam, like most of the rest of the messages, there, in which case it just gets ignored.

That is, I’m not writing this post to get hired. But if someone reads this and wants to hire me because of it, that’s certainly not the worst outcome. Even better if someone already looking to hire me reads this and improves something.

That out of the way, if you’re looking to hire someone like me—possibly the actual me, possibly just someone with a similar background and temperament—these are the issues that I recommend watching out for. I feel like this is fair, because there are few publications that one can read where one can go for more than a month without an article from a recruiter or hiring manager listing all the hoops that they require of candidates before hiring them. If they can regularly publish articles claiming that they’ll only hire you if you memorize the LinkedIn profiles of everyone who works at the company and can quote from the specifications to the tools they use, then surely I’m justified in explaining what that looks like from the other side of the interviewing table.

The Old Ways

It occurs to me that technical recruiting has changed significantly in the last few years, in no small part thanks to Stack Overflow’s Jobs section. Not too long ago, a job posting might have looked a lot like this.

Anonymous company requires 10+ years expert experience in X, Y, and Z.  Must be a US citizen with a driver’s license. Travel may be required. Send résumé and salary requirements ASAP.

Here are the central problems with that style:

  • The list that might approximate the technologies used on the job suggests that you won’t hire someone who has used many comparable technologies and can learn yours quickly, and would rather just find someone who worked with exactly that set, no more and no less.
  • There’s no indication of what the job might be about, other than the technologies you probably use.  Is it in finance?  Engineering?  Retail?  Science?  Some fields are more interesting than others to different people, and many have special requirements.
  • Then there’s the two-way mirror of contact.  You want to know everything about me without indicating anything about you, and you’re suggesting that you want information to disqualify me.  You claim to want quality people, but you want the upper-hand at every turn, which comes off as childish rather than professional.
  • Because I’ll talk about inclusivity more in a bit, it’s also worth pointing out that the non-technical requirements are almost never what the company thinks they’re looking for, and so instead comes off as bigoted. They don’t want citizenship, for example; they probably want someone who can get a security clearance. They probably don’t actually need someone with a driver’s license, either.

Some companies think they’re going to go one better.  They’re going to try to be excited about the job.  They’ll post exactly the same description, but add something like, superhero programmers only.

Oh.  Well, that changes everything.  What I really want to do is spend my day in an office of people who give themselves made-up titles like I did in elementary school.  Plus, maybe they’ll also hire cowboy, astronaut, and zookeeper programmers, some day.  And obviously, anybody who would describe themselves as a superhero/ninja/rockstar/elite/whatever is on the up-and-up, right…?  Totally not some jerk who’s full of himself?

In fact, I’ll go further and point everybody to Kat Matfield’s Gender Decoder tool that—based on existing research showing that many people, primarily women, turn away from job postings that seem obsessed with maintaining a macho image—flags subtle biases in job postings.

This style of job posting is related to the recruiter e-mail that generally goes something like this.

We have such a great opportunity that you seem perfectly suited for! Please respond with résumé and hourly rate. Must relocate to North Shambhala. Four to six week term. Ten years expertise in Whitespace required.

I’m always somehow perfectly suited for a job with technologies that I’ve never used, in a town nowhere near where I or anybody else lives, for a short enough term that becoming useful in the technologies would be prohibitively difficult, and on short enough notice that housing would be expensive, as judged by someone who doesn’t have my résumé. Presumably, everybody else in the recruiter’s database is, too. It’s a bold approach to recruiting, if nothing else.

I haven’t seen much of either style, recently. Again, I credit that change to the new breed of job sites that actively discourage companies from being vague.

Get to the Point

Even though the job postings have improved, they’re still often uselessly vague, leading to unnecessary exclusion. For an example in my own work history, a few of my “15+ years experience” with C# might as well have been the same year of experience, for all I learned during that time. But because I’m older, I’d have a better chance of applying for a job than a much younger colleague who may have spent a summer volunteering to fix bugs alongside Microsoft employees in the libraries that the job will use.

Because of issues along these lines, what I really want to know from the start is something like the following.

I need to know that I’ll learn something interesting on the job.  It may not be related to software technologies, and it probably isn’t, in many cases.  Personally, I’ve taken really boring jobs because the majority of the company worked in an entirely new field to me.  Meanwhile, I can’t really afford to take full-time jobs that require my career to stagnate by just fixing bugs in yet another e-commerce system. I don’t mind solving the same kinds of problems if I see how a new kind of business is run. I don’t mind staying in the same role in the same industry, if there are new problems to solve. But solving the same problems in the same roles is a dead end.

The company or team must have a real problem that I can help with.  If the team does just want someone to make routine fixes to an e-commerce site, they should really hire a kid out of school at a fraction of my salary, instead.  I’m not going to do anything that candidate wouldn’t, and someone with less experience will learn more from of the work. If they’re hiring someone because they have the budget for it and hope that new work comes in, they’d be better off putting existing employees on more experimental jobs.

The company should plan to treat me like a peer, rather than hired help.  I may be reluctant to call myself an “expert,” but I’m good enough to know that teams should be hiring employees for their judgment, rather than just their ability to work to exhaustion following orders, and that the latter would be a waste of their money.  A good sign that they’re just looking for a minion is when the interview is a bunch of what amounts to trivia questions—such as, “what API call is used for XYZ purpose?”—that could be answered faster by searching the web.

The team shouldn’t be dysfunctional.  When I’m interviewing, when they ask if I have questions, many of my questions are about relationships.  I want to make sure that everybody’s voice is heard when there’s a decision to be made, and that everybody’s experience is respected. This has only become more important over the years, as software developers have become a more diverse group and many of us still need to unlearn biases that tell us that some voices can be ignored.

These have something in common that might not be immediately obvious. While it looks like some are about furthering my career or about making sure that the company isn’t absurdly toxic, they’re actually conditions making it possible for me to help. If there’s no reason for me to stay, or if the role is to shut up and just do what someone else says, then there’s no way that I can contribute enough to the company to justify my pay.

Also, regarding interviews or other pitches, I don’t care about the cutting-edge gaming consoles that the company might have in the basement for after-hours violence, the free snacks or artisanal beers in the pantry, the regular happy hours (what is it with companies hanging their culture on alcohol?), the laundry service, or—honestly—even the bonuses and maybe the health care plan.  I want to know that the job is worth physically or virtually coming in for on its own terms.  The things that they might be trying to use to trick me into accepting the offer only make me suspicious.

The Questions

With all that, here are the sorts of questions I think about for any job, in no particular order. Note that I’m throwing in my judgments, here and there. Other times, I mention prior experiences that I’ve had. These aren’t recommendations, because not every position needs to be revised to fit me. But they are issues that certain kinds of candidates are going to find important.

I don’t actually ask most of those questions, to be fair. Most are usually obvious within a few minutes of speaking to a prospective colleague or a hiring manager. But the answers still paint a more useful picture of a job than something like the “Joel Test” or other list of technology-based questions. When interviewing candidates, I have occasionally been asked about the computers that employees use, and I’ve never understood how that information is useful.

Value of Time

Probably the most obvious thing that I need to know is how I should expect my time to be valued. That is, I know how much I value my time. If the company is going to put a significantly lower value on my time than I do, then I’m not being fairly compensated.

  • As mentioned, but now in more detail, what’s the compensation and what is the compensation for? The company is going to expect me to offer a salary expectation and probably an implied promise to work overtime, so it’s hard to trust a company that’s going to play information asymmetry games. And a prospective employee can’t estimate the return on investment, if the investment and return are a mystery.
    • If people are expected to work sixty-hour weeks—whether that’s scheduling work based on the assumption of long weeks or just informally judging people’s commitment by how long they spend at their desks—that reduces the pay rate.
    • As a variation on this, if I receive a salary, but my work is valued at an hourly rate, the employee’s goals will inevitably run directly counter to management’s—any manager is going to want to maximize “inventory” at the lowest cost, and the easiest way to do that is to convince salaried employees to work overtime—and that changes the calculation further.
  • Along similar lines, how are schedules and deadlines crafted? You might guess that I think a lot about schedules, given that I wrote an entire post on getting project estimates right. In my experience, schedules are the easiest way to measure how well the project is run.
    • Schedules that were written to encourage certain behavior (assigning extra work to test an employee’s commitment) or model prior behavior (assigning less work, because a member of the team was sick last time) are signs that nobody knows what they’re doing.
    • Deadlines set without regard to the amount of work involved—with some limited exceptions, like needing to present something at a real-world trade conference—or that are too flexible to bother thinking about are signs that nobody has a real plan.

There was a time that I’d come out and just ask “what does a typical day look like on this team?” I knew the job would be bad whenever the manager would get uncomfortable and suggest that every day is different, because they either don’t know what their team does or people get interrupted so frequently that they’re constantly working extra hours to deal with things.

One word of warning, here, if you’re a job-seeker planning on using these questions. If anybody talks about how flexible their schedule is, press everybody for details. There are many kinds of flexibility. Some companies basically operate from nine in the morning to five in the evening, but if you need to occasionally vanish for an afternoon, nobody cares, as long as it doesn’t disrupt anybody else’s schedule. Other companies will claim to be flexible, but they mostly mean that you can work some of your eight hours per day late at night or on weekends, but will still nickel-and-dime your attendance.

Requirements and Onboarding

These questions relate to longer-term value. I’m looking for investments that the company makes in employees and how that investment gets repaid.

  • Increasingly, it’s important to know what agreements are employees expected to sign. NDAs with no expiration, claims to anything that I create while employed, and no-compete clauses are red flags that should at least have a satisfying justification. And by the same token, I have a lot in my life that I’m not willing to sign over for a paycheck, on the slim chance that the prospective employer might find CPREP or a new edition of Seeking Refuge valuable in the future.
  • What resources are available for new hires to get their local development environment ready and learn the basics of the project?
  • What’s the ideal vision of the job at the end of the first day, week, month, and quarter? What does the team plan to do to maximize the chances of those things happening? My experience has been that anybody who can’t give a project-based answer to the first two—“you probably won’t know the system after a week” is far too common—is just looking to put a butt in a seat and hopes that work will show up.
  • How are employees evaluated? How objective/reproducible are those criteria?

I have only had one job where onboarding was reasonable. They sent me to a half-day course about the product line I would be writing software for, handed me a pile of equipment, and told me where to download the libraries that I would need.

By contrast, the dumbest job that I’ve had—the company is no longer in business, so while I have no trouble making fun of them in public, the specifics would also be meaningless to readers—started my first day by complaining that I was late…because nobody told me that they started work before nine. Then, they left me in a conference room for the morning because my desk wasn’t ready…so what difference did my arrival time make? Late in the afternoon, they gave up on finding a desk for me and enrolled me in a week-long course that had nothing to do with my job; it just happened to be the class that started that day and had an open seat. By Friday, they had my desk, but that’s all they had, an empty cubicle with an Ethernet cord hanging over the wall. It took another few business days before I was able to send e-mail to request access to source code and the like.

If you want to hear more about these clowns, I’ll mention them again, a bit later.

Culture Fit

I fit into most cultures that aren’t toxic, I think. Yet there are many ways for a culture to be toxic.

  • Is the “company culture” descriptive or prescriptive? How is it managed? If the culture is important, but management doesn’t know where it comes from or how it’s enforced, then they’re almost certainly just trying to hire people who remind them of people they work with, which can have its good points and its bad points, depending on the managers and who they are. Similarly, whether the culture is imposed by management or just what has evolved from putting people together influences what “fitting in” means.
  • Who audits the hiring process to make sure that it accomplishes its goals? If a manager ever tells me that “you can’t improve what you don’t measure,” but doesn’t measure and analyze everything about the team’s hiring process, then the team is broken.
  • How do non-programmer things get done? I generally don’t care about this, but sometimes it’s important to know if software needs to be requisitioned or if there are special privileges required to install software.
  • How much of the budget goes to “pure” research and development? Who makes what decisions, based on the results that are found?
  • How are meetings kept on track? I’ll be honest, here, that the only right answer is that the entire team is responsible for preparing for meetings ahead of time—reading the agenda and associated material—and then self-polices when anyone drifts off the topic. If anybody is ever surprised by something said at a meeting that isn’t explicitly for an announcement, or if the meeting runs long, then either the team or the planner hasn’t done their job and is wasting a lot of money.
  • Where and when do employees generally socialize? Everybody at the company knows the answer to this question, and the answers say a lot about the cohesiveness and the stress that the team is under.

At the aforementioned dumb job, I was given a new module to test. I won’t bore anybody with the details, but I needed, requisitioned, and received permission to use two servers in the server room for a few hours. They needed to be connected, since the server room (for whatever reason that I don’t remember) didn’t have the computers plugged into the common network. I walked in, saw that the machines were on opposite sides of the room, and envisioned my solution: I untwisted some paper clips, hung them from the frame of the ceiling, and used those improvised hooks to run an Ethernet cable across the room without getting in anybody else’s way.

By the time that I got back to my desk, I had a voicemail waiting from someone in the IT department, screaming that I had no right to plug the machines in. That was their job and I had to wait for them to take care of it.

Fast-forward past my actual testing, I presented my findings, which were that, at least for our use case, we should expect almost every use to fail, which it turned out was backed up by the manual, which they had only just given me. They waited to hear my analysis, listened again when they misinterpreted me, and then said “well, we already signed the contract, so I guess we’ll need to ship this broken and figure something else out later.”

I came back to my desk from that meeting to a voicemail from a recruiter, as it happens, so I wasn’t there much longer.

At a different unpleasant job, most socialization happened at happy hour after work. If people need to “log extra hours” to get to know each other and regularly need alcohol after working, I’m confident in saying that it’s probably not a great sign. By contrast, at a different (far better job), people regularly e-mailed each other (back before chat programs were normalized) with interesting things, dropped by each other’s offices, and went out to lunch in big groups.

Stability

Stability is more important to different people, but it has to be at least a small factor in most decisions, if only because nobody enjoys looking for a new job.

  • How is the company financed? Who’s tasked with growing revenue? How does that person interact with the workers? How would the interviewers describe them?
  • What’s the company’s goal or plan? I usually see three answers: Becoming/staying profitable, paying for something else, and getting acquired. Each of those comes with different expectations.
  • What does the company/project actually do? Not only do I want to know that the company does something that’s in sufficient demand that it won’t go bankrupt soon, but we also increasingly live in a world where side-projects make the company look bad. I’d rather not have a holiday dinner where I tell everybody that I’m working for Shopway and suddenly learn that another division has been working hard to industrialize murdering kittens, or anything that I would just as soon not be involved with.
  • How does the team (or job, if there aren’t teams) contribute to the bottom line? That connection makes a difference to job security when revenue drops, and makes a difference in the long term when talking about any raises. As I discussed a couple of weeks ago, that knowledge is important.
  • What is the company currently changing? How are those tasks progressing and by what metrics? These days, it’s common for companies to get excited about their new Diversity and Inclusion initiatives, for example, but not have anybody who knows anything about the program. Running with that example, if there is one person who knows about the program and that person happens to be a member of an underrepresented minority, just leave. A company should never have any program that’s only staffed by people who would have benefited from that program and given no resources beyond their slack time.
  • How often do managers write code, especially on projects with people that they manage? Some people see it as a benefit to have technically oriented management, others see it as a problem with office politics.

I assume that all of these are self-explanatory, except for the last, since the rest all amount to some variation of “what are the odds that my desk will still exist in five years.”

For the last item, my personal experience at multiple companies has been that, when managers write code, they expect less oversight than the rest of the team (or just get less, because less-confident members won’t want a confrontation) and—because they have other responsibilities that can block people—frequently miss deadlines and need someone else to cover for them. Often, that coverage isn’t requested; the ticket just quietly gets reassigned to someone else. It doesn’t make the job unstable, but it makes the team unstable, as nobody on the team has the authority to hold the manager to account and has extra “help” that may actually be slowing everybody down.

The Lightning Round

There’s one question that I always make sure to ask in interviews, and I recommend it to anybody who’s worried about a number of issues, provided that the anticipated job is one that makes things. The question answers many questions at once and sometimes provokes answers that will be stories that you eventually tell your friends at parties or write about on your blog.

What can you tell me about my prospective counterparts in sales and marketing?

And then, do not interrupt, under any circumstances, no matter how much you might be inclined to follow up or change the subject. My favorite (condensed and sanitized) answers, for different reasons have included the following.

  • “I’ve never spoken to anybody from those departments. We just occasionally get notice that we need to change the products.”
  • “You’ll be working with X, who sits a few desks from you, and is great at their job. I think you’ll like them a lot.”
  • “They’re a bunch of overpaid idiots who don’t know anything about the product. They blow their hot air, sometimes, and we just ignore them.”
  • “We only have technical people, here.”

I took two of those jobs. One of those answers led to what’s probably the best job that I’ve had. Another led to a job that I didn’t mind at the time, but in retrospect shouldn’t have taken. One had me wondering if I should offer to take the hiring manager for a walk so that they could have their nervous breakdown in peace. I won’t bother to identify which is which, but you’ll notice that the answers reveal or overtly fail to reveal a lot about company culture and how the company values people’s time. And it seems so innocent, too.

And there you have it, pretty much everything a company might need to hire me or hire me away from another job, or at least someone like me.

Credits: The header image is Man Job Interview by “Linkedin” (possibly mis-attributed), made available under the terms of the Creative Commons CC0 1.0 Universal Public Domain Dedication.