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..
- How Would You Move Mount Fuji?: Microsoft’s Cult of the Puzzle
- Cracking the Coding Interview: 150 Programming Questions and Solutions
- The Google Resume: How to Prepare for a Career and Land a Job ..
- Puzzles for Programmers and Pros
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.
