A Tale of Two Interviews, Part 1 | Hacker News Reader

A Tale of Two Interviews, Part 1

youell.com

133 pointsjavinpaul74 comments

Make sure you read Part 2: http://www.youell.com/matt/writing/?p=801

I shouldnt need a compelling reason to work some place.

I - need a job, presumably they need someone with my skillset, now obvious, there are soft skill concerns, do I match the culture, is it going the direction I feel my career ought to go? Other then that, it should be pretty simple.

A general rule for hiring is that one should never ask a question where its impossible to tell a good bullshit answer from a good answer. The bullshitters will always do better, and thus your biasing your hiring process to bullshitters. Answers to questions should be signal with extremely high information content. A question where a good bullshitter will get a disproportionate amount of points is in fact a net negative to your hiring process.

If you're the type that needs personal validation such that you would knock a candidate for saying something like "I need money, you guys are paying in money", then you simply shouldn't ask the question. Of course, people love to think that they have a highly tuned bullshit detector, are immune to blatant flattery, etc. The problem is everyone thinks that. We are all susceptible to these things and we need to make sure our process is such that its not biased towards people who are particularly good at telling you what you want to hear.

Thanks for writing this. It's a succinct and lucid description of the problem with the "commitment & faith" class of interview questions.

There are two sides to the coin, of course. I personally don't mind being asked about my motivations because I tend to only apply to companies that I actually want to work at (paychecks notwithstanding).

I'm hiring at the moment for CircleCI, and if you don't have a reason to work with us, that's a real red flag. That says you have no particular interest in the job, which means you either don't care about what we're building or what our customers need, or you might jump ship if a job comes up that you really do want.

That said, you applied for a job here, so there must be some reason you want it. Maybe "I ended up in a really bad job and I want people who care about their craft", "I love Clojure and you guys write everything in clojure", or "I love your flat organizational structure", or "I like making developer tools". But "i need a job" is a terrible answer, and won't even get you past the phone screen.

Every girl wants to feel 'special' too. But really, there's 3.5 billion of them.

You are just going to weed out all the people who are not bullshitting you, and take in all the people who will. And amazingly, you are happy proclaiming this!

I'd thank you for weeding me out though. I like reality. Don't like happy rainbow snowflake dreamland, which you've just outed your company as. Since such things never last.

It took me a long time to find the special girl for me. If you approach dating as "any girl will do", then I feel sorry for the girl that ends up with you.

I don't know how you translated "wanting to hire people who want to work here" into "happy rainbow snowflake dreamland", but so long as people who don't care about our product or market feel weeded out, then I'm happy. For others reading this who do actually care about the people, product and technology you work with, please let me know at jobs@circleci.com.

Meh. Look at the example reasons in the post you're responding to; you don't need an answer like "I want to save the world, and I'm pretty sure the best place to start is in the plastic chair manufacturing sector".

If the best you can offer is "uh I need a job" that means you don't know a damned thing about the company you're applying to, doesn't it? I.e., you found a list of 30 companies that are offering jobs in your city that vaguely match your CV, and instead of reading about them and choosing a few, you're taking the shotgun approach.

If you read about them, what made you choose this one?

Do they seem like they have a culture that's better than your last job? Do they use a language you like (and/or would like to use more)? Are they doing something you know anything about, or find interesting at all, or can at least categorize as "not morally objectionable"? Almost anything is better than "I need a job".

The 'feel special' analogy is a terrible one. Surely you don't propose picking the first person off the street to marry just because they want to be married?

>"i need a job" is a terrible answer, and won't even get you past the phone screen.

Which is why it should be part of the phone screen. In the article, they didn't even ask this until after the 5 hours of interviews. Ouch.

You shouldn't need a reason. But if it's a close choice between you and someone who's really good at faking enthusiasm, who do you think they're going with? We're only human, and people like being told their company is awesome. It validates their life choices.

Yeah, it might be fake, but it could also be the chance to work somewhere amazing. I have gone to a few jobs like this, where the job was fantastic, involved working on grid computing, traveling around europe. I did not have to fake enthusiasm, but I can imagine a lot of people would not have cared for it.

I agree with you, but honesty can be expressed in different ways.

"I'd never heard of you guys, but when I was searching around your thing seemed a lot more interesting than some of the other things."

And on the employer side, unless you've actually got tanks out back from having turned water into wine you might notch the erection down a few degrees. There's smart people everywhere, that's not special.

You don't need it, but perhaps they do. It's far better for an employer if you're particularly enthusiastic about what you're going to be working on.

I think you probably need a compelling reason if you're not unemployed and they didn't come to you first.

Since there are so many companies out there, giving some reason as to why you picked this particular one seems fair.

I would usually go with something compiled together from separate things: - New challenges - Location - Their field of expertise - Their culture

This is where it can get murky. If you are firing off a bunch of resumes to jump ship from a poor situation, honesty doesn't get you very far. While if you were targeting the company from the get go, honesty is your best option. It doesn't sound good to say "my current job sucks, and you guys responded to my resume", but if you don't want to say that, then you will scramble to come up with something that sounds like what you think they want to hear.

I can understand how a company wants someone enthusiastic for their product/company, on the other hand I can understand how alienating it is to have to bullshit about the reality of your situation.

My "go to" answer in that situation is to describe the kind of role I'm looking for, and then give some reasons why I think their company matches that. If I'm wrong, and they're a terrible match, then I don't want them to hire me.

If you have any interest whatsoever in the product they are working on's success for example, tell them that. That's a good thing to tell them. If all you want is any job anywhere then you can probably work at Subway. If all you want is any job anywhere that pays as much as they do then at least tell them that.

I myself have asked a candidate why he wanted to work for [my employer] in a position of some responsibility, and been unimpressed by the reply "well, it's a job." I had no idea this was a commonplace response.

It's good that you recognize from their feedback where you went wrong, but it's bad that you don't understand why "I just want a job" is a poor answer. Your cynicism about "Cubicle Dream" also doesn't sit well. (Not trying to be harsh - I know exactly where you're coming from, having been there myself.)

Here's a secret: in the workplace, unlike school, attitude trumps raw ability. Every single time.

Think about what you really want. Maybe read Ask The Headhunter.

Good luck.

>Here's a secret: in the workplace, unlike school, attitude trumps raw ability. Every single time.

This is true... but only because the workplace is run by total fucking idiots.

I mean, I'm one of those people who always looks way better in the interview than I actually am. Excited, engaged, confident, interested in your problems... but seriously? you'd rather have me? some overconfident douchenozzle over someone smart? I know of several setups where I was interviewing against someone I know was better than me, where I won. I remember once, I got a guy who used to work for me an interview at a place where I had a full-time sysadmin job. (For much of my career, I've alternated between doing my own company, and working for other people.) the guy didn't get the job, apparently because he didn't interrupt my boss enough (who kept getting interruptions throughout the interview.)

The hilarious thing is that I'm a total mercenary; I'll leave your sorry ass for the first 20% raise I can get, while those people with a 'poor attitude' will stay at the same place even though they are underpaid and treated poorly, for years.

It's kind of like how employers prefer tall white guys. It's fucking retarded, but if I turned down all jobs where I think that worked in my favor? I'd turn down a lot of well-paying work.

I mean, sure, if it is mercenary work; if you want a problem (in my area of expertise) solved and then you want someone who is cool with being let go the next day? I'm probably a pretty good choice. I don't expect loyalty or anything; pay me on time for the hours I worked and I'm happy. I also do pretty well when one needs to ignore social mores or corporate bullshit to get something done. (I'm terrible, though, when /following/ those rules is important.) And I'm not completely stupid. Certainly, there are times when you won't be able to find someone better, in which case, you take what you can get, eh?

But for full-time "we want you to stick around for a while" jobs? I'm a comparatively terrible choice... I mean, assuming you have other applicants that are smarter and have basic competency. but from what I've seen? I do way better than people who are obviously more competent than I am, because of that arrogance.

I really like this comment for its honesty and ability to reflect on yourself with such brutal honesty too.

I'm not that confident and get really nervous before interviews, even for jobs that I'm not sure I even want. However, once I pass my nervousness, I can come across as "Excited, engaged, confident, interested in your problems" as you said, and also most times funny and fun to work with! However, I believe that in truth, whilst I can be funny, I'm not that much fun to work with. I can be argumentative, picky, stubborn and not easy to compromise.

I try to work on these attitude issues, but it's not something so easy for me to fix. However, in the interview context, like going on a date, I obviously won't expose those faults.

So there's definitely a disparity between the first impression a person can give, even over 5 hour pair programming sessions, and working day after day with them...

Yeah, well, evaluating people is /hard/ and, I would say, pretty nigh impossible to do well in a few days.

>However, in the interview context, like going on a date, I obviously won't expose those faults.

I dono about interviews... but I do know that in sales, sometimes revealing faults, especially real faults, can build a lot of trust. (I mean, the 'real faults' bit really only applies if you are selling something to a customer who understands the product... but that's really the only kind of selling I do, outside of the "selling myself" interview context.) It's more like dating than you think, though, in that I generally don't want to waste my time with someone who still believes that they will find someone "perfect" - you want a employer or customer or date who has been around the block and knows that everyone has flaws, and you've just gotta pick the flaw you can deal with. Then you want them to know about your flaws pretty soon after they know about your assets so that you can both cut your losses if a flaw is a dealbreaker. anything else is wasting time.

I mean, you've gotta show the counter-party your assets first, but in sales, that's easier than in dating, at least for me, as most of my sales prospects read about and come to me; they already think I'm pretty okay, so I can hit them with the "and here are the problems with my setup" just about right out the gate. Come to think of it... the time I've been really successful dating went similarly.

>So there's definitely a disparity between the first impression a person can give, even over 5 hour pair programming sessions, and working day after day with them...

Yeah. My biggest asset is that I do really well in novel situations. My biggest flaw is that I do really poorly once I'm settled in and the situation is no longer novel. So yeah; good short term contractor, shitty long term employee (compared to someone else with a similar level of knowledge)

I dislike like the "why do you want this job?" question because, unless I'm unemployed and really needing a job, the fact of the matter is that I don't know if I want the job. Interviews go both ways. I'll need time after the interview to consider the experience and try to predict whether I'd be happy working there.

Unless your company is doing something extraordinarily cool, chances are your product is not enough in and of itself to attract many if any developers on that basis alone. What will attract people is the quality of the work environment, the quality of the people, and the amount of money you can offer them. That's really the gist of it, and during the interview the candidate won't have exact knowledge of any of those factors.

As an interviewer I'd far prefer a candidate who said 'I'm still not sure I do want the job - it looked interesting, but I still need to get a sense of your team and how you work' than someone who said 'actually I just need a job'. 'Actually I just need a job' is one of the worst answers to that question.

Personally, I'd not like either answer.

You have to watch out for people just using you to get a better deal at their current job. That's why I put expiry clauses in all offers.

When asked the question about why I want to work somewhere I'm smart enough to sorta-lie, but when you get right down to it the real answer boils down to the fact that I want the job for the money. If I didn't have to work for money, I'd spend the time I spend at work hacking on my own projects.

Having said that, of course not all jobs are equal and some jobs are much more desirable for me than other jobs and so I will focus on these unique traits when describing why I'd like to work on that job, but if I were interviewing someone and they mentioned their primary motivation for taking the job was to get paid, I'd think it was a refreshingly honest answer and not hold it against them.

I think his issue was he was bruised and battered after 5 hours of relentless questioning that answering a question like that was the last thing on his mind.

A 5 hour interview is a ludicrous amount of time to take out of someone's day.

If it takes someone more than an hour to determine a programmer's basic worth, then they should fold up shop. The extra 4 hours is a waste of both side's time. You won't really know how good the person is until they are working for weeks or months so how to do you expect to learn this in 5 hours?

This is fascinating for me, I just came out of a 7 hour interview day earlier this week feeling hyped up and energized (although a little croaky after talking for 7 hours)

4-5 hour interviews seem pretty standard for any higher level position. A couple years ago I had an 8 hour interview. Now that was insane.

> It's good that you recognize from their feedback where you went wrong, but it's bad that you don't understand why "I just want a job" is a poor answer.

A bad answer but an honest answer. I mean, until you work at a place, or unless the job is fucking amazing, there is no reason to pick one over the other. For 95% of dev jobs, there is no big reason.

I sometimes think companies fall under power law distribution, when it comes to being interesting. Most of it is CRUD app work.

Let's not forget something. Interviewing is also an skill that you will learn. If you are actively searching for job (because you're unemployed, or you really want to leave your current job), you'll know what to expect and be more confident and perform better on each interview. After the fifth interview, you have already faced 90% of all those pesky algorithm questions. I don't really believe in those kind of questions (other than for screening purposes)

Anyway, as a company, if you are able to create an atmosphere when interviewees can relax and show "how they really are in a regular day" is a great win.

This needs repeating - interviewing is a skill you have to, and you can learn.

Like lsc below, I'm also a "mercenary". But probably much less competent and maybe even better in interviewing.

My background is in humint which gives me some skills to "read" people, figure out exactly how to build the trust with the interviewer, get them to like me and even manipulate the conversation towards the questions I want them to ask me... In my 17y IT contracting career, I didn't have a single interview that didn't end up in an offer despite my significant lack of algorithms or programming knowledge. Luckily, I didn't have 5h pair-programming interviews.

You can make it "click" with the company and you can manipulate their "gut feel" to tell them that you would be the ideal candidate for the position.

It's not fair and it's irrational that people like me can get the job instead of some much more capable developers, but that's what humans are - irrational.

This article made me kinda curious - is it common to go into an interview expecting to have to write algorithms? I've read about this frequently but writing enterprise software I've found very little occasion to write algorithms. I say almost but I probably could just say that we never write algorithms at all.

I'm not saying algorithms are unimportant, obviously a lot of the tools we use rely on that type of skill. Just that enterprise software is almost always more about workflows, schema design, UI layout, automating processes, etc. Possibly some accounting math is used but generally those formulas would be provided by the accountants anyway.

Is this just something interviewers are asking because it indicates school training? It is just a benchmark of general awareness? Does it indicate understanding of the simplistic recursion that some algorithms use? It seems to me just testing plain old memorization of forumulas - it's not like I expect the interviewee to have thought up the fibonacci sequence on his/her own.

Most people on net forums don't want to be in the enterprise software world, even if they are.

One small thing I was wondering about - how comfortably can you drive in a pair programming session on someone else's computer?

I mean, I don't mind being in the back seat on whichever editor the driver is using, but if I'm driving, I really feel awkward without vim and my plugins and key bindings etc...

I was thinking the same, but in reverse. If I asked someone to sit and drive my esoteric setup, there is no way they'd even be able to type code let alone be productive :D. And the same is true when I walk over to help someone. I start typing and then I realize, this isn't vim, they don't have my .profile in their shell :D, ah fuck it, let me do it on my machine and I'll check it in or send you the change.

In my experience, it can be a little awkward. At one point I interviewed with a company that uses Rubymine almost exclusively, and I had previously only used Sublime / vim (and Eclipse for Java).

It was definitely more distracting than I would have thought going in. Everything is a potential hickup, from tab switching, file navigation and basic shortcuts. It's definitely less than ideal, given that you're essentially context switching into basic operational stuff when what actually matters is the logic of the problem at hand.

More than IDE, it's about the code you are doing. If you aren't comfortable with the IDE other person is using, I think you should request to change it and that person should allow.

My understanding of pair programming is that the driver never even touches the keyboard. Do I have that backwards?

I think you have it backwards. According to [1] at least:

"Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in"

[1]https://en.wikipedia.org/wiki/Pair_programming

The Internet lawyer in me gasped when I read he was pair programming, especially driving. Did he sign a transfer of IP rights and copyright beforehand? Placing his code into production? He still owns the copyright on that code...

It was a work for hire. He got paid in lunch.

Maybe it was open source software and/or he went through a simple CLA process?

I've had both kind of interviews before, and the latter made me want to work for the company so much more. Ever since that interview, it's how I conduct my interviews now -- no more whiteboards or pointless algorithm questions, I just bring in my laptop and we work on something together.

Interview is a two way street, they interview you, you interview them. Basically, you just didn't like the first company and clicked with the second. Don't put too much weight on the interview style. If they didn't extend you an offer, chances are it would be even more frustrating - it's harder to figure out what went wrong with the second interview as they are relying more on the "gut feeling". The first one is a bit more systematic. Both styles can work fine.

I think there is a lot more to it than that. I have been to interviews which were almost hostile like the first one, and the opposite, where it was almost a conversation.

I do not understand people who do the first type. Why? The interviewee is the enemy.

Sure, but read closer,and you'll see that the impression of the two interviews is based almost entirely on the subjective terms the writer chooses to describe them. One person was the "shark on the team" whose questions got "very aggressive", while the other was "intimidating but tolerable" and "I could tell he was protecting the quality of his team".

Or consider "Instead of demanding from me why I wanted to work there, he just tried to get a feel for what I was aiming for."

Was there really a difference, or did the writer just click personally with one group and not the other? If it had gone differently, I could imagine him writing that "team one was respectful of my time and allowed me to order my favorite sandwich and eat during the interview, while team 2 expected me to waste yet another hour socializing with the group at a bad restaurant, where they got very aggressive asking about my personal life".

So maybe company one really was hostile; just like you, I've seen that happen. OTOH, maybe it was just a personality clash, or maybe some of it is slanted by the fact that he got an offer from one and not the other. In my experience, once an interview process starts to go bad, I start to see everything the company does in a bad light, and vice versa.

This is cool. At one point I worked at a startup where they hired a guy who interviewed well but froze up constantly when pairing — sort of the opposite of this story — who consequently didn't work out. Seems like pairing-as-interview would solve both that problem and the freezing-up-at-whiteboard problem.

I admit to being sufficiently extraverted and borderline autistic myself that I don't have a good understanding of why people find his "part 1" interviews stressful and freeze up. I mean, it's just talking to hackers, right? I like talking to hackers. Who doesn't like talking to hackers? But I guess standing up and talking in front of a bunch of people, or being grilled to see what you understand and what you don't, is a lot more stressful for most people than it is for me.

Hm, I thought ~ 5 hour interview process wasn't uncommon?

Must be a US thing.

My first job had an interview that lasted around 2 hours.

The second had one interview that lasted 90 minutes, then a follow up interview a few weeks later for 90 minutes.

Taking up 5 hours of someone's day (especially if they are unemployed) is wrong and downright pathological. Job seekers are often desperate to get back into the market and abusing their time is grossly unjust. It's fine for the interviewer, they have a job and are in a position of power to decide the fate of the interviewee.

Not sure how its abusing their time? In any company I work for, I want to ensure that people who join my time are going to be good for my team and the company. You're going to be working with an individual for years hopefully, and the cost of getting rid of bad hires is really high: shouldn't you spend a few hours to make sure they're the right person?

5 hours of the existing employees time is super expensive too. If they're investing the time for the full hour interview, they probably think you're worth it. Think of it as them spending like $2000 on you (at least).

Seriously? Australian here; longest interview I've had is two, but they're usually an hour long at most. There may be two rounds of single hour interviews sometimes.

(How are you supposed to take five hours out? Ask for leave in advance and hope the company doesn't mind waiting a fortnight for you to be able to show up? I usually interview before or after work.)

Heh, in academia, interviews can last for days. The minimum is typically an entire 9-5 schedule. Sometimes it's in multiple rounds.

Same here. My interview for my current job lasted about 7 hours.

Man, I'd honestly find example 2 more stressful than example 1. Is pair programming really something that programmers find useful? Should I develop this skill more? I've barely had to do it at all at my jobs, and when I have, it was difficult for me because I couldn't get into my usual flow. Even with an extra pair of eyes and hands, I felt like I was working at 50% efficiency.

I guess I should read up on concurrency. :)

Pair programming is really interesting. I've taken several courses where there was an optional pair programming portion, and after trying it a few times, I swore it off for good. I hated pair programming because every person I worked with just sat there (without interest). Which is just stupid.

But recently, I did some pair programming with folks closer to my skill level, and it was much better. I wouldn't swear by it or anything, but we were both working through a really hard problem, and it was helpful to write code together. It was slower, but I felt like I absorbed the problem quicker.

Also, one tip: plug in an extra keyboard. The driver is still the driver, but if the other chimes up and thinks of a better way to write a particular piece of code, it's easier to just let them instead of having them explain it to the driver or having to switch the keyboard over or something.

> Is pair programming really something that programmers find useful?

Some do. Some people swear by it.

> Should I develop this skill more?

Yes, definitely. Think of it as being a more social version of learning a new programming language or systems architecture.

> [I]t was difficult for me because I couldn't get into my usual flow. Even with an extra pair of eyes and hands, I felt like I was working at 50% efficiency.

It's definitely an acquired skill. If you think about it, though, if you're spending most of your time while programming engaged in typing, odds are you're probably doing something wrong (or working in a ridiculously verbose language ;)

> If you think about it, though, if you're spending most of your time while programming engaged in typing, odds are you're probably doing something wrong.

He didn't say anything about typing. Pair programming is meant to be slower than alone programming, the extra eyes and ears actually slow you down because you have to reach consensus so often.

Pair programming is about quality, not productivity.

And quality is in turn at least partly about productivity (i.e., it's usually faster to avoid the bug than to fix it after the fact).

It really depends if you need the quality or not. Also consider Gabriel's "worse is better." Anyways, doing pair programming can be considered as another tradeoff (as you more than halve the productivity of your team); it shouldn't be valued as always a net positive.

Yup; lots of variables to play with. As long as we're actively aware of the tradeoffs (and adjust approach as needed) it's all good.

I don't personally find pair programming very useful most of the time, though I've done it now & then... though I do benefit from the half-way version, which is to occasionally talk through problems I'm working on with other developers (in detail, with code).

I personally benefit from the rubber duck approach, but I'm a researcher without so many people to talk to.

Read it. Awesome! So you what happened to the Startup? Did it fail?

Seems like this issue with the first job is you just weren't that passionate about the company.

The worst thing you can do is trick people into hiring you. You'll waste precious months/years of your life.

Most people are not passionate about a company. How can you be passionate about a company you have never heard about, for people you have never met before?

Is there really a need for a phone interview?

I mean, you could just look at their github, and the writing on their blog, to determine if there's a baseline of competence.

I know this sounds crazy, but hear me out:

The vast majority of talented programmers neither have a github account, nor do they keep a programming blog.

Upvote, beacuse I see myself as a descent programmer and my github account has been idle for ages.

Not to mention that holding a full time job and my wanting to spend time with my wife and kid leave very little time to maintain a blog (which I don't) or contribute to OSS (as much as I can, but next to nothing compared to other readers of this site).

Github can sometimes be a lot of copy and paste from either other repos or Stack Overflow or tutorials and such. For blogs, many very talented developers don't have one (or don't keep it up to date), and so it's very difficult to determine and verify ability just from an online presence.

Eh. I still think GitHub can be useful, it just might take a little more time. Instead of simply scanning the list of projects, take a quick peak at the commit logs for a few of them. It should be pretty clear based on the workflow if it's just a copy & paste job, or if the developer is actually working.

Someone could certainly game that, but it's a stretch...

Reply on news.ycombinator.com