iPhone Developers are not arrogant and stupid :) Gears has been “dead” for a long time, it’s OK, but a shame
Nov 28

How to hire; Why don’t we date, get engaged, and only then get married to a job

Tech with tags: Add comments


Aaron gave a humane look at how to hire a programmer. It was less about programmers than it was about hiring, and how to judge people. Some have jumped on how this doesn’t scale to BigCorps, and others don’t think it tests the programming side of things at all.

First, the scaling. If you take a look at how big companies recruit their often have legions of sourcers scouring linkedin and the Web, and recruiters on top of them. The law of averages has them weeding out people based on some kind of “bar” which is inperfect but they feel like they need something. Of course, the main problem is that there is a huge amount of nuance in judging someone from their resume. If you can get past the fact that a resume can only tell some part of the tale, you also know that you, the seasoned programmer, can instantly make some kind of judgement on one. “Erm, this guy lists XHTML, HTML, SGML wtf?” Many sourcers will not be able to tell the crap from the truffle. Once you get these people through there are phone screens and the like, and then in person interviews, and suddenly engineers are spending a lot of time in the process. Rather than having them ask how many eggs fit in a mini, maybe there is something more productive.

This directly relates to school exams. We all know the kid that always did well in tests. And we all know the kid that was incredibly bright but never seemed to do as well as he should. Exams and tests are pretty crap depending on what you are going to Be When You Grow Up. If you are a flight traffic control chap, then the fast on the spot thinking will help. If you are an artist? Maybe not.

I am far more interested in seeing a portfolio of education than an exam grade. When Sam and Josh are older I want to talk to them about what they learned, and what they have produced…. not their score out of 10.

I think the same goes for programming. Show me what you have done and let’s talk about it. It is important to understand the scope of that persons role on the project, who they worked with, how long it took, and many other factors, but this can come across with conversation.

Another part of showing me what you have done is doing it with you. The best interviews I have done have been where you get some code out and you hack on it together. This is after all how things will be like in the team, so let’s practice what you will actually be doing. It isn’t about getting every line of code right, or getting the correct big O notation answer to a question.

Ideally of course you would be able to do much more than a quick hack session before you pull the trigger on a hire, and vice versa. So wait, aren’t we just doing this entirely wrong!

Doesn’t it feel like we are jumping into bed before we have rounded the other bases? What I really hope for is that we change the way employment happens. Imagine a world like this:

  • A company has need for someone to come hack on a project
  • A person has the interest and potentially has the skills
  • Person and company come together and start working on the project
  • Over time if things are going well, the person and company do more projects together
  • Much later, if the companies want to make a joint commitment to each other, the person weds the company

If only we had the tools to do this. Oh wait, we do! We can contract/consult right now. There is no rush to bed at all. The only issues seem to be social and perception.

People often want to jump into bed with a company as they want security (which includes items like healthcare in the US which is INSANELY tied to companies, but that is another matter) and upside (e.g. “get me in now so I can get stock and kick off vesting!”).

Companies often want to jump into bed with a person as they want to “lock them in”. There are many legitimate reasons here such as investing in people, getting domain knowledge (including secret knowledge!), and the like.

Some companies and cultures have the notion of “probation”, but that seems rare and feels much different: “company: Just in case you suck I have an easy way out!” vs. “let’s both check each other out and see how this progresses”.

I have some consultants on my team now who are great. I hope it progresses. I wish that culturally it becomes more common to go this route. It is socially acceptable for permanent bed hoppers (consultants) even if they often have a stigma.

Oh, and with Employment 2.0 we will have micro-employment too. Oh wait, we already do.

Insert Google Anecdote

People love to talk about Google hiring. This is one of my favourite anecdotes. It is hard to get into Google (rightly so!) and you get rated out of 4. When you go through “perf” (the review cycle) you also get rated. I remember being in a meeting where someone ran the numbers to see how the hiring ranking matches the end of first year (and beyond) ranking. There was no correlation at all. The higher the hiring rating didn’t mean anything for 1 year performance.

Insert Hiring Anecdote

We are hiring at Palm. My team is looking for developer advocates and the like, and the company is looking for a whole slew of great people, especially engineers!

  • Think the native apps on webOS are cool? They are just HTML/JS/CSS. Help us make more!
  • Think that a Web based device platform could be better? Help us on the framework or beyond!
  • Low level Linux hacker? Got spots there too. Bring it on!

3 Responses to “How to hire; Why don’t we date, get engaged, and only then get married to a job”

  1. Fabian Says:

    Hey Dion,
    you are correct. I really like those interviews where detailed questions are asked. However I have almost never seen any live hacking.
    And I think the reason for this is that you are searching a rockstar. Thats valid, but there is a reality, I also have not seen a few years back: There are very few rockstars available on the market.
    So you normally deal with the average developers, or even juniors. And you will not hire them after live coding, because they are not the level you want them to be. As an employer who is in need of people to staff projects you have to take a variety of people and invest into them.
    I think that pays off for most of them.
    Oh and for the rockstars: There are better ways to acquire them than the standard hiring, aren’t there?

    PS: I have been in the Google recruiting process and got a question wrong (palindrome calculation – now I know better :-)) . I am not sure if I am on their blacklist forwever :-)

  2. Lloyd Hilaiel Says:

    Thanks for writing this Dion, I’ve long believed in dating without ever putting it into such concise terms.

    I agree the need for “security” on both sides, and fear prevent the world from working this way. It’s always an “At Will Employment” but the process is such a PITA for both parties that… Well, divorce sucks.

    In addition to Employment 2.0 (what an interesting world that is), open source and open communities around the development of products is another way that you can create an environment where a comfortable type of dating is possible. If you hang out in our IRC room, contribute a patch or two, and work with us on some extensions or fixes…

    whoops! we’ve just dated, hey you were pretty good! Where’d you learn that trick with postincrement? looking for a job?

    another argument for open source where appropriate and possible I guess…


  3. Ashley K. Edwards Says:


    Interesting insight.

    Can you, by chance, e-mail me directly? Would like to send some info your way, that I think you’ll be interested in.



Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: What is the number before 3? (just put in the digit)