Hacker News Reader

On the rationality point, I've definitely been one to talk openly when asked about times I've failed / would have done something differently. I've looked at it as a no-loss scenario: if I'm talking with a company and they can't accept that no one is perfect, then I'd rather not work for that company anyways.

Interviewing in a sense is kinda like dating, one way to really screw things up is if you're both looking for different things. If you're both trying to get into a fling, then yeah I guess lie your pants off and have unreasonable expectations of each other. If you're looking for long-term match, just lay your cards on the table and if you match, you match.

There is one rather big key difference in dating versus interviews. You only get once chance to find out _everything_ about a company during an interview. Whereas dating has many "meetings". This is the real problem with interviews. They're an all or nothing.

Many selective companies have many phone screens and coding projects, plus hours of on site interviewing. Google's process notoriously takes months. Some companies interviews likely take 10+ hours all in all. That's more like 3rd date territory in terms of hours spent together, and plenty of time to evaluate a hire, not some one shot thing.

Google's process consists essentially of 2 meetings - phone screen, and onsites. You don't get engaged to someone after the second or third date. It's not about hours spent, it's also about hours spent reflecting on the relationship.

So right here is the mysterious reason why perfectly qualified people don't get hired at Google - they didn't spend hours reflecting on the relationship!!!

I realize you're trying to mock me, but you've totally failed because that's exactly my point. If your interview process consisted of a 6 month work trial period for every single candidate (and assuming no candidates dropped out), you would pretty much be able to detect nearly every single qualified person. Of course, this is not feasible in practice, so we settle for interviews.

Oh, so that's why.

Here I thought it was their high false negative rate. I should have known it wasn't the google process.

Google's process is absurdly slow.

Dating only has many meetings if you don't tank the first one.

Interviews are like blind dates, you need to be in the social circle to have an idea of what you're getting into before you go to the interview.

First dates are probably most analogous to phone interviews. It's a testing of the water. If you've met the barrier of entry, you'll probably make it to the next one unless there is no chemistry whatsoever.

> If you're looking for long-term match, just lay your cards on the table and if you match, you match

This is an excellent point. If someone does this I view it as a signal that they are intelligent, rational, and honest.

A key distinction is that daters who are really good at identifying the right life partners are rarely on the market.

I worked in an organization where we used behavioral interviewing techniques to get to the core of how someone operates.

"Tell me about a time in which you..." works very well. If they resist answering the made mistakes questions we prompted them to understand that an honest answer is important. If they could not do that then they were not considered.

These were not developer roles but most were very technical / analytical roles for an organization that paid well and candidates knew up front they would be interviewed this way. In addition some jobs were "cased" where you had to solve a problem and talk about how you solved it to the interviewer. Great fun when I went through the two days of interviews. I ended up doing maybe 200+ behavioral interviews over 6+ years for the company. I saw this approach work time and time again.

Some people could not answer for themselves: "the team did..." "They did...". When pressed we usually discovered that the candidate did not have the ability to get the job done themselves.

> "Tell me about a time in which you..." works very well.

These types of questions probably cause me more stress than any other. Being asked to think of a situation where you felt a certain emotion or had a certain mental experience is not actually that easy for everyone. My memory is terrible at that kind of thing.

It's like my memory lacks a necessary index for what you are asking. I can start going through every major work experience I've had in sequence and filter out the ones that fit, but we might be sitting there in silence for 2-3 minutes which gets awkward enough in itself.

And it's not an inability to remember mistakes specifically, I mean the old "tell me about a time where you solved a problem with no prior knowledge of the domain..." gets me. I solve problems like this ALL THE TIME. That's a skill I have. Fetching those times from memory is not a skill I have.

Luckily I've had these questions in enough interviews that I generally try to have some examples in mind.

Incidentally, behavioral questions are common in nontechnical interviews, since the entire interview is spent analyzing a candidate's skills in the abstract.

How will I know if this person is good at, say, sales or biz dev in a vertical with long lead times? I can't vet that skill set directly; I can only ask the candidate about it. Behavioral questions give me something to cross-reference in the absence of on-the-spot performance data. So do case questions, which (at least ostensibly) tell me how a candidate thinks, and how she organizes her thoughts. (And of course, domain-knowledge questions help me assess the depth and quality of a candidate's experience in the field.)

Behaviorals aren't perfect, though. They can be gamed. It's not too much of a stretch for a candidate to memorize a half-dozen anecdotes to trot out in response to any question that begins with "Tell me about a time when..." (Nevertheless, you'd be surprised by how few people do that sort of prep work.) Canned responses are especially common with candidates straight out of school or grad school, where they are often trained in how to answer behavioral and case questions.

I have the same problem. I couldn't think of these things on the spot for the life of me. So awhile back I googled 'Top Personality Questions on an Interview" and filled out prompts for each question way in advance, and then I review it each time before right before I go into a an interview. Made the rest of the process much simpler.

Hah, I'm exactly the same, and not just with this, with everything. I just have a hard time retrieving things by index when prompted, and I envy people who can just recall interesting/funny things that happen to them. Things happen to me too, I just have to be reminded of the situation to recall it, I can't just go "funny thing? Ah yes, I remember X".

I've got one particular project that usually fits these questions. And if it doesn't, I can tell enough interesting stuff about it to satisfy the interviewer anyway.

Exactly, same here !!

I find your last comment interesting!

From my experiences with employers in many parts of Europe, they value partial contributions to teams more than complete individual achievements. Talking to much in "I did..." sentences instead of "We did... (...and I helped with...)" can come across as self-centered, which often is considered a negative trait here.

So noted. We asked follow up questions to get to a person's contribution. It is valid to move the team forward. It is not valid to ride on the contributions of the team without putting your own contribution in.

This is exactly where biases creep in to evaluation. It's really, really hard to assess these signals objectively, and not use them to justify your snap judgements or prejudices. So maybe when the guy with a college sports background and a military-style buzz cut talks about how 'the team' did stuff, you mark it down as a sign of being a great team player and sharing credit. But when a guy with long hair does it, you assume he didn't make any individual contribution. And if a young woman talks about 'I' did stuff, you interpret it as confidence and evidence of personal contribution, but an older lady with kids does it and you dig in hard for evidence she's taking credit for others' work. Not personally accusing you of these specific biases here - just trying to show how these vague 'personality' judgement signals can be unconsciously misjudged by an interviewer, without them even knowing that's what they did.

At the company I work at when we interview we tend to ask tougher and tougher questions until the candidate either starts spouting BS or replies that they don't know. BS is a no-hire.

If you're going to do this level of hazing, save yourself some time and just have the candidates compete in a big Jeopardy match. Those that don't know will stay silent, those that know will answer correctly, those that don't know but answer anyway will be punished more than if they stayed silent.

Personally I'm pretty tolerant of a lot of BS, depending on the person. Sometimes it's just a cognitive quirk that someone uses BS to search around their brain see if they can trigger some association that lets them remember, or discover that they really don't know. Saying "I don't know" immediately is often the wrong thing to say (especially in interview settings) when the real answer is "I don't remember, let me rediscover / look that up", but not many interviewers let you look things up or will mark you down if you say you'd need a reference for X though you studied X some years ago in college like everyone else and might work it out (after wading through a bunch of BS and false-starts in general) if you had unlimited time and no pressure...

An ability to state "I don't know that" without shame is a strong positive signal of intellectual maturity, but I'm not sure that I'd want to press it out of a candidate by asking an impossible question, if it had to get to that point. The process that you describe isn't one that I would feel comfortable using, but I like the objective.

The thing is, at the edges of people's knowledge there are two issues.

One is, people want to demonstrate what they know about the topic, even if they can't answer the specific question. If you ask me to explain elliptic curve cryptography, I can tell you that it's useful because it uses smaller keys then prime based RSA crypto, and that's something I'd want to mention to indicate that, despite the fact that I'd need to look at a book or writeup to actually implement elliptic curve cryptography and I'm not sure I can verbally explain the math behind it, I at least know something about it.

The second is, at the limits of my domain knowledge, I may not know what I know and don't know. Limits are fuzzy, and I may feel like I have a pretty good understanding of a linux file system from a user perspective (permissions, inodes, etc) but I couldn't implement one off the top of my head and I'm probably missing some important components. As an interviewee, I may have incorrect or incomplete knowledge, but not know that. That doesn't mean I'm bullshitting intentionally, I'm just trying my best to answer the question I think you are asking.

Also I have to think that other developer cultures may have different values around these ideas then my own. Maybe the cultural expectation is to show confidence in my ability; I know that confident individuals are more likely to get hired or even apply for jobs, and that often job requirements are a screen for confidence.

Sure, I'd love if I knew every gap in my knowledge and every mistaken understanding I have, but I don't know how realistic it is to suggest a deliberate deception on the edge of a person's knowledge.

And that's setting aside whether the interview process is a good predictor of workplace behavior... I think we all know people who are excellent devs that can't write on a white board for shit, or who sit down for a good think for an hour and then come up with a perfect solution but aren't going to be able to write and simultaneously talk you through a solution to a 15 minute data algorithm question.

Knowing what you don't know is pretty important, because then you know when you have to go look something up rather than rely on your memory. When I have to call mmap(2), I know that I have to read "man mmap" first, because I know that I just can't remember the order of the five arguments, or if that's even the right number. I've been working with UNIX type systems for 30 years or more, and have worked on the guts of three different kernels on many different architectures, but when I say that I know UNIX, I think that I mean that I really know where the stuff I need to know is described in the man pages.

It's important to have approximate knowledge of many things, including how to look up and figure out the shit you don't know.

That said, I think you balance assumptions vs knowledge in order to be effective. Like you assume that it's in the man pages, and the man pages describe the code that is being used on your system, but it's entirely possible that your version of vim or whatever is different then the one described in the system wide man page.

No one said "impossible". Just harder and harder. I think this is okay, especially if the interviewee knows that's the plan. Make sure they shed the notion that they're expected to know everything that is asked of them, let them know that your plan is to challenge them.

A developer who can't accept a challenge that stretches his/her boundaries a little bit is probably not a developer you want.

I completely agree that I want to hire programmers who want to constantly learn and improve, but I'm not sure that I should expect them to do so during a stressful high-stakes interview.

I've had good success when we introduce the conversation with "We're going to ask a bunch of questions across a variety of problem domains. We don't expect anyone to be strong in all these areas, but we want to get a feel for where your strengths are, and then we'll drill down into those areas"

But, once you do that setup, everyone is eventually going to say that they don't know what they don't know. It's exceptionally rare for someone to be able to delve into the implementation details of a couple of different programming languages (of our choosing), cryptography, distributed systems, relational modelling, CS theory, and a variety of algorithms and data structures.

So "I don't know" ceases to be much of a signal, since everyone says it a few times.

In fact we prefer to see the opposite, where people are willing to tell us the bits of info that they do know. Even if you don't know how two phase commit is implemented, knowing what problem it's trying to solve will allow you to research it when the need arises.

Because an interview situation is so unlike a normal workplace environment, I don't know any reliable way to translate their willingness (or otherwise) to say "I don't know" in the interview, to on the job behaviours. Either you'll coach everyone into it, or you'll be letting the interview pressure (potentiality) distort their behaviour so much that it's too hard to derive a signal from.

This is basically how PhD qualifying exams work, as well as the defense to an extent.

You're welcome to guess or describe how you'd think about something, but you should be willing to clearly state when you're really out of your depth. It's important to note, though, that this isn't done adversarially; it's usually just a natural conversation that goes down a particular rabbit hole.

As you said, interviewing itself is a very stressful environment. I've been asked a time I've failed by one of the HR person and I talked about it. Was basically sending emails to real people from my test environment...

I talked about it openly but he kept pushing. In the end my feedback was that my "time I've made an error" was not very impressive.

Like... wtf? I find these questions very weird. I never know what they're expecting as an answer.

Imagine you start a job painting houses. You would not paint them the same way on your first day as you would after a year of experience or 5 years of experience. What have you learned? How do you work smarter/better now than in the past.

What experiences triggered that learning process, or did you just take orders from someone else with a more problem-solving oriented worldview.

The same applies to technical work. We're not perfect robots, we are given the freedom to figure things out, so the goal is a refinement of the "program" in our minds. The more effective/sophisticated that program is, the more rational we are.

Why don't you just ask for their self-performance reviews / retrospectives for the last n years of their current/previous job after you've filtered by resume? I suspect that unless they were expecting it (which isn't unreasonable since a lot of interviewers have variants) "remarkably unsentimental" people like John Carmack would blow this part of the interview. Why do you care about the step-by-step process of my programming journey, which is irrelevant to whether the current me can help you out right now? If you're trying to test for passion ("why'd you start house painting anyway and what drove you to keep doing it for so many years?") or self-awareness there's probably a better way.

I would consider asking for that too invasive. I think the important thing to get a sense of is how they look at problem solving as a function of expertise.

In other words, it's possible to be smart but not act smart, and it's possible to act smart while not being exceptionally intelligent.

I'm basically looking for self-awareness of one's own cognitive limits and evidence of a meta-process that seems likely to result in better decision making than whatever the raw intellect would offer.

I don't get how that relates to the question asked to me? I mean, it was a time I had a problem / failed that impacted production environment. That was the only one I had in mind, the guy looks like he was expecting a time I've put the servers on fire. It simply didn't happen.

Another thing is that my current environment IS very CTO pushy taking order and doing his view. Why stating this counts against me? It's not like everyone can take leadership in the tech stack / implementation.

I am a 100% sure that I would get into his (big) company and just follow orders as well. Of course having my implementation and my personal touch every now and then but still I wouldn't get to make architectural decisions or choose the tech stack.

Unless you're working in a 100% microservice architecture with hundreds of small people team deploying separated stuff I don't see how that can happen.

As a rational person, I'm going to be honest in an interview, and if the interviewer doesn't value that, then they can just suck a turd. :)

>I think this is a super important characteristic for a great employee to have, but I don't know how reasonable it is to expect to see much of it in an interview. In an interview setting, the candidate is under a lot of pressure to come across as "perfect" in the sense that they want to appear to meet all of the expectations the interviewer has for them.

I would never hire someone who couldn't honestly speak to making mistakes and being wrong. We're human, and your ability to be self critical and learn from your mistakes is one of the single most important aspects in continued professional (and personal!) growth.

It should never be difficult to speak to a time you've screwed up. No one rational thinks we go through life with a perfect record, and no one has done it. Be honest.

Just to clarify, I do not suggest asking about mistakes a person has made. That is both a hint that I'm looking for a flattering narrative and not quite true. I'm looking for someone who can think back and identify the things he/she was wrong about. What were the false assumptions, how did those come to light, how would you solve a similar problem differently after that experience, etc.

In other words, is the candidate someone who has a rational meta-process going on about his/her decisions and is able to refine his/her approach based on learnings. I'm ideally looking for small things that show clear evidence of that kind of thought process.

As for body language, I agree, and I think my choice of the term "poker face" was a bad way of describing a certain kind of evasiveness which can indicate bad motives or bad people skills, either of which can make the person a bad hire.

> I think my choice of the term "poker face" was a bad way of describing a certain kind of evasiveness which can indicate bad motives or bad people skills, either of which can make the person a bad hire.

As a practical matter, how do you detect this kind of "evasiveness", and differentiate it from (say) plain old introversion or nervousness?

Good point. I certainly require more than a few moments where I sense it before I feel confident in considering someone's behavior evasive.

Suppose you're having a conversation with someone and in 15 minutes one of you chosen at random is going to have to trust the other with his/her life. What kinds of signals indicate that the person is trustworthy, understands the potential future, and is accurately representing him/herself?

There are some people where I never feel the kind of connection I'd want to feel in that scenario, and others where I feel it fairly early on in the interaction. Just a kind of straightforwardness, not extraversion or social comfort.

Seems like an easy way to end up picking a lot of people like yourself. After all, it's a lot easier to feel connected to someone like yourself.

> people like yourself

That is certainly a risk with any notion of "culture fit", but any time someone who cares about culture is interviewing someone that fit is being evaluated to some extent.