Universities are churning out CS graduates at record pace.This would make you think it has become easier to scale a development team. It has become much harder to separate the wheat from the chaff. Counterfeits and muppets abound in the software industry, and while a 10xer could make a startup, a muppet can just as easily break them.
Like the Bronze age and Iron age, the years since the 1990s at least until now and for the foreseeable future will be known by the main material around which we organize our societies: “software.”
Welcome to the Software Age
Software is now the material of construction, of leisure, and of war. The best-built, most comfortable and the strongest societies will now depend on the quantity and quality of their software.
This new machine of innovation needs meat for the grinder, more digital peasants to toil in the feudal fields of what has become the software industry.
But unlike the past ages, the kind of labor needed doesn’t require a strong back, or a strong mind, it needs a special kind of person. A New Scribe, a Ninja, a Unicorn, a Full Stack Developer. Someone capable of translating the needs of technocrats into the arcane language understood by the spirit in the machine.
These are not the unicorns you’re looking for…
It is a truth universally acknowledged, that a developer in possession of full stack knowledge has already been scooped up by your competitor. In 2006 Joel Spolsky wrote about the difficulty of finding great developers:
The great software developers, indeed, the best people in every field, are quite simply never on the market.
The average great software developer will apply for, total, maybe, four jobs in their entire career.
People who apply to developer jobs are rarely any good. If you want your unicorn, you are going to have to seduce them away from other companies and other localities.
One current innovation in hiring that has cropped up in the last few years is that of hiring remote developers. Hiring remotely allows you to cast a much wider net, and you’re more likely to pick up a talented, but location locked, developer in some remote area of the world.
If you read Joel’s article you’ll find some good advice for finding great developers. I am going to talk about what it is like being on the other side.
I am not a hiring manager, though I have performed technical interviews. I am a developer. I won’t be so arrogant to say that I am a great developer, but I am rarely on the market. In fifteen years of development, I have only sent out my resume once to a recruiter who found me a post at Orange writing code for their intranet.
I was, until recently, very happy with my position. But due to some contractual mishaps, I’ve decided I would like to move on from working for a French Company. I’ve learned my lesson, and would never again accept a post from a one.
Once I opened myself up on Linkedin as actively searching for a new post, I have received a deluge of interview requests, I completed 4 last week, and have 11 more scheduled over the next two weeks.
I want to talk to recruiters in general about what they do that is good, and what they do that is not good.
I can tell within 5 minutes if I like the company enough to continue with the interview, and usually, I find myself wanting to just hang up the phone, or close skype and never talk to this recruiter again.
The stupid things recruiters ask
Because I’m a massive tool, I hold the firm belief that if you ask a stupid question you should get a stupid answer. Hey, I’m working on it — so far the therapy is helping.
I find that an immense amount of my energy in a job interview is spent keeping myself from being snarky and rude. I feel like a spider on a diet during a mass wave of fly depression. They just keep walking right into idiocy.
I did mention I’m a tool right? Carl Jung once said “I’d rather be whole than good.”
Recruiters really don’t make it easy, here are some gems I hear in interviews that make me twitch.
Why do you want to work here?
When you ask this question you are being very silly. At the beginning, I used to stretch for a reason, but lately, I’ve begun tanking the interview by telling the truth. This is one of those questions you never need to ask because by the end of the interview it should be obvious I would want to work there by asking you questions.
My favorite response to a recruiter who asks this question is: “I don’t. You called me.”
The problem with this question is that it is often asked way too early in the conversation. We’ve barely gotten to know each other, I have literally no idea yet if I do want to work for your company.
The best way to find out if someone wants to work for you is if they take a second meeting.
Do you know what we do here?
I hate this question. I have a full-time job as a lead developer and I often double as technical lead and fireman on our more than 20 concurrent projects and 70 servers.
Yes, I read your website and company description as well as a description of the post, but no — I really have no idea what you do, or what you’re about.
You called me. Tell me what you do, and what you need.
How much do you make in your current position?
I have yet to find a good response to this one but it irks me. What you’re really asking is: “Tell me how much you make now so I can try to get you as cheaply as possible.”
I don’t want to anchor you to a number. How much I make now is relevant to the company and the job I work at — now. You aren’t the same company or the same job. This isn’t the industrial age where all jobs are more or less uniform. A manager of a textile factory is not that much different from a manager of a tin can factory.
Make your offer, we’ll talk about it. Sometimes I feel like acting like one of those snooty upscale boutiques. If you have to ask how much it costs, you can’t afford it.
For me, wages are relative to the area I am working in. I gauge my salary needs based on 3.5x the cost of a furnished apartment + utilities in the area I’ll be working. There are all kinds of balancing goodies that can make that better, such as diner’s checks, covering gym membership, a new development laptop, compensating travel expenses, health insurance, 401k matching, covering continuous learning and so on.
$200,000 a year sounds like a great salary, but not necessarily in San Francisco.
My current thinking is I want two things, the amount you intend to pay, and the address of the building I’ll be working in. I’ll look at the local cost of food and apartments and if it seems like you’re making a reasonable offer we can negotiate. If it’s insultingly low, I just won’t call you back.
Stupid things recruiters do
These are things recruiters consistently do that annoy me to no end.
Surprise technical interview!
Yay! Actually not. I’ve just spent the previous 11 hours coding in PHP and you want to spring a surprise C++ algorithm question on me. How quaint.
I work and have worked with a lot of technologies over the years. But I don’t keep that stuff in my head. No one could. I get contacted by all kinds of companies, and I am seriously interested in working with their tech, but I know at the end of the day I’m not going to be in anything remotely approaching top condition so springing a pop quiz on me is just mean. I won’t like you, and I probably won’t work for you no matter how well I do on the test (which is usually pretty well anyway.)
The right way to do a technical interview is to provide an outline of what is going to be discussed so that I can prepare. It takes the average developer something like 30 minutes to get their mind going on a particular technology, giving them some advance information ensures they can start preparing, and you will end up getting a more realistic example of their competence and workflow.
The reason often given is: “because equality.” This is so stupid as to beggar belief. It shows a fundamental lack of understanding tech and problem-solving (and equality). Not everyone is starting from an equal footing. Not everyone responds the same to time constraints. You are eliminating good developers based on a unidimensional criterion that has nothing whatsoever to do with their technical competence. That means you are stupid.
It’s not all bad
Sturgeon’s Law, abstracted to all things, tells us that 90% of everything is crap. 90% of recruiters are complete tools (but then so are 90% of developers — including me).
I think of the 20 or so recruiters I’ve talked to in the last couple of weeks, 3 stand out as having been amazing.
They asked great questions, they represented their companies with distinction, and they are the only 3 posts I’m seriously considering.
The following is what I feel they did right.
It’s a conversation, not an interview
The overwhelming majority of jobs or projects I’ve worked on in the past 15 years did not require an interview. Invariably I was recommended to the company by a former client or another developer I had worked with. I am not really used to doing “interviews.” I’m used to being somewhere where I am wanted, discussing the problems and goals that need to be met, and how we can work together.
This is usually conversational. It’s a kind of structureless exploration of both parties that is fun and engaging, revealing who both parties are at a deeper level.
One phone interview went over by one hour just geeking out about tech and discussing the nuances of language implementation and how it guides algorithmic choice when coming up with solutions, or strategies for refactoring monoliths into microservices.
Albeit in this instance, the recruiter was also in charge of the development team, and so we spoke a common language.
In one of the interviews, the recruiter was not technically inclined, so instead they focused on asking me questions about the technology that their client was looking for. This strategy was very good because they were able to see if I could discuss fluidly on the needs of the job, even if they were ultimately unable to decide if I actually knew what I was talking about. At the end of that interview I was scheduled to talk with the CTO, and we ended up geeking out on 2D side-scrollers in C using SDL and discussing the finer points of using AWS Lambda to implement serverless architectures.
In every instance, the focus of the “interview” was a conversation, with a basic understanding that if a developer has a general and broad understanding of different technologies, then they’ll probably be able to do the job.
In the third interview, although the person doing the interview was also a developer, we spent most of our time talking about developer culture, unit testing, and the barriers to innovation in large companies. We talked about more open and inclusive environments, the need for rigor in software engineering, and why company politics poisons creativity.
Take home projects
Each one of these interviews also had a small take-home project that was interesting and well thought out. I’m a big fan of the take-home project because it gives me the time to do it my way, to have some fun, and to solve a small challenge in my own time.
I really dislike timed tests, or quizzes, I don’t think they give accurate results. But a small project is just the thing to really see how someone thinks about a solution to a possibly real-world problem.
The best questions I’ve been asked
The following are some of my favorite questions to be asked, and why I think they are the best questions (and projects) to use to guage a developer.
Do you have a github account?
I do have one, with over 90 repositories in every language I’ve ever worked in. You can see all my code since 2008 (over 10 years) on my github account. Not just my best, but my weird experiments and half done projects.
Whenever a recruiter asks for my github, to me it’s a signal they are very keyed in. In fact, it’s really the single most important question you can ask, because everything else (even take-home projects) are superfluous. You can see my code already.
Do you have a stackoverflow account?
I do, with a user story, work history, and questions I’ve answered! While I’m not a stackoverflow guru, I do have a reputation of at least 1,000 on the site and am in the top 20% of answerers in PHP.
What editor do you use and why?
This is, I feel, the most important question you can ask a developer. Whenever I meet a new developer, I ask them this and their answer speaks volumes.
There are only four good answers to this question, and they are Vim, Emacs, Eclipse, and TextMate.
Anyone else is by definition a dilettante (there are a few exceptions, like QTCreator, or RAD Studio or 4Coder — or mandated environments like MSVS).
What’s your favorite language and why?
This is hands down one of the best questions you can ever ask a developer because it tells you precisely what stage of programming they are at in their career. The more they discuss the internals and implementation of their language of choice, the better you know they are.
The same is true of any craftsman. The moment he becomes interested in the quality and construction of his tools is the moment he moves from journeyman to master.
Being able to have a meta-discussion about programming is an essential stage in the development of a programmer.
To give you an example, I work with PHP programmers who don’t even know the name of the man who created PHP, nor do they know the history of PHP, or any details of its implementation. They’ve never read the source code or even looked at it. They’ve never tried to extend the language, nor can they weigh the pros-and-cons of different module implementations.
Most of the companies I am talking to now are as far away from PHP as I can possibly get.
PHP is to web programming what Java is to systems programming. A brain rotting experience.
Just to feel better about myself and cleanse my palette, I downloaded GHCI and started poking through “Learn you a Haskell for great good.”
I’m starting to feel like one of those cliché characters in a story who try to break out of the inner city into a better life, but keep getting drawn back by former gang cronies into a life of crime. If I never have to program PHP again, it’ll be too soon.