Category Archives: Interviewing

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: http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Possible answers outlined here: http://c2.com/cgi/wiki?FizzBuzzTest

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.

Resources:

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:

http://www.codinghorror.com/blog/2012/07/coding-horror-the-book.html

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.

Finding a Job

Finding your next great adventure is a numbers game in many ways. You are the perfect match for some position out there, it’s just a question of finding that place, or perhaps, that place finding you.

In my book, there’s an ordered list of ways to find a job:

  1. Create your own job.
  2. Places you want to work.
  3. Places your friends work.
  4. Recruiters who target you with non-spam.
  5. Recruiters who target you with spam.
  6. Random job postings.

Create your own job.

If you’re creative, self-driven, and have a great idea or two, why not create your own job?

If you’re already tinkering, all you need to do is take your hobby a bit more seriously. Polish your hobby into a product, make a website, form an LLC, and go take over the world.

You never know, your hobby may turn into passive income, or it may even subplant your real job. If not, there’s no faster way to learn new skills and grow to appreciate the intangible benefits an employer provides or provided for you.

Places you want to work.

If you already know where you want to work, your job-hunt is over, sort of.

It’s a good idea to tailor your resume for the exact position you want, and make sure you interview at a few places you *don’t* want to work first, to get the interview jitters out of your system.

A great way to get an inside pointer or two is to search up a recruiter on linkedin for the company (assuming the company’s big enough to have their own recruiters).

And please, do not interview for position X, when you really want position Y.. you’ll just be wasting team X’s time.

Places your friends work.

After a few years of experience, your peers will branch out to new opportunities with other companies. It’s a good idea to keep a list of awesome people you want to work with again in the future, and email or do lunch with them when your job hunt starts.

Having a friend on the inside will give you a better look at the not-so-great truths of the place and give you far more information than any interview process will.

If you don’t have friends who are branching out, and you’re not happy where you are, it’s time to find that next job and take a risk that your peers don’t seem to be taking.

The great thing about taking that risk is that you’ll likely land at a place with other risk takers just like you, which may lead to a happier work life, or perhaps even friendships with people who *will* take the risk to find the next great job again when the time is right.

A great way to meet new risk-taking friends is to attend and participate in local user groups and discussions. Most any metropolitan area will have meetups you can attend, here’s a list of stuff I’m aware of:

Recruiters.

To understand the recruiter animal, you need to place yourself in their shoes. A recruiter is someone who’s a great networker. Their job is forming relationships with hiring managers, and hooking them up with you. The good recruiters excel at helping the hiring managers understand what talent they need, and the bad recruiters will break your arm for a shitty hiring manager when the low-ball offer’s in site.

A recruiter (generally) gets paid a 10 to 20% finders fee, meaning if you make 100K a year, the recruiter will get a 10K or 20K check for hooking you up with the job, so you can understand a little freak-out or pressure on the recruiter’s behalf when an solid offer actually comes through.

Just remember when the recruiter’s freaking out, that it’s not your problem or duty to make them happy – if you don’t like an offer, haggle, and if something seems fishy (such as a feeling of being pushed around a bit or bullied), you’re probably best off to just decline altogether. After you’ve met some recruiters in town, and watched the game for a bit, you’ll probably learn why some hiring managers and recruiting firms are pushy, as they’ve always got positions open due to high turnover.

There’s spammy recruiters, and less spammy recruiters. There’s corporate recruiters working for the man, and brave little groups of headhunters striking out on their own. If you want a corporate job at a juggernaut like IBM, you’ll need to find a recruiter for the company via linkedin. If startups or small to mid size companies are your thing, that’s where the self-made headhunters come in.

Never give your real phone number to a recruiter you do not trust, instead use Google Voice. All recruiters, spammy and non-spammy alike, will email you new opportunities they hear of, but some of them will cold-call you on a monthly (or worse) basis. You can’t fault the cold-calls though, remember this person’s job is to network, and they’re good at what they do.

It’s a good idea to make a list of your favorite recruiters, and keep that list close at hand for your friends when they start looking.

If you’re starting fresh, perhaps one of your past colleagues already has their own list of favorite recruiters, otherwise you could start with mine:

Austin recruiting firms:

Other recruiting firms:

Alternatively, you could, and should, post your resume on all major career sites, and that will bring the recruiters out of the woodwork. Here are places to consider:

Random Job Postings

If the recruiter scene isn’t your game, or even if it is. Taking some time to filter through a bit of the job-posting noise on your own may net you your next great gig. If nothing else, you’ll find names of companies in your area. Here are job posting sources I’m aware of:

Hopefully these resources will help you improve your next job hunt.

Remember, if you can afford it, don’t rush your job hunt, be patient, pay attention, and take the time to filter the signal from the noise. Your forever, or next-5-year adventure is out there somewhere, you just have to find it.

Great Interview Questions

Interviewing is not a one-sided conversation. If you land a job by only worrying about successfully impressing interviewers, you will almost certainly be surprised, and you may be unhappy once you start the job.

It is critical that you understand that an interview is not about making the company happy and fitting their mold, it is about finding a good match for both you and the company.

How do you make a good choice in choosing the next place to work? Simple, you ask questions! And how do you make the best possible choice? You put some effort in and come up with some great interview questions.

Don’t do what some of your crappy interviewers will do and google something random right before going to the interview, actually take some time and think about what matters to you.

There are obvious things you would want to know about a company, such as what hours you’ll be working, and how much you’ll be paid. But, there are also tons of subtle but important things you can figure out before receiving the offer.

If you don’t have a list of questions organized, The Joel Test is a great place to start.

I strongly recommend making your own list of questions, printing them out, and bringing them with you to every interview you attend.

You will not have time to get answers to all of your questions, but I recommend making an exhaustive and prioritized list of questions anyway, so you can work out the answers that matter to you or concern you as your interview process wears on.

I have my own list of questions that evolve over time. My questions are almost certainly not going to perfectly capture what truly matters to you on your next job hunt, so be sure to put some effort in and make your own question list.

From my experience, I would highly recommend getting as many details out of the recruiter up front, rather than waste everyone’s time if they’re not planning on paying well or have insane work hours, or whatever else.

It is also important to ask the following two questions to each person you speak to, no other questions will reveal more about the truths of a company, the culture, and the employees than these:

  • What is your favorite thing about working here?
  • What could be better?

Keep in mind that not all interviewers are honest (at times for fear of losing their jobs, sadly), so if you intend to deduce a not-so-great truth, it’s best to ask questions that require an answer beyond “yes” or “no”. For example, don’t ask if the interviewer likes working at the company, instead ask them what their favorite thing about the company is.

And, if you really want the true truth, ask for it like a detective would from separate witnesses, that is, ask the same question to each person who interviews you. In the best case, you’ll have a more robust picture of a truth at the end of the day, and in the worst case you’ll have different stories and know to avoid the company.

If you find that the company’s interview process is not welcoming to your questions, the company is telling you immediately, with perfect clarity, how they treat their employees and how much they care about this position.

Here’s my list of questions:

recruiter questions

  • location?, multiple offices?
  • if far: telecommute ok? flexible hours?
  • offer range?
  • is the position full time? salaried? contract?
  • if contract: expected length? contract to hire? 1099, or w2? paid overtime?
  • is telecommuting an option, as needed, permanent?
  • how much travel involved?
  • team size?, division size?, company size?

questions for each engineer

  • how long have they worked at the co?
  • what is their favorite thing about working here? what could be better?
  • are developers empowered to do their job?
  • are developers empowered to speak up and get problems fixed? are other people (UI, business, mgmt, qa, ops, etc)?
  • who do they work with? (dev lead, project manager, multiple managers, other teams?)
  • how would they characterize the co’s culture?
  • what is a typical work week like?
  • how many hours per week avg?
  • how many weekends worked past year?
  • what are their responsibilities?
  • what else do they recommend i ask?

position questions

  • what would my responsibilities be?
  • are there remote or telecommuting team members? if so, how is collaboration done?
  • how is work split up amongst the team?

project questions

  • how long has the project been in development, and when was the last release?
  • how long is the current phase of the project codewise, and when is release ballpark?
  • are subsequent phases of the project currently planned?
  • how many projects or project releases are worked on at once?
  • what languages, libraries, and technologies are used for the project?

process questions

  • what dev methodologies are used, how long are project iterations? what tools are used?
  • source control? what type?
  • how is product, api, and code documentation? who does it? how often?
  • builds: one-step build? nightly integration builds? automated tests run?
  • how are product dependencies managed?
  • how is 24/7 support managed?
  • how are live deployments & support managed?
  • what sacrifices are made when product completion nears? (pushed deadlines? cut features? cut quality?)
  • are there annual busy or slow seasons?

tools

  • process tools? (scheduling, resolving I.T. issues, comm ticketing systems for other groups)
  • dev tools? (OS, IDE, debugging, profiling, building & packaging, DB, libraries, dependency management)
  • remote collaboration tools? (conference calling, im, video conferencing, screen sharing)
  • live/test tools? (OS, deployment, monitoring, automated testing)
  • documentation tools? (wikis, etc)
  • work environment? (laptop, desktop, multi monitor, test hardware, etc)

test/live env questions

  • is there a test env? how does it differ from live?
  • is there a qa team?
  • are there unit tests, or automated test suites?
  • is there an automated build?
  • are test suites automatically run periodically?
  • what types of testing are done? correctness? usability? load/performance?
  • does dev and qa write tests?
  • is there a bug tracking system?
  • how are live and test issues debugged?
  • how is deployment done?
  • what are some typical examples of issues found in live (scaling issues, data consistency, install/config consistency, etc)?

work/life/culture questions

  • are there quiet working conditions?
  • how are career goals (advancement, raises, etc) managed?
  • how does the company make (or plan to make) money?
  • how is current funding?
  • how often are layoffs?
  • how much pto per year, and do people use it?
  • what kind of team or company events are there?
  • what kind of on-campus amenities are there? (food, beverages, pool tables, trails, sports, gyms, parking, etc)
  • does company sponsor or encourage training, conference attendance?
  • does company encourage contribution to open source?
  • what are core hours? do all engineers work exactly 9 to 5? or do some come in ealier/later?

hr/offer questions

  • relocation package offered?
  • stock options? RSUs? vesting schedule?
  • bonuses? if so, how (cash? stocks over vesting period)?
  • signing bonuses?
  • 401k? what kind of matching?
  • other benefits (health, dental, vision, sabbatical, parking, etc)?

Correctness in the Real World

Music: Glitch Mob – Drink The Sea

I failed calculus in college. I’m an applications guy, in that, if I can’t see the point, if I can’t see the payoff, I have a lot of trouble convincing myself effort is worthwhile.

What happened was this: It was my first semester in college, and I took my professor at his word. He said there would be no curve at the end of the semester. The day of the final, I had two finals, one at 8 AM (calculus) and one at 11. Never quite a morning person, and making a 37 grade in calculus thus far, I slept past that one and instead got an A on my CS recursion final.

I could see the point in recursion, it was real to me.

A few days later I talked with one of my calculus peers who was also aiming at a grade of 35 or so out of 100. He went to the final. His final grade? He passed the class with a ‘B’. The professor was so bad, or perhaps just trying to teach us a little something about life, that he curved anyway.

My final grade? A 37, because I skipped the final I knew I would not pass. I took the course again a year later and passed (with a healthy and generous curve).

What we perceive as correctness/truth and what actually happens or matters in the real world are often two different things. This is a concept that can be incredibly hard for engineers to grasp, but this concept is key to surviving in the real world.

Often you are given a complex, or seemingly unsolvable problem with a timeline that makes no sense, and your “correctness” problem solving skills go out the window. In these real life situations you’re going to find your career teaching you a lot more about artfully cutting corners than precise algorithm correctness.

Consider for example the following interview problem:

You are given a list of items. You know the list’s size. The list contains apples and oranges. Find the last apple in the list with the fewest number of comparisons.

The conceptual algorithmic “most correct” answer to this question is simple, you do a binary search. That is, a algorithmic way of dividing the list in pieces and searching for your needle in the haystack with as few steps as possible.

A binary search is a fundamental algorithm you learn in college and is almost gauranteed to find your item in as few steps as necessary. If you don’t see this as an answer fairly quickly, the interviewer will probably be concerned.

But, as a smart little coder, you know the answer, and you’ll enthusiastically answer “I’d use a binary search!”

That’s when the real fun begins, the interviewer will then respond: “right, binary search is what works, now code that, on the whiteboard, in ten minutes”…

At that point your mind turns to mush and you immediately start stressing out about horrific bounds checking nightmares that you’ll never possibly solve correctly in ten minutes.

The trick to the interview question is this, a good interviewer isn’t looking for the absolute *correct* answer alone. A good interviewer is trying to see how you think, how you work, how you’ll approach the eventual bounds checking nightmare and corner cases. Hell, a good interviewer may not care if the code you write is completely correct at all, as long as you can communicate your intentions and think on your toes as you work through the problem.

But what about the real world?

Suppose you get the job, and your former-interviewer/new-coworker says “remember how you said binary search? well, can you do that for us on this project..?”

This is where the theoretical idealism of correctness starts fading and the real world sets in.

When presented with anything algorithmically complex, you should be asking yourself “how can I make this easier?”, and ask as many short-cut questions as possible. There’s no point in writing or (better..) finding a binary search implementation if it’s not actually what’s needed.

Your engineering training background will feed you little worrying thoughts of “doing it right, the 100% correct way”, but it’s your job to bridge the gap between theoretical fantasy land and the real world.

Will your project be fundamentally better if you burn a week solving this problem, rather than 2 hours? Probably not. Will your project manager or dev lead be happier with you for solving the problem 95% effectively in 1/10th the time? .. yes. And, when 95% isn’t enough, you can explain to the management that you need 10x the time of your 95% solution to get the more-correct answer.

When you solve problems effectively and efficiently, you’ll have more time later to re-evaluate which little cut-corners to invest more effort in. When you solve problems correctly in the pedantic academic sense, you’ll be slipping ship dates.

But how do we simplify?

The answer is simple: Take a walk. Get away from the computer, grab a coworker, and go for a walk. Free yourself to think on the problem from more than the “100% correct, perfect” angle.

Another easy way to simplify something is to ask yourself “how difficult will it be to test this?”. If it’s going to take you a day to write a decent unit test suite, figure a week of solid engineering and debugging time to get the algorithm right.

When we dont have 6 days, we figure out what works, and simplify. Allowing room for solving the problem better in the future.

A real world example of this came up for us on our TumbleOn product. We’re adding a feature to the application that allows a user to jump anywhere in a blog’s posts. A Tumblr blog has a mixture of post types such as text, video, photo, etc. TumbleOn only looks at photo posts, and Tumblr only tells us the total count (including all post types) of a blog’s posts, so essentially we’re looking for apples in a long list of a known size. This becomes a problem when the user says “jump to the end”, because, while we know the total number of posts, we don’t know how far backward we’ll search to find an interesting post.

Our first attack on the problem was the “correctness” attack, a slightly optimized binary search of sorts, with all kinds of complex rules built into it:

a) when a blog has more than 20,000 posts, check 1,000 back, see if we get a hit, then try 500 back, etc
b) when a blog has between X and Y, check different intervals
c) and so on.

Long story short, it was complicated shit, and unnecessarily so, and the worst part was developing a test suite to catch all of the horrible edge cases. The test suite itself was turning into a nightmare, nevermind the algorithm itself.. all to find the last apple in the list.

We didn’t want to take days to solve this problem, so we thought outside the box for a bit, away from the computer. We asked ourselves what corners could we cut now that’d work good enough; be easy to test; and be improvable in the future (if we ever cared). After only a few moments we came up with something much easier, our so-called “screw-it algorithm.”

The “screw-it” algorithm to reverse search (aka: brute force):

Just search backward from the end, until we find something, stopping with an error at 10 search attempts inward from the end.

Many an engineer will have a hearty laugh at our cop-out/simplification, but wait, there’s real-world ‘science‘ to the choice:

a) if/when Tumblr exposes the photo post count in their api, our algorithm is even easier, and this will be trashed.
b) our application is only looking for photos, and there’s 50 posts per attempt, so if we can’t find a photo in 500 posts, chances are this blog’s not really photo-centric to begin with.
c) we dont want to spend 3 days debugging our algorithm, and 2 days writing it
d) we want the algorithm to be testable, easily
e) we want to have time to add other value to the application

We started implementing the “screw-it” algorithm, when it hit us, why not instead do the “who even cares?” algorithm.

The “who even cares?” algorithm:

When it’s a corner case, if at all possible, just show a descriptive error and let the user deal with it. If it becomes a big issue later, work on the issue some more.

In this particular case, the chances that a user jumps to post 100,000 and finds no photos is slim, and it will take the user 1 second to instead jump to post 99,000 in this very rare case. We can (but never will) optimize on this usability corner case in the future if we really want to, but that’d be pretty pedantic and there’d be about 10,000 other things we’d improve first.

You’re taught, and interviewed as if you’re supposed to be making 100% correct uses of famous algorithms, and nothing but. It’s important to know about famous algorithms, and know when to use them. And if you’re at the JPL or working on something like a medical device, the “who even cares?” algorithm is not an option. But, 99.999% of the engineers in the world are not at all involved in a project where a hand-written reverse binary search algorithm (or quick sort, or a dozen other super-complicated-to-get-correct algorithms) is at all relevant or crucial.

The thing is, the future is sort-of infinite. The features you want to get into your software by deadline NEXT are known, but the features you can get into some future version is unknown and therefore infinite in possibility. Burning time today being pedantic about a million irrelevant details just eats tomorrow.

If you can get 15 features into your application today with a handful of difficult corner cases avoided until later, or 3 features in with all corner cases solved, which would you choose?

Being a software developer in the real world requires an ability to be flexible and know when to go academic vs practical. This is the fundamental difference of “correctness” in the academic sense, and correctness in the real world.