Monthly Archives: December 2012

Music To Code By, 2012

Here’s what I listened to while coding in 2012.

This year I’d categorize my listening habits into three moods: getting shit done, relaxing, and background noise.

Standard disclaimer: I listen to albums all the way through, front to back, and am often annoying the hell out of my wife with a single track or album on endless repeat, for an entire day. I like moody music, stuff that takes you places, stuff with meaning or at least the feeling of meaning. If that’s not your style, and you want pop hits – you can stop here.

Getting Shit Done

These are the albums that put me in the zone this year, some new releases, some new-to-me stuff. This is the good stuff to go heads down with, especially at volume 11 or 12 on a 10 point scale.

For many days I listened to This Will Destroy You’s albums and EP. This Will Destroy You is awe-inspring post rock, think sigur ros, with much more tension, and more precision. I’ve seen these guys twice in concert in the past year or so, and they always impress. When you listen to TWDY, you wander off somewhere, and come back, up and down. It’s just perfect, buy it now. If you’re not sold, here’s the kick: you know that main epic theme that kept coming and going in Moneyball, but wasn’t on the soundtrack? The one that practically made the movie? Yeah, that was This Will Destroy You’s ‘The Mighty Rio Grande‘:

You’re welcome.

Later in the year, my good friend Greg and I went to see Tomahawk in concert, so that of course revitalized continuous repeat of their albums for a few weeks. Tomahawk is the rock super group to end all super groups: Mike Patton from Faith No More/Mr Bungle/50-more-bands is on vox, and that should be enough to convince you outright to at least give their stuff a spin. Mit Gas is the record to check out, and the selling point here is this music video, which just happens to be the greatest music video ever:

The thing about Tomahawk is, these guys are truly pro. Hands down, the most amazing concert I’ve ever seen: these guys. They’re not visual overload, they’re not elaborate, and frankly, the mix at the venue we were at was junk, but none of that fluff matters, because their command of moving your soul both aggressively and with pro style – all at once, that’s where it’s at. You hear these guys’ albums and some of it sounds like studio magic that can’t possibly be done live, then you see it done live, and you kind of feel embarrassed for everyone else in the music business. These guys pound the bass, drums, with force, and a moment later they’re drowning you in the most beautiful cathartic melody for just a moment, then bring you back around to aggressive amazing all over again. Tomahawk’s one of those things where, you know, some rock music could be characterized as cock rock, aggressive for the sake of being aggressive – but, again, you hear this stuff, and the level of effort and talent involved and you realize that for Tomahawk, you really don’t give a shit about the labels – it just is, and it’s awesome. BTW, Tomahawk has a new album coming out in January.

Okay, those are the two worth gushing about for hours. Here’s the rest of it:

I spent quite a bit of time this year coding to electronic music of this variety of that. I don’t know or care what classifies as IDM or Trance or LeftField or whatever the hell, b/c it seems all of these artists have albums containing all of the above, so we’ll just call it what it is: good stuff.

First up, The Glitch Mob came out with an *amazing* album in late 2011. This is glitched-out over the top melody and move your body music. It’s just good, the end. They’re working on something for early 2013 right now.

Second, as I mentioned last year, I’m a big fan of 65daysofstatic, and one of their members put this incredible solo effort out as Polinski, it’s really great sweeping synth with a bit of glitch. It’s a short trip, but man, is it epic:

Third, BT’s ‘These Hopeful Machines‘ double cd is godlike. BT’s a ‘trance’ artist, or so I hear, but like most of his more-pop albums, this one’s just good in all of the ways, all of them. Some bits are trance mind benders, others are good old fashion pop electronic love songs dance music style. Like This Will Destroy You, BT likes to spend 5 minutes building up to something, but when the crescendo hits and starts crashing down, you feel the goosebumps and then the waves of cathartic glow wash through you, and you come out the other side feeling like you really need to write this guy a thank you note for the experiences he compiles, or at the very least, do something awesome with your life that may one day pass the feeling on down the line to someone else.

I heard a bit of hype about this Skrillex guy this year and mistakenly listened to his ‘Bangarang EP‘ on repeat, for days, before giving his other albums a go. DON’T DO THIS. Bangarang is a remix album of some of his earlier efforts, with some new stuff in the mix. The thing is, Bangarang is basically a more precise version of his tunes – an added layer of glitch, noise, and so on. There’s that, then there’s the fact that almost every tune has it’s BPM increased just enough to notice. So, if you listen to these things in the wrong order (or perhaps this is the right order..), when you hear the earlier efforts – you find them annoying, b/c they’re slower sloppier versions of the tunes you’re already in love with. Skrillex is glitchy noise, with the correct amount of cathartic breaks in the middle of it all. The EP takes you on a trip, a high speed headache-inducing trip if your mood isn’t just right – but if you’re in the right mood to handle it, Skrillex moves you.

I love me some glitch / noise, or “white noise bullshit” as my wife lovingly puts it, but there were also more than a few regular alt rock records this year that spun endlessly while I was coding.

Metric is one of those bands I don’t think I’d care for, had I heard them before their last record, Fantasies, came out. Frankly, I think they’ve come a long way since the garbage they were putting out before Fantasies. I spun Fantasies quite a bit in 2010 and even 2011, but it still felt – this will sound snobby, but if you’ve heard it, you’ll know what I mean – accessible for the sake of accessibility. Think Rise Against after Swing Life Away hit it big – that kind of accessibility compromise. In Metric’s case I don’t perceive or care that they were so accessible, it’s just that the music sounded not quite there. Fantasies came out, then there was a track on the Scott Pilgrim soundtrack that sounded next-level – I was hoping for more of *that* on the new album that came out this year. Good news, there is more of *that*. Their new record, Synthetica is fantastic. Where Fantasies had some bits that felt off, or goofy, Synthetica is 1000% more polished. I’m not saying Synthetica doesn’t have some not-quite-right moments for me, but I dunno, the ‘Breathing Underwater’ track, and any record that opens with a line like “I’m just as fucked up as they say” over an immaculate bed of synth – these things make it A+ in my book. There’s a deluxe edition of the album that was released later this year. You care about this, because there’s a haunting, amazing acoustic recording of ‘Breathing Underwater‘ on there that you need to own:

It’s funny, when Synthetica hit, I started to think about Garbage, b/c a lot of this new electronic pop makes me feel like Garbage was just ahead of their time or something. This all caused me to poke around on the internets about what ever happened to Garbage, and it turns out they were broken up or calling it quits for a half decade or better – but this year they returned. And, they returned, with force. The new record is the same old Garbage (that is, the first two albums, good, Garbage), but with a 21st century shine. It seemed their last couple or three records were getting into esoteric pop jangles seemingly aimed at churning out sales more than style, that’s gone. This new record is, I guess, power pop. It’s upbeat, but it has a next-level feel to it. It’s the same old Garbage, but the in-between tracks that should have hit the edit room floor are now where they belong – on the editing room floor. It’s definitely worth a spin:

There were also a few decent mope rock records this year, I think.

Notably, Maynard James Keenan (from Tool, A Perfect Circle) released another solo-ish record under the puscifer moniker. Like his other efforts, the album’s flow and quality from track to track varies to a worrying degree – but you get the sense this is his i-dont-give-a-shit take-it-or-leave-it artistic outlet. There’s some half-decent tracks on the record, nothing I’d consider as deep or touching as selections from his first record, but.. it works, I guess. I listened to it quite a bit for a few days, but then I discovered the Blood Into Wine soundtrack, which has some pretty awesome remixes from his first effort and one of the best tracks I’ve ever heard: ‘The Humbling River‘.. the track makes a great point of how accomplished one can be on their own, but without helping hands will never be able to accomplish anything of importance. It’s tracks like these that excuse the white-boy-hip-hop-trash filler that you find in between the tracks that matter on his albums. He may be playing practical jokes on you the listener 50% of the time, but when he cranks someting like ‘The Humbling River’ out, you can tell he’s still got it.

In the opposite direction, you have Trent Reznor, who’s still playing with the idea of making music with his new wife, they released another EP, which just isn’t quite right, just like the last one. And he released the soundtrack to girl with the dragon tattoo, which like the social network soundtrack, didn’t really grab me personally. Once you’ve heard his Ghosts album, this other stuff just sounds like he’s pulling the 9 to 5 punchcard and pushing the buttons over again for client X. Like Billy Corgan, Trent kind of trapped himself in this juvenile lyrical style, and now that he’s a happily married better-adjusted non-addict, he’s not that guy anymore. He has the talent to churn it out, and I have faith he’ll return to form with something mind blowing with a step up in maturity in time – but it feels like he’s still getting over his last few records and adjusting to a better life.

Oh, Billy Corgan also put something out with moderate success, it’s listenable, which is more than I can say for everything since about 2000 otherwise, but that’s not saying much. Maybe next time.

So, with all of the Rock Gods retiring, it makes me feel slightly less ashamed/dirty-pleasure to heartily recommend Linkin Park’s latest effort, ‘Living Things‘. Perhaps it’s ironic the boy-band/nu-metal professional commercial calculated band is sharpening up and moving forward in small steps all the time, whereas Rock Gods proper are treading water. Like many people, I didn’t care for Linkin Park’s first couple or three records very much – then Minutes To Midnight had some hooks and movement to it that signaled something better coming, and something better came. I think that next record, A Thousand Suns was a fantastic record:

I find myself spinning A Thousand Suns at least a dozen times a year, three years later, it’s just a really solid record. It was often compared to Public Enemy, if that means anything to you. Where Minutes To Midnight started bringing some songs with serious depth, A Thousand Suns jammed 3 really great songs together with perfect transition into every single track. With A Thousand Suns, guitars-front-and-center nu-metal lolz are sidelined for electronic-laden super-layerd grooves punctuated here and there with equal parts hard hitting reverb/death-march drum tracks and epic melody. This year’s effort, Living Things, was really good too. It’s not a concept album like A Thousand Suns, but it’s solid front to back. Though, to be fair it feels like a bit of a retreat – mixing more of the safe go-to style into the next-level stuff we heard on A Thousand Suns. A Thousand Suns wasn’t as accessible as other albums and suffered in sales because of it – and that’s a damn shame because A Thousand Suns was epic. I can see why these guys may be back on track in the safe zone, but man, I can’t wait for their next risky concept album move.

Relaxing Music

Some days are heads down code, and others are what-am-I-doing-with-my-life hassles for this reason or that. When I was taking it easy this year, or needed something to calm the nerves, here’s what worked:

For a while, I thought Sigur Ros’ new effort was forgettable. It seemed like a meandering half hearted return to a light/not-sure-what-we-want-to-do-now Agaetis Byrjun. I love their earlier albums, don’t get me wrong – it’s just that everything that came before was always upping the game to the next level this way or that, finally climaxing (for better or worse) w/ Med Sud.. being a pop record. I kind of wondered where they’d go from there, and I just set their new effort aside. Turns out, I just had the wrong frame of mind. You already have your Sigur Ros records to listen to when you’re sad, inspired, happy, or cathartic – what you didn’t have, until this year, was the record to just chill out with and recoil from the stresses of your day to day. This latest effort doesn’t have anything you can impress newcomers with – but it’s still Sigur Ros, and it’s still damn good:

On lazy Saturday mornings, my wife and I seem to continually put Death Cab For Cutie’s 2011 effort on. It’s good – a solid record, with the right percentage of low-key pop jingle intertwined with otherwise relaxed fare. It works, for almost any mood or any time, but it really seems to hit the spot on Saturday morning.

A couple of indie/folksy albums came out this year that are absolute must-listens, but like the Sigur Ros record, you absolutely must be in the proper mood to soak them in. Of Monsters and Men is equal parts sounds-like-that-one-band and i-dont-care-i-like-it:

First Aid Kit is great folksy throwback with a 21st century crispness over the top:

.. and their touring open act, Dylan Leblanc, has a great laid-back whispered wallowing tone that works with a glass of wine as easily as it does a dark room filled corner to corner with volume 11:

Background Music

For those days where I just needed something on:

Angels And Airwaves’ latest album ‘Love 2’, and their just-released EP are really good, as is the just-release Blink-182 EP. The Angels’ EP has a really great track called Diary, and otherwise is a great collection of instrumental remixes from recent albums, they made a great retrospective video for Diary (the real album track doesn’t have the robot voice over..):

Blaqk Audio’s second effort is decent enough, feels phoned-in compared to the first, but it works. Rob Zombie’s 21st century remixes of White Zombie and solo hits is pretty epic, and I feel like I’ll regret saying this, but the Deftone’s latest is bearable front to back, which is more than I can say for their past 2 or 3 records. The offspring put out a new album that’s really catchy, if annoying after N repeats, but solid. I had really high hopes for Silversun’s Neck of the Woods, but it seemed to fall into background-noise mediocrity surprisingly fast – not horrible, but generally meh:

There were certainly other records I gave a chance but am not mentioning, so all of the above at least have that going for them..

One more background album or two: The Smashing Pumpkins reissues are still a thing, and this year saw the Pisces Iscariot and Mellon Collie remasters + deluxe awesome. I’d highly recommend either release, in deluxe form, to any Pumpkins fan. I’d say Gish benefitted the most from the remasters, followed by MCIS. MCIS’ remaster is particularly impressive because they’ve created room to clarify bits you never knew existed (such as a ferocious bass line in the wall of noise during ‘Bullet with Butterfly Wings’), all without compromising the fuzzy/warm/crunchy/wall-of-mud signature marshall-amped guitar sound that seemed to drown all of this stuff the first go-round. The deluxe edition of the MCIS reissue is expensive, but worth the price in my opinion for some of the recorded-live-as-a-band takes that are damn near the final version of what’s on the record. The pumpkins were at their best when they were recording that record, and it’s really inspiring (like, pro tomahawk level stuff..) to hear the raw full-band aggression – you can tell they cleaned up a bit with studio tricks on the backend, but only slightly. Impressive.

Bonus: Jonny’s Stuff

My younger brother, Jonny, occasionally recommends a few bands he’s heard.

Here’s his credentials: he introed me to Metric, Of Monsters and Men, First Aid Kit; he fully agrees that Silversun is basically amazing; and he’d pass on any of my over-the-top post-rock or 8 minute electronic suggestions. He likes stuff that’s to the point, but at the same time he heartily agrees that the acoustic ‘Breathing Underwater’ is best-of-year material.

Here are the bands/songs he sent my way this year:

Later in the year, my friends Adam and Amanda heartily recommended The Lumineers (you’ll enjoy if you like First Aid Kit or Of Monsters And Men), and Ronald Jenkees:

Ronald Jenkees part 2:

I really try not to curse on the blog, but yeah, ^^^ that, fucking awesome.

Jonny actually recommended The Glitch Mob to me late last year, after I wrote my 2011 entry, and somehow I have a feeling Adam’s suggestion of Ronald Jenkees is going to be in the best-of/high-play-count list for 2013.

Finally, my wife recently heard some “white noise bullshit that sounds like something Jason likes” while eating lunch. She inquired about the white noise, and it was Tympanik Audio’s ‘Accretion’ collection. Tympanik is a record label, and this collection is a selection of tunes from their electronic artists over the past five years. 4 hours of music for $9 – it’s worth a shot.

So that’s music for me, 2012. Hopefully you’ll find something new here 🙂

Interviewing Technical Candidates – My Approach

A good friend of mine is about to interview a web development candidate and asked me about my approach to interviewing, here goes..

A little philosophy / disclaimer:

I’m a fairly proficient and efficient software engineer, I’m not a performance hound, and frankly, I suck at math.

I’m certainly a bit of a warm and friendly generalist more than a one-better-than-you-because kind of engineer. But I think, when you can afford a team of more than two people, diversity is *critical* to building a team that will deliver. Meaning, you want generalists, and performance hounds as well.

When I say diversity, I’m not talking about racial diversity, I’m talking about technical and interest diversity.

Your team needs people who are extremely creative, as well as some who aren’t. You need people who can ship, as well as some who may struggle there but may be performance hounds. Ultimately, you need *balance*. If you have a homogenous team of super-sharp super-bright perfectionists who can dream all day long, but can’t ship, you’re screwed.

Lastly, I’m the culture-fit AND technical guy on the interviewing circuit, and I think culture fit along with an ability to code at all is more important than poor culture fit with wizard-level coding skills.

If you disagree with these sentiments, you can probably safely ignore any advice that follows 🙂

The basics:

Just to be clear, before we start, my approach here is the approach I use with *every* candidate, junior, senior, more senior than myself, whatever. The only difference I would suggest with more senior candidates is to let them talk a bit at first, in case they’re already comfortable with the interviewing process. If they seem like they’re already comfortable, I’ll ease up on the re-assurances and such mentioned later.

An interview is a conversation. It is vitally important that both sides of the conversation feel comfortable, so the conversation can flow, and both sides can learn.

Remember that this is not a one-way game, any good candidate would know, and every candidate should know, that this is as much about you portraying the company as it is about them portraying themselves.

Interviewing is *not* about pressure-cooking a candidate so you can make them a low-ball offer on the back end of the deal, or establishing dominance before they’re in.

A really great candidate understands that there’s more to life than work, and that work is a part of life, so they will be looking not for a place that will pay their bills, but for a place that’s actually a worthwhile substitute hour for hour for those hours that you’re stealing/paying-for from the bits of their life that really matter.

That great candidate can practically walk into any software shop they want, and land a job, and that’s the candidate you’re targetting, so treat them as such: treat them as a rockstar (even when they’re clearly not!).

Once you’ve established that who you’re looking for is going to be amazing, interviewing becomes much, much easier. All you have to do is have a conversation with the candidate and let them tell you amazing things about their story so far.

There are two things you *must* figure out: first, are they a great cultural fit? second: can they code? Cultural fit is more important than coding ability, but the canidate must have both. A wizard coder who seems to be a jerk underneath is not what you want, more so than a really nice, kind, genuine, hard-working person with mediocre coding skills.

Don’t ask yes/no questions, and, if possible, ask questions that let the candidate talk about their experiences. You’ll learn far more about the person this way than with the standard interview questions I’ll outline later.

Don’t be afraid to ask questions that will help you figure out what matters to you (or at least what should): can this person do the job; would I want to work with this person; how does this person handle conflict; how does this person handle pressure?

Do give the candidate options for water, bathroom break, breather before you begin.

Do give the candidate time at the end (even if you’ve blown your time slot) to ask questions. If they have none, offer up that you always ask interviewers one question “What’s your favorite thing about working here? and what do you think could be better?” – then answer that question yourself, and then encourage them to ask that question to your peers who will interview them later. Tell them that is really important for them to understand as much about a job and people they’ll work with as they can before they get that next great offer.

You want this person walking out of your interview to be feeling really great, and informed. You want their decision to choose your company to be a decision they made with great confidence and enthusiasm.

There is no harm in admitting that other companies exist, and if a candidate, good or bad, walks on your offer in the end – there’s a good chance you’ll be high on their list of stories they share with peers about great interviewers.. which in turn, down the line, will bring more candidates in.

If it’s impossible to fit time for questions in because of some military style schedule keeping, give the guy/gal your business card and tell them to call you later anytime if they want to ask some questions that you can’t make room for right then. – Unless, of course, you can tell very strongly that you do not want to work with this person in the future.

Oh, one more basic, get them to sign a NDA (non disclosure agreement). Interviewing someone for 4 hours without an NDA, so you can’t speak freely about the actual job this person is going to do, is bullshit. Don’t be that guy, or that company.

About coders:

Generally speaking, coders aren’t the most social creatures, so for this reason I usually try to be overly warm and friendly while interviewing, rather than cold, curt, and silent. The candidate is likely nervous to some degree or worse, and sometimes if they get stuck, it gets worse, so if you’re friendly with them and help them along with hints here or there they may fail a few questions (b/c you have to help them so much) but do much better at others as they loosen up.

Personally speaking, when an interviewer goes the cold route, I personally freeze up and start wondering if the interviewer is playing a game or worse – is this what their culture is like? It *is* a dog eat dog world out there, truly, but for me, I get on and perform much better at a people/culture-first outfit than a bottom-line-end-all-be-all place. If the interview process is overly mechanical and surgical, the candidate gets turned off.

Once the candidate is loose and friendly, you can ask hard hitting questions more easily without much fear, and the candidate will likely tell you more truth about their experience than they would have had you been the guy who gives zero visual or audible feedback about how they’re doing.

It’s also *very* important to know that there are different people out there, some coders *cannot* ship worth a damn, but can find bugs super well, or figure out super complex problems. Some coders (me) can ship worth a damn, but cannot dream up possible bugs as easily, or do great at tricky math related problems.

A *great* team has a mixture of varying characters who respect each other and recognize that each person brings something to the table.

Don’t fault a candidate for not being an interview question wizard on some weird puzzle – those things seem a lot easier than they are when you know the question *and* the answer/trick.

If you’re hiring for a team of one, or your first hire for a larger team, you need someone who is very well rounded and can start from scratch, architect well, ship, debug, fix things, be flexible to change, and stick to it.

Additional team members can be the same, but may bring differing interests to the table: the guy who takes too long to do things, but writes the most performant code ever; the guy who is kind of complainy, but can predict and help fix bugs miles before they’re a major problem; the guy who’s a math head and can model complex reporting using statistics and such; and so on – depending on your needs.

Also, since coders are not very social creatures, many coders hate giving interviews, because they’re forced to be in a non-hierarchical chaotic unknown zone, and talk while they’re there. If you can overcome this inner turmoil yourself and be warm and friendly and show the candidate that you give a damn, you’ll be presenting a message that this is an awesome place to work with nice people who take their work and culture very seriously. *This* is the message you want to present.

You show the candidate that you give a damn by taking the time to loosen them up; asking them questions about their specific experience; showing engaged interest while they’re talking by asking questions; joking and laughing with them about the more annoying aspects of the career; actually looking into their side projects listed on the resume before the interview; and asking imaginative questions.

One more important thing about coders, generally speaking, they’re some form of OCD control freak / perfectionist, almost every time. This means they have an aptitude to solve ridiculously obtuse complex problems that nobody in their right mind would, and learn how to work with complex systems that nobody in their right mind should, but it also can mean they have too-high expectations of themselves and others.

In the interviewing playground this can really work against these guys and gals, because many of the candidates have not had the opportunity to interview other candidates themselves before, so they have not seen first hand that nobody’s perfect, and that often the candidate who’s hired is not the most technically proficient, but rather – a well rounded individual.

The technical interviewing circuit has historically been, and is, brutal. Academic institutions and huge dont-give-a-shit-about-you companies on the career fair circuit train and reinforce early on that what matters is technical aptitude and nothing else. That’s great for a fuck-you culture that wants to have management call the shots and hire voiceless coders to burn out perpetually, but real life can be, and thankfully often is, different: technical aptitude is a great talent, but it’s not the end all be all – and that’s okay if you’re not a wizard!

It is not uncommon to have a candidate seem to completely shut down on you because you’ve asked them a question that’s stressing them out and they can’t see the answer immediately.

Again – these are people driven by precision and control of their world around them.

Facing the unknown, and the added pressure of talking about themselves and being scrutinized can lead to overload, fast. Many of these uninitiated candidates expect you to be looking for this robotic superbeing that simply doesn’t exist, and they may very well expect themselves to be that superhero. The first, second, third little sign that they’re not so hot shit may really throw them for a loop when in fact they’re a great person, they just need some help.

Keep this all in mind when you’re reminding yourself to be warm and friendly.

Personally, I prefer to make it clear up front, at the first sign of weakness or shut down, that interviewing is a conversation and I’m not here to make them solve crazy problems alone in 10 minutes that take 4 hours in real life. I remind them that an interview is to see if I and my teammates would like to work with them in the future, so in that vein, we should work together on problems during the interview. I tell them that it is perfectly alright to get stuck, just like you do in real life.

With that re-assurance in place, it becomes easier to truly monitor what the person would really do when they’re stuck. You can easily give them a few seconds when its clear they’re stuck, and see if they’ll admit it or ask a question or start working a different angle, and if they freeze even still after your re-assurance, re-assure them again.

My thought is, as a teammate, it is part of your job to make sure your teammates succeed, just as it is theirs for you. There is almost no effort or harm in setting up your candidate up for a feeling of absolute success – and then grading them later based on how the experience went. If a candidate really seems to be dependent on your reassurance, is that something that fits your culture, or is that going to not work? If a candidate never once asked questions to clarify the problem space, will they ask the required questions to have success on the real project? And so on.

Technical Interview Phases:

Generally speaking, a technical interview runs like this:

First, There’s a phone screen where the hiring manager tells the candidate about your place a bit, then asks about their experience, and possibly attempts to figure out if the person can code at all.

Then, on site, a minimal 2 to 4 hour interview is given with different phases: cultural fit, experience/background, practical easy/concrete problem solving, and possibly: puzzles.

I’m of the opinion that you can take or leave the puzzles section if you’re happy by that point, if not, sometimes the puzzles crap can really show you the light in perhaps 1 in 10 candidates who otherwise seem to be a dud.

Microsoft/Google fans will tell you it’s all about the puzzles, junk like “why is a manhole cover round?” that’s really obtuse, to more reasonable oddball questions like “How long would it take a single person to wash every window on Seattle’s sky scrapers, if it takes 3 minutes per window?” – these less straight forward questions can show you very quickly how out-of-the-box/esoteric a person can think, but to me that’s much less important than the basics: would you want to work with them, and can they code?

A fun puzzle question:

If you must ask a puzzle question, my favorite from paypal days was: “Can we fit a million dollars in pennies in this room?”.

I love this question because it is physical, concrete, and there’s no “trick”. The puzzle questions often have some really clever trick insight to them that if you don’t know it, you’re completely screwed. Nothing is worse than a interviewer who’s so thick that he’s cocky about how smart he is (knowing the trick), but probably couldn’t deduce that esoteric trick himself if he hadn’t seen the answer two seconds after reading the question.

Answers to this pennies in the room question have been astounding at times. I recall one guy we hired working out spacial geometry (which always amazes me, b/c I am horrible at geometry) – which may have been overkill, but was a precise answer.

Whereas the simple anyone-can-understand-you answer I liked to hear was something more like:

“Well, a roll of pennies is about 3 inches tall, and that’s half a dollar, so for every half foot of height we have a dollar, or two dollars per foot height, right? This room is about 12 feet tall, so that’s 24 dollars per stack of pennies.

A penny is about 1/2 inch diameter, so in a square inch we could have four penny stacks, a square foot is 12″ by 12″, so thats 12 x 12 = 144 square inches per foot, multiply that by 4 penny stacks per square inch (this is where I whip out my calculator on the iphone, or let the candidate do that if they want..) = 576 penny stacks per square foot.

So we have 576 penny stacks * $24 per square foot in a 12 foot height room per square foot of floor space, that’s: about $14,000 per square foot. (dang..)

This room is 15×10, that’s 150 square feet, 150 square feet x $14K = about $2.1 million dollars, so yes, we could fit a million dollars in pennies in this room, and sit comfortably counting our riches, as well.”

The thing is, the geometry answer is more precise, and probably correct, but for me, an effective coder with some smarts, the geometry was way over my head. I had to wikipedia the equations for a few minutes after the interview to see if he was right!

If we wanted this guy to face project managers or worse, non-technical clients – would he be throwing geometric equations at them for problems with simple followable answers? Further questioning in that particular interview revealed that no he would not be throwing equations at people with less technical knowledge, he was just being technical b/c he expected I would be – he was able to dumb it down to my amateur-hour level quite easily as I asked him more.

On the other hand, the more verbose step by step answer is easier to follow, stop, back up, go forward again, until everyone’s on the same page. If *I* can follow the answer, there’s a decent enough chance this person thinks in small steps like this in general, and will write code we have a prayer of understanding when a bug hits while he’s on PTO.

The most important question:

If you can: Ask the candidate about their most favorite project ever, doesn’t have to be professional, can be hobby. This question and general questions like this will give you a really great gut-feel about who this person is and how they feel about and approach their work. You’ll be able to tell how involved or interested they were, and they should be – this is their most favorite project ever, right?

In my book it’s a really great sign of drive, and creativity, and interest, if they really enjoy something they’ve done before or are doing. I’d prefer a candidate with ambition and side projects (the more failures, the better), because that’s my personal style and generally the kinds of people I see the produce the greatest work with the greatest enthusiasm.

As they’re going along, talking about the greatest project ever (or so far), pick out a few things to ask them specifics about. If you’re not exceedingly technical yourself, it can be difficult to understand what they’re talking about and/or if they’re bullshiting you or not, so it’s best to choose trivia you know good and bad answers to. If you can’t find something easily, ask them generally something like “what was the best and worst parts of the project?”, or “did the project ship, why, why not?”, “what was the greatest technical challenge?”.

If the candidate completely freezes up, especially if they’re a recent grad who’s young, it’s time to be warm and friendly and be more specific, look down at their resume, pick the latest job and ask how that went and what they did there. It’s possibly a negative that they couldn’t offer something up on their own, but remember coders are sensitive and non-social creatures, so like a shy child it takes just a little more time to really see their eyes light up and get going. If the last job was horrible and what not, figure out if the job before was too, try and dig for something they enjoyed. If they didn’t enjoy any job they’ve been at, and can’t put a positive spin on something as silly as coding, they’re likely a cancer for your team’s morale.

While you’re looking at their resume, it’s a good idea to figure out if the candidate has ever been a part of a team that actually shipped something, and why not if no. Failure is not a reason to skip on hiring, failure is a good thing almost always if the person learns from the experience for next time, so keep that in mind.

Also figure out their level of involvement in the professional resume experience, did they have the opportunity and autonomy to solve problems on their own? Have they experienced rigid-bullshit land where an architect or manager demands minimal code and perfection via configuration and absolute worship of libraries and immaculate design in all things, even more than shipping? Have they experience cowboy-bullshit land where everyone is autonomous and friendly and structure is laughed at and progress suffers because of it? Someone with really great opportunities in their past will have seen both of these extremes and everything in between. If they havent, know where your company falls on that spectrum, and interview toward finding candidates who will be excited to be in that type of culture.

Example Starter Questions:

These examples should take a minute or two each, nothing crazy, and if someone knocks some of them out of the park you may just skip on to your better questions later.

Question: What’s the difference between a div and a table, and why would you use one or the other?

Answer: Years ago everyone used tables for everything, including laying out where stuff was on the page, the div tag, with css added, can do all of that so a div is basically a random box that you can do things to, a table is best used for actual tabular data like laying things out like a spreadsheet.

Their answer wouldnt have to hit all of this or be precisely what i said, but something along those lines.

Next question: javascript implies some programming ability, so ask them fizzbuzz:

About fizzbuzz:

Possible answers outlined here:

I’d accept any of the last two solutions, b/c for a simple five minute starter question like this, I dont care about the most elegant code style on this question, just that they *can* code.

Those are the easy questions, if they don’t get those two, and you expect them to do JS programming, yikes. If they’re doing good so far (which any candidate should), you at least know they have some bare minimal context.

For more intermediate questions consider something like:

Intermediate Question: Tell me of your most recent IE-hell experience, and what did you have to do?

Answer: IE is, to this day, incompatible with various standard html, css, js models in various odd ways. Most web developers will make their code work in chrome/firefox, then fix compatibility at the end in IE. No matter if they use jquery or great libraries to abstract the problem away and solve it most of the time, or not, they still hit this kinda crap *all the time*. The candidate should be able to describe in detail what was going wrong, and give you a good sense of how they compromise in a situation where they have little choice and are possibly upset by the idiocy they’re forced to deal with.

More Advanced Question: Suppose I’m a junior programmer who’s just learned about the innerHTML property in javascript and don’t know what DOM is, how would you explain to me why to use one or the other, and what they do?

Answer: innerHTML is a property on a DOM object (which in turn is a code representation of some tag in the html). when you assign a string like “<p>hello world</p>” to something.innerHTML, the browser parses this info and overwrites the inner html inside that particular tag. so before you had “<div<>p>goodbye world</p></div>”, and after assignment you’d have “<div><p>hello world</p></div>”. You *can* use innerhtml for quick hacky ways of generating HTML in strings and changing the page easily, but there are more robust and flexible tools for doing the same thing using the DOM Model. The DOM model lets you inspect the HTML document’s structure (tags), and walk up and down, inside and outside of a given tag or node. With the DOM model of programming you can find children tags by id or other means, replace them, add children after them or inside of them, etc. Further, if you have a page with a lot going on, using innerHTML is not going to be as performant, because the browser will be doing a lot of work parsing and creating DOM html objects for it’s internal DOM structure out of those strings you keep throwing at it.

Better questions:

Better questions come from your own experience. Think about a problem you recently solved yourself, that was kind of tricky, and ask them how they’d solve it. I usually preface these kinds of questions with a disclaimer that I don’t expect them to do 4 hours of work in 10 minutes with absolute precision, nor do I expect them to solve everything alone, let’s work together and figure out different ways this could work.

As the answers go along you can prod this way or that with questions like “That sounds good, are there any issues we’d need to worry about if we do it that way?” – This is especially fun to ask when you don’t even perceive issues yourself – sometimes the candidate will surprise you in being smarter than you, and other times you’ll get a sense of how a candidate handles confidence and/or arogance when they’re certain the solution is the best.

The truth of the matter is: code’s never done, and can always be done differing ways, doing things one way may be the best in terms of time to code the solution, but not great for X Y Z, if a solution is technically sound, these other more esoteric concerns could be discussed.

If your direct work experience is not exactly relatable to the candidate’s position, make it relatable.

For example, you worked on a windows system that may have a windows GUI, a great question may be: “When I was working on this windows GUI, it was tricky to make this widget work correctly for different window sizes, how do you handle that kind of thing in your web development for a browser?”

Even Better Questions:

If you have time, let the person actually code something, on a real computer. Give them an hour to do something you’d expect to take 30 minutes. Tell them they can use google, stack overflow, whatever they like. Tell them before the interview this will happen and that they can bring in their own laptop with their own code if they want, so they can copy/paste or reference a solution they’ve already worked out before for pieces of the problem.

In this kind of setting you can do all kinds of things:

a) Write a function that tells me if all letters are in a string with a boolean result.

b) Make a small webpage that takes has a div, a textbox, and a button. When the user taps the button, the text in the textbox is added to the div.

c) Show me some jquery tricks, make a box animate for me. Make it move to the right when I click a button in the page, and make it appear or dissapear with a fade when I click this other button.

If the candidate comes back in 10 minutes with these answers (reasonable for a senior candiate, more like lets say 30 minutes for a reasonable junior candidate w/ some experience), ask them another, or ask one more complicated:

a) Alphabetize all of the letters in a string.

b) Validate that the text box contents are alphanumeric, and show a nice error that fades away after a second if there’s something bad in the text box.

Notice that even these more difficult questions are *not* rocket science. You’re not hiring a rocket scientist, you’re hiring a coder who’s going to be putting up with shifting schedules and bugs in other people’s code, and doing things fast when we can’t do them elegantly b/c we don’t have time, and so on. If you test for extreme technical proficiency, you’re losing time better spent figuring out those other equally important abilities.


There are some great books out there about technical interviewing, I’d particularly recommend the mount fuji book, because reading it really eased my mind about technical interviews.

The basic story that book will tell you is: Microsoft invented technical interviewing, and most everyone followed this particular style of interviewing blindly, because it worked mostly. Microsoft found that it’s better to weed out a million maybe-good candidates, than hire one bad candidate – because a bad candidate can be a cancer, as I mentioned previously – and it’s difficult to get rid of someone, especially if they’re not outright horrible in some fireable way. The mildly horrible are the worst ones..

Personally speaking, I think some of the Microsoft/Google-way of interviewing is a bit dehumanizing for candidates and may overly prefer coders with jaw-dropping technical skills but not equally important human skills.

It seems the to-the-book style those guys use does not test well for creative spark or leadership ability, which in my book are critical things to understand about an incoming candidate. A coder who breathes OpenGL wizardry or cache-line/register insanity (in 2012, no less) is awesome, but only if they have the spine to say no when they should.

I get the feeling some of these technical-merit-trumps-all fun houses are a bit predatory in that most of the people I’ve know to get through the processes have been surprisingly low on my “would want to work with” personal scale. Not all of them, some really amazing friendly people I’ve met are over at Google now, for example, but they’re definitely not the rule.

Anyway, the books are still great learning material for the history behind technical interview processes, and they contain tons of sample crazy questions..

I would also *highly* recommend reading this book:

Coding Horror is a great programming blog, one of the more famous blogs on the subject. His e-book he published earlier this year is one of the best things I’ve read this year, and more than a few of his favorite blog selections in that e-book are posts about interviewing style and process. I do not necessarily fully endorse or agree with all of his opinions on interviewing, but you should not completely agree with me or anyone for that matter. The book is *excellent*, the end.

Interviewing is a skill.

At the end of the day, interviewing well (as an interviewer or a candidate) is a skill, and an important function of your job. I recommend that you take it very seriously, and encourage the jerks you work with who don’t to consider taking it seriously too. Candidates are not warm bodies or numbers, they’re humans who want and deserve the same things in life that you and your teammates want and deserve, treat them as such, even if they suck. Just don’t hire them if they suck.

You won’t be a great interviewer the first, or fifth time you interview, so I recommend shadowing some other teammates while they interview for those first few go rounds.

Once you have a few rounds under your belt, you’ll realize that like your great engineering team, a great interviewing team needs diversity.

It’s okay to have a peer who’s really aggressive or cold perhaps be one of the later interviewers in the schedule, as long as he, and the rest of the team takes his ‘personality’ into account when he comes out with the left-field cynical insanity about the candidate everyone else loved.

You yourself may be warm and fuzzy and more culturally minded, like me, rather than super technically brilliant, which means you’re a better cultural fit phase guy – there’s no harm or problem in that.

The key is to structure your interviewing schedule to have the person comfortable, and shining, as early as possible – and have your interviewing team well rounded, with equal parts personality-people and tech-heads in the mix.

Finally, on this topic, I have the following advice: pay attention to who’s hired and not.

This is feedback to you about how well you are or aren’t interviewing the candidates, as well as feedback about what the culture is looking for.

I’ve been in cultures where everyone was a hot shot and they couldn’t hire anyone b/c they wanted nothing less than superheros always, unsurprisingly – I was never asked to interview there, and I was a bad cultural fit for their culture in general. And.. I’ve seen cultures that were more laid back and so permissive that almost anyone could come in the door, and that had an entirely different set of problems.

I’ve had enough interviewing experience now that honestly I can tell quite a bit about a company’s culture (or at least their sincere interest in well-fitting candidates) based on their interviewing style and techniques – and you’ll get there too.

A short story

I didn’t start interviewing candidates until I was about 3 or 4 years into my career. I always feared interviewing other people because I was so horrible at interviewing as a candidate myself. I did not want to see how awesome everyone is at interviewing and further crush my own perception of my interviewing abilities.

As I mentioned earlier, coders *really* do not like interviewing, from either side of the table, and one of my teammates was the prototypical example of this. He was a great conversationalist and had a great sense of perception, so naturally, he was a permanent fixture on the interviewing team – and he hated it.

One day at random he asked me if I would interview in his place, and I was hesitant for reasons outlined above, and he almost immediately offered me $1000 to take his place. I laughed at him, and then I stopped laughing – because he was not laughing. He was serious. We ran it by our HR guy, found no ethical dilemma, and considered it an out-of-band cash bonus incentive to join the interviewing team.

Being paid $1000 to start my personal interviewing saga is funny, but in actuality, my friend single-handedly shoved me beyond a silly perceived wall I’d set up for myself, he forced me to go interview some candidates – which in turn showed me the other side of my silly perceptions.

Thanks to him I learned very quickly that I wasn’t alone in my fear and clumsiness in being interviewed, and I found a serious interest in figuring out how to really interview a candidate well, in a way that would give them the best shot of shining and strutting their stuff in the process.

Seeing the other side of interviewing, from the interviewer’s side of the table really showed me how full-of-bullshit the dogmatic technical interview process/style really is if you’re just going to buy into it hook-line-and-sinker without using your brain a little.

Microsoft and Google have part of it right: the candidate needs to know how to code, and you need to test a bit to figure out how they handle conflict and such, but it doesn’t have to be a pressure cooker.

Insane puzzles with no correlation to the real world job you’re interviewing for are not really where it’s at. It’s more than that.

Credit where credit’s due:

When I was out of college, doing the career fair circuit, there was one interview in particular that always sticks out in my mind.

Where I had been dog meat (a warm body, a number) in every interviewing situation before, the interviewer opened up the conversation asking me about some very specific little shareware products I had made and listed under the hobby section of my resume.

That interviewer really took me off guard, and for a moment flipped everything I expected from technical interviews on its head.

Essentially, my personal interviewing style, 8+ years later, is to make my best damn attempt I can, every time, to replicate that amazing interviewing experience, where my past colleague, and friend, Brent Schneeman, showed me how friendly and amazing technical interviewing really can be.