techno.blog("Dion")

Ben and I were chatting about interviews after hearing some horror stories from a friend. He made a jape about how bizarre technical interviews can be, and how we often ignore some really important factors… like a portfolio. A portfolio in this case answers the question of “what exactly have you created?”

I will pick on Google as it is the brunt of the “holy crazy interviews batman” trade, which is made more fun now that my sister-in-law is a recruiter there. I like to tease her. She knows that I am a fan of Google and think it is a fantastic place to work. I would be honored to work there again one day for example. Anyway, she doesn’t need my help in hiring… you have all heard about the food ;)

So, feel free to substitute Google for other high tech companies in any story below.

Imagine if Google interviews painters or artists in the same way that they hired engineers. Michaelangelo would show up, and would be hammered on questions about how he exactly makes and mixes his paints. Why does he use that particular kind? Why do those mixes chemically end up with the result that he desires. “If you were on a dessert island with 3 paints, what would they be and why?”, “Discuss the difference between RGB and CYMK”.

This may feel strange. A natural first step when you talk to an artist to see if they are any good is…. see what they have done! “Can I take a look at some of your pieces?” The artist will then probably show a variety that show a broad range of abilities. Some of you have probably had this experience hiring a wedding photographer.

Now, it isn’t that the process doesn’t matter. You want to chat about that side of things too. The right paint may result in a longer lasting piece. The right technique may result in you not getting annoyed by the photographer at your wedding. But, it is probably secondary to seeing what the person has actually done.

Google of course does a fair amount with art. The Doodles for example…. they have competitions for those, and the tools used may or may not play a factor.

Now, you may argue that the portfolio focus makes much more sense for art than other genres, including programming. You can tell a lot from seeing that art, and it is pretty static in time. Programming though, has to be maintained. It has to live. The “how” matters so much more. Maybe it is more like architecture than art. An architect can be known for his amazing looks, or building experiences, but the building better be structurally sound. You would still look at the portfolio of an architect first though, versus peppering them on structural engineering questions.

You do need to test the portfolio. It is one thing seeing that Bob Harris created an amazing website, a top 10 iPhone app, and contributed to a popular open source project…. but what exactly was the contribution. Projects have many folks involved. This is why you need to test the interviewee. Write some code with them. Talk through a real problem that they would actually have to solve on the job (shock horror). Do you *really* think that they will be implementing bubble sort on the job?

Interviewing itself is an art. It is hard to quickly make a decision on if someone will be a fit. Not only does there have to be a technical match in expectations, but there is the social match that is oh so important when a person joins a collective :) I have already talked about how the current process of hiring is like a shotgun marriage and broken but I definitely feel that in a constrained world there are three things that I favour when interviewing a candidate:

• Understand their portfolio (ask the candidate to come ready)
• Test the candidate to make sure they match with their portfolio (work with them on what they will be doing. E.g. pair on code)
• Talk to key people who know the candidate and learn from them about the person

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!