More Than Coding

Because machines still need humans

Category Archives: Interviews

Hiring awesome software interns

What says “summer is here” more than the nice weather? It’s the flood of eager college kids who are keen to get hired for a few months to get some real commercial development experience.

The challenge for employers is in the interview process. Because the candidates are both young and inexperienced, it can be tough to gauge the skill level of somebody so “green”. Assuming they are being hired to actually write code, you should of course check their knowledge of fundamental algorithms and data structures. However that might not whittle down the list enough, so how can you figure out which of these fresh-faced kids are the best of the bunch?

Ask them two extra questions:

When did you start programming?

If they answer, “For my assignments in CS101″, put them at the bottom of the pile.

If they instead answer, “When I was 13, I started creating my own web pages and coding Javascript utilities to make them do more cool stuff, and I haven’t looked back since”, put them at top of the stack.

Do you write software in your spare time?

If they answer, “Yes, I just built this iPhone app to see if I could, and now I’m writing a Sudoko app for Android for fun”, well, you guessed it: top of the stack.

The answers to these simple questions tell you if the candidate chose to study computer science because it sounded like a good career choice, or if software was already their passion. And that can make the difference between a good internship and an awesome one.

The Programmer Pyramid

Newsflash: some programmers are better than others.

OK, I admit that’s hardly a revelation. But most companies use a grading structure that can obscure the relative strengths of each engineer on the team. There may be a 20-year veteran with the title Principal Engineer who regularly breaks tests and hacks his way through his day while a young intern may be writing some of the best code the team has ever seen.

I’ve built my own mental model of programmer strength and organized it as a pyramid:

Typist

At the lowest level of programming competence is the Typist. They hit the keyboard a lot but don’t produce anything that even remotely resembles professionally-written software. They are utterly lacking in their technical knowledge and have little desire to change that fact.

A software team cannot survive long with typists in their midst because they do more harm than good. They are at best anchors and at worst damaging to the momentum and morale of the other members.

Coder

This is the level that most programmers are at when they graduate from college. They have a good knowledge of data structures, algorithms and are proficient in at least one language. Due to their limited professional experience they typically don’t yet understand why they should make code maintainable or do refactoring (mostly because they haven’t yet had to fix someone else’s bugs).

Coders require investment from the stronger members of the team in terms of review and oversight, and if there are many of them on the team, that can weigh the others down.

Builder

A Builder is a Coder who has adapted to work in a professional environment. They create readable, well-organized code and always ensure that their tests pass.

Builders work best executing the designs of those above them in the pyramid. They write good tests, are self-motivated and have the word “solid” associated with them a lot. Most teams need at least some Builders to be productive, and most teams indeed already do have some of them on staff.

The majority of programmers reach this level during their careers, but not all of them will move upwards to Engineer.

Engineer

Ironically, almost all professional programmers have the word “engineer” in their job title, but many of them simply never live up to the name.

Engineers design scalable and reusable components, infuse others with their knowledge and are very disciplined. They keep abreast of industry trends and technologies but will only use the right tool for the job at hand rather than get distracted by the latest fun tool they played with.

Their code is impeccably written and very well-thought out, and they know exactly how it fits with the rest of the system. They are very good mentors and routinely assist others on the team. Every team should have at least one.

It’s not guaranteed that a Builder will eventually become an Engineer, because some of the traits required (creative design and problem solving, among others) are likely innate and can’t easily be learned.

Master

Masters are rare. These seasoned veterans produce software that is more than just engineered – it is crafted. Their software has aesthetic beauty. They are the Frank Lloyd Wrights of software and are worth every penny if you are lucky to find one on the market.

Whatever they create – be it a user interface, an API or a tool – is incredibly easy to use. It just never gets in the way because it just works, and works well.

Having a Master on your team quickly causes people at the lower levels of the pyramid to move upwards thanks to their positive influence. I was lucky enough to have one on the team that I joined after leaving college, and I’m forever grateful for the experience. The Master created a team culture that encouraged everyone to better themselves and to work like true professionals.

An unexpected attribute of a master is their humility. While there will always be plenty of alpha Engineers around, the Master is confident and secure in their knowledge and doesn’t need to brag or assert dominance. Their work speaks for itself.

Using The Pyramid

The pyramid is most useful at hiring time. Many employers think first in terms of the position they need to fill and then only consider the relative strengths of the candidates after they’ve interviewed them. I think that’s backwards. They end up completely discarding resumes without the “correct” number of years of experience. A better approach would be to think about the desired strength of candidate first and only worry about their grade when an offer is being prepared.

The pyramid helps prevent the kind of pointless discussions that begin with someone in management saying, “We must hire only top talent!”. That’s a fine goal, but you have to realize that you’re not going to find a team comprised only of Masters. You may need a few Coders to write an internal testing tool based on the design of some of the stronger members, and it would be silly to pay top-dollar for that work.

You may also look at your team and realize it’s staffed almost universally by Coders, and what it’s really missing is a strong Engineer to lead, mentor and inspire them to build better software and lead their growth up the pyramid levels.

When you are interviewing a programmer for a position, I’d suggest drawing the pyramid on the board, explaining what each level means and asking the candidate where they think they currently fit. You’d be surprised how much you can learn from their reply: some candidates shoot right for the top and proudly boast that they’re Masters while others take the time to really consider their own abilities and give an honest answer. I have even encountered candidates who, after hearing me explain the level of strength I’m looking for, candidly mention that they may not be right for the position.

And it’s so much better to find that out before they get hired.

A Fake Google Interview

Imagine an engineer being interviewed at Google:

“Have you seen our website?”

“Oh sure, I’ve been to goggles.com.”

“Do you know what we do here?”

“Something about searching, I think. You do some advertising too, right?”

That’s a ludicrous scenario only because Google is so well-known. Everyone interviewing there nowadays knows exactly what their website looks like and is aware that they are the world’s most popular search engine.

Sadly, the same conversation plays out every day in technical interviews around the world in companies smaller than El Goog. The candidate arrives armed with a smart suit but is lacking even a basic knowledge of the company’s products, goals or technology and the interviewer quickly realizes they are wasting their time.

You may think that’s harsh, but consider the candidate’s motivations. By not bothering to understand the company, they are implicitly declaring that they want a job purely to benefit them. They look at job descriptions for a few techie keywords that they recognize, and email across their resume. They don’t know — and don’t care — that their potential employer is looking for passionate people to become part of a team that will work together to build something revolutionary or make huge gains in the market. They’ll be a 9-to-5’er, doing exactly the minimum work required and no more. Unless the position is for mindless data-entry, the company is not going to benefit from having someone so self-serving on their payroll.

Therefore if a candidate hasn’t even bothered to look at what the company does before going there to ask for a job, they should be quickly shown the door. However if you’re like me and enjoy hearing dreadful answers to softball interview questions, you’ll always ask them one final thing before escorting them off the premises:

“So, why do you want to work here?”

Follow

Get every new post delivered to your Inbox.

Join 34 other followers

%d bloggers like this: