Matthew R. Bisson

Great Recruiters, Unite!

The following transmission is directed toward the (job) recruiting community everywhere. It’s time to get together and improve the way employees and employers connect with each other. The current method of matching software engineering candidates with software engineering jobs is completely broken. With so many good people out there looking for work, and so many good companies out there looking for good people, you’d think this would be no problem — especially in an age of so much technology centered around communication. If you have landed here, that’s a good start. Well, here is what I think are some of the roadblocks in this fundamentally flawed process.

A résumé is a horrible method of weeding out unqualified candidates.

There are simply too many things to know about a person that cannot be conveyed by a résumé. That people read in to a résumé as much as they do is, simply put, crazy. Don’t get me wrong — résumés can be very useful for determining what someone knows, how experienced they are, what kind of companies they have worked for in the past, or how adaptable they are to a changing technological landscape.

Recruiters do not typically use résumés like this, however. The classic mistake here for employers is to give your recruiter a list of technological skills that you require to fill the given position. This will lead some recruiters to simply scan for words in candidates’ résumés, and match them against the skills that they have been given for the position. Don’t do this. To me, it seems ridiculous to look for a candidate (for example) to fill a position called “Senior Network Engineer” and discard them because they have not used Objective-C. Experience is experience, knowledge of networking is knowledge of networking. Unless you’re looking for someone to write an Objective-C compiler, I personally don’t believe this should even be a factor in considering them from the recruiter’s perspective.

Programming language, OS’es, and software used in the past is meaningless for finding a good software developer.

As someone who has been on the hiring end of the process, I almost always ignore what technologies the candidate has used in previous positions as a means of ruling out that candidate. Ask yourself, do you want a smart, adaptable employee working with you, or do you want a candidate who already knows the specific technologies involved and can start right away? Any engineer worth your time should be able to pick up any programming language. They should be able to start working in a new language in weeks. Think about this. Weeks are a very negligible amount of time in the timeline of the hiring process.

I can’t tell you how many times I’ve personally been told that I don’t know technology “x” by an employer, and that is the reason that I’ve been passed over — many times without even being spoken to in person — only to learn technology “x” in my next job, and use it very successfully. A successful candidate can do anything put before them; an unsuccessful one can only do what they already know. Example: as a recent college graduate, I interviewed at a startup (actually a company with two employees). I came to learn that they thought that their SQL queries were too difficult for someone to learn as a first foray into SQL. At the job that I ultimately took, I started off doing mobile development in C++, but after they decided to change the direction of the company, I adapted. In about a month’s time, I was doing Oracle DBA work, designing data models for the database, and writing large queries and stored procedures in PL/SQL.

Nobody is doing anybody any favors.

There are few things more insulting in the interview process than when one party thinks that they are doing the other party a favor by even speaking to them. All good candidates recognize this; all good employers recognize this. Some employers take on an air of superiority when they speak to you. They’ve perused your résumé and have decided that you at least have enough of the skills that they need, but when they speak to you, you get the feeling that you’re somehow being belittled. This rarely happens with a face-to-face interview, but occasionally happens on the initial phone screen. In my experience this is because the person conducting the interview isn’t really confident with the topics about which they’re speaking, so they’re attempting to make you feel like they are speaking at such a high level that you must not even understand what they’re talking about if you challenge them (see [1], sec. 3).

To me, this is a major warning sign about the company. If a company treats interview candidates like this, then they will probably end up driving away many of the better developers. Nobody likes to feel belittled. This is a company that will have trouble hiring quality people, and it is not a company where you will want to work — unless you’re looking to be a big fish in a small pond. Don’t fall into that trap; work somewhere where you can learn something new and be challenged.

The same rules apply to candidates of course. People should be proud of the company that they’ve worked to grow, and it’s offensive to approach them with disrespect. Maybe you’re better than the job, but not the company or its people.

My life’s story (or, something you can only tell by actually speaking to me).

To drive the point home, I’m going to tell you about how absolutely fantastic I am — something you could never find out by perusing (or ignoring, as the case may be) the “Technical Skills” section of my résumé. First and foremost, there are two things that have never happened in my professional career. First, I’ve never gotten anything but a glowing, superlative review of the way in which I perform my job. Second, I’ve never happened to get any of those positions by submitting a résumé to a recruiter within my current company, to a “job cart,” or through a career site like (Regarding the last two, it just seems wrong to me to waste all the time formatting my résumé, only have it converted to text and submitted in an HTML form.)

My first job out of college was the toughest to get by far. I graduated when the internet “bubble” had just burst. With few connections, and every job posting looking for someone with a minimum of 10 years of experience in some small niche skill-set, I ended up being unemployed for almost a full year. I probably sent out about 1,000 unsolicited resumes (even going through the Yellow Pages to find software companies), I got exactly 2 job interviews… I guess the point I’m trying to make here is that the job market was bad — really bad.

My mother happened to find out that someone she worked with about 20 years earlier was the VP of engineering at a small start-up, and contacted him on my behalf. I went in to talk to some people, and decided that I liked the company. Unfortunately, they didn’t actually have any positions open at the company. After a few weeks of checking back and bothering people at the company to see if there were any openings, I came up with (what I thought was) a brilliant idea. I would offer my services free of charge for a month. Worst case, I learn some new technologies, get let go, and it doesn’t cost them anything. How could they say no? They didn’t. After only a week, they said, “we don’t want you to find a job somewhere else,” and offered me a position. I had a great experience working there on anything from simple content transformation to hand-held device application and synchronization to Oracle DBA work.

After a little more than two years, the company was starting to go under, and I knew I needed to start looking for a new job again. Someone I worked with at the company for only a short time contacted me out of nowhere from Palm. I went through the whole process — a phone screen, two 4-hour interviews, and a final talk with the director at that time. I later came to find out that they were on the fence about me until they talked to that person I worked with (and they respected very much) and apparently I made such an impression that he basically put himself on the line for me. “He’s good… hire him.”

When they first hired me, they had some pretty modest expectations for me, but in my first week on the job, the architect (my manager) went on his sabbatical — for four weeks. They were going to hire a much more experience developer to take on a project to port and expand an existing framework that was in place under the Treo’s email application. This would basically bring the email application into the Linux world for their next big project at the time. I just plain did that job and took over the framework (with guidance from that architect when he came back of course).

Two years later, the office closed its doors so Palm could consolidate all their developers to the main office in California. I had no interest in moving across the country, so I took my severance and took the summer off. Using a recruiter that got some of my former co-workers jobs, and armed with glowing recommendations (including one from the director of the Palm office, and one from my manager), I got a job working at a start-up with some of the smartest people I’ve ever worked with. After only a year, though, they were bought out and the office was moved out of the city.

At that exact time, though, Research In Motion met with the director of my former office at Palm and a few of the managers with the intention of basically having him create a new office. This director thought so highly of me that I was the first new hire for this office (after him and one of the managers). The rest, as they say, is history. I guess if you’re looking for a moral to this story, that moral is that you have to use your own personal connections to find candidates, and that you must actually speak to people before deciding that they can’t do a job (after you’ve decided that they have the experience you’re looking for of course).

Further Reading

  1. Corcodilos, 7 Mistakes Internal Recruiters Make.
  2. Corcodilos, Respecting The Candidate – Instructions For Employers.

Enjoy a printable version here!

Leave a Reply

Your email address will not be published. Required fields are marked *