Hacker News new | past | comments | ask | show | jobs | submit login
What I Learned From Blowing An Interview (braythwayt.com)
131 points by braythwayt on Nov 24, 2015 | hide | past | favorite | 120 comments



Everything you do in an interview will be judged. Some people will give you an incomplete problem spec and mark you down if you don't ask questions. Some will give you the same problem spec, but feel that you were too hesitant to "just get started" if you ask questions. There is a guessing game going on in an interview, and while it's not 'just chance' to do well vs poorly, there is an element of chance involved.

Since there is this element of chance, a 'blown interview' is certainly worth evaluating, but also not necessarily worth completely changing your process. You may have just had a bad matchup of expectations.


Exactly. There's no game you can play that'll win every scenario because you can't possibly know how the person on the other side of the table will be judging you.

I made this realization a while back and decided to make two changes to how I approached interviews:

- Be myself. This sounds simple but it's harder than one would think. Most people are trained to put on faces and airs in these situations, most guides will tell you how to act, dress, etc. Ignore all that. If they don't like the real you they're not going to like you long term. There are some people who will ding you for not acting all prim and proper in an interview situation, but do you want to work with them?

- Flip my mentality around. They're the ones that need the selling, not me. This ties together with the first point but it is a key mentality change. It's easier to just be yourself and stay calm if you can think about the interview in terms of you interviewing them.


That's one way to deal with it, the other way is to not take it personally. It is not you who are being judged, you are merely a sales person selling your service, if the buyer ended up not buying yours, it's totally OK, you just find another buyer.

In the end, it's all about framing a situation in your own mind to make yourself comfortable with it. It is a very powerful technique to allow you perform well in stressful situations, and in a sense, keep yourself happy. It also applies to more than just interviews, but dating, social events, giving presentations, etc.


That's more or less what I was saying. I didn't mean I'm interviewing them quite literally in that I don't believe I'm above them but rather that we're on a level playing field and I have no need to be a supplicant or to put on airs. If it works it works, if it doesn't it doesn't.


>Be myself

Super important, and easier said than done. I was too much "myself" during an interview, and I ended up disparaging their choice of Visual Basic as their main language (at a trendy startup in 2015) a bit too heavily. Said I passed the interview except for that bit. Did a similar thing recently during a phone interview. Another trendy startup who acquired a legacy .NET product and were looking for engineers to "automate" it. Sorry, I'm not buying what you're selling.


I disagree that you were "too much" yourself, because if being yourself means you aren't a good fit for the company, it's better for both parties that you don't join the company. I'd argue that it just wasn't a good fit.

I've definitely faked my way through interviews in the past, basically saying what I thought they wanted to hear. However, it just leads to being unhappy on the job because presumably you aren't going to fake it your whole time working there, or, even if you are, you're at a place where you constantly disagree with everyone on the inside.


You have options:

* Stop being yourself in the interview, and then have a bad experience on the job, battling over your disagrements.

* Be yourself, and get a job that fits you.

* Change yourself, then be yourself and get a job that fits you.


If you're going to have a policy of being yourself, that needs to go with an understanding that yourself is mutable, and a policy of changing yourself to be better adapted to your environment. In this case, it's important to realize that the days when choice of programming language was very important are long past. Pay, working conditions, not having to live in a very expensive area are important. Programming language is a minor detail, not worth getting worked up about.


It depends. There are languages I have no desire to work with and others which I very much would prefer to work with. It's a factor even if it's no longer the factor.


To be fair there's nothing you can do in VB that you can't do in C# with an order of magnitude more available talent. Half my VS extensions are C#-only, to boot.


Much easier said than done. I still tend to revert back to "OMG, I'm in an interview! What do I say? What do I do?". It's a process.


It should go without saying that "be yourself" does not mean be an asshole.


In general, you are right, but in this specific case, there was something deep that I learned from the experience.

You shouldn't change everything in response to every setback. In general, that is called "oversteering." But sometimes a thing happens, and for you specifically, there is a lesson that you recognize speaks to a larger issue.


It's clear that you're a very analytical person and I can very much appreciate your analysis of the situation, but I think you've missed a more fundamental thing that went wrong with your interview. While it's absolutely true that answering questions at a different contextual level from what was expected will give a negative impression, it's also true that it's very difficult to discern what contextual level an interviewer is expecting from just the question alone and not all interviewers have the same expectations.

But what I can assure you of it that at some point when you were veering off track from what your interviewer was looking for, your interviewer was sending you signals that you ignored. They're often very subtle and usually unconscious on the part of the interviewer, but if you can attune yourself to those subtle ways in which they're reacting to you, you can then vary what you're saying (and, just as importantly, how you're saying it) to meet the interviewer's expectations.

There will be interviewers who want to hear abstract, high-level thinking like you exhibited in your interviewer. And there will be interviewers like the ones you met with that will want the opposite. There will even be interviewers like me that try to get you to do some of both and to be able to read my reactions to gauge which I'm expecting. Because for high-level engineering positions, this in itself is an invaluable skill. As a VP of Engineering, you'd need you to not only have technical chops, but also be able to read people. Whether it's a meeting with board members or knowing ahead of time that a key engineer intends to quit, reading people is an important part of the job.

Tuning your game plan going into an interview is very important, and I think this experience has helped you do that. But if you're not able to be contextually fluent, you won't be able to make the on-the-spot adjustments necessary to really nail the interviews.

Some great resources on this come from the world of poker, where reading people and concealing your own intentions is a large part of the skill involved. There's also good research from law enforcement on interrogating suspects. Both of these fields are too adversarial to be directly applicable in most situations, but they provide good examples of the kind of concrete things you look for to gauge someone's response.


This is great advice. I just went through a ton of interviews for my next job. I got phone screens on all of them, but only offers from about half. I studied one way for all of them, and there's only so much material you can prepare for.

A couple of the interviews I blew because I was completely unprepared for graph questions, since I've never used a graph in 20+ years of programming, so there's no point in faking like I knew how just to get a job. As well, one interview I was asked a very tough bit manipulation, which I completely flunked. Another interview I bombed because my interviewer didn't know C/C++, and although he said I could program in any language, it was obvious he couldn't understand what I did, and had no confidence that my solution worked, even though it did.

I did learn, however, that using C/C++ in interviews these days is problem, because most interviews now expect you to run these on the fly, or they ask questions that expect you to use built-in libraries that other languages already have. I was asked at a couple of interviews to parse a CSV file, and that was a huge problem in C/C++ that would have been handled in a single line of code with python. Lesson learned, the nature of the questions are changing and I need to adapt to it. Next time around, I will need to master python and use that.


maybe even powershell? import-csv


Right, most folks give you problems just to get you talking. The problem isn't the interview, and fixating on technical answers is missing the point. Its all a process for feeling you out, understanding where you are at in your career, and testing you as a 'fit' in their organization.


You are giving interviewers a little more credit than they deserve. It's certainly a process for "feeling you out", but not so much "understanding".


You need to interview at better places, I think :)


There's a class of interviews that are like this though. Knowing about that class is important because it's in heavy use. If it says "competency based interview" anywhere, don't do theory or generalities, prep as many specific examples as you can, and know the Situation/Task/Action/Result format.


And especially, Behavioural Interviewing:

http://www.udel.edu/CSC/pdf/behav_interview.pdf


That's really true. At the end of the day, you are being interviewed by people, and people are all different in the questions they ask and the answers they want to hear. If the author made a mistake then it might be that perhaps he wasn't watching for clues that his answers were being well received. Or perhaps just straight-up asking if his answer was what they were looking for. The interviewer may have just said "yes" to be polite, but perhaps they would have explained that they were looking for a more specific answer.

That's great that the author had a friend who was able to give him the honest scoop - most of us never have the luxury of knowing exactly why we didn't receive an offer.


> There is a guessing game going on in an interview

Or you should act how you will act on the job and let the chips fall. If you are a question-asker you gain nothing (and stand to lose quite a bit) by rushing into it because that's what your potential boss wants.


I think the best strategy is to try to emulate how you actually work as close as possible.

If in the former case a candidate were expected to get started, it's probably indicative to the culture of engineering that the behavior is valued. If they are one that likes asking questions and clarifying before working on it, and that's counted as a negative, at least they won't be in a situation where how they normally approach problems is always criticized, seen as a 'weakness' and probably brought up in reviews.


Well said.

In other words, an interviewing is not so much of an standardized test, as it is a date. Half of it depends on your interviewER. Just like a date, both of you move on if it doesn't click. There is no formula to "crack every date" and there never will be.

Prepare well, but be yourself. It's true for a date and for interviews.

[About us: http://InterviewKickstart.com]


in my experience interviewing is a game where you have to display a good measure of self confidence (but again not too much of it); I guess that too much self examination upon a failure here will work against you, as it will make you part with your remaining self confidence.

The problem is that it is very hard to appear self confident if one is looking out hard for a job for more than two weeks; Any ideas on how to manage this particular problem?

Interesting that most hiring processes do not give much weight to past working experience or good references - instead one is supposed to perform well on the detailed check list of the interviewer. What does that say about the company that is adopting such a hiring process vs one that doesn't ?


That was my take on it.


> The specific problem was that I was speaking of broad patterns and forces, when my interlocutors were asking about specific, tangible incidents and tools.

Interviewing is a two-way street. If you actually do feel that you were the ideal candidate based on what they said they were looking for, didn't they blow it as well? When you went high level, did they give any immediate feedback that indicated you were speaking at a level of abstraction above what they were looking for? If not, the failure is just as much on them.


The article makes it seem like they were asking those questions, he was just missing it.

To your blaming the interviewers, part of being VP level is being able to pick up on stuff like that. He admits he missed it. They may be concerned, as a result, that he'll "miss it" in other ways too.

Very humble article, and great lesson learned by the author.


I interview candidates a lot, and I see this pattern many times. I can't remember how aggressively those particular people followed up with me, but I can tell you that I have had conversations like this:

---

Tell me about something specific you did to improve the productivity/velocity of your colleagues.

"I'm a big believer in unit tests. When you have a lot of code coverage, other people can make changes without worrying they'll break things."

Ok, I get that, we write tests too. But what, specifically, did you do with respect to testing? And what, specifically was the result?

"Well, I write tests for all my code first. TDD leads to better designs, and that's better for everyone."

I know what TDD is, and I admire people with the discipline to practice it consistently. Now tell mw what, specifically, you did with TDD to improve the productivity of the team. Did you introduce the idea? Did you introduce some process around TDD? Did you introduce some TDD tooling?

"I use Mock Objects."


That's a great point. I think a mistake a number of interviewers make, and maybe they aren't used to the idea of interviewing for a position, is that they aren't interactive enough in their questions.

In this case, it sounds like the founders made a bit of a mistake. Even if they were able to find someone who could explain things to them more directly, like they wanted, during the interview, it doesn't mean that the candidate is more qualified for the job.

In general, communicating with management or founders won't necessarily be the same as communicating with engineers.

For me, I had an interview about a year ago with Google and they were basically so uninterested in asking questions that they didn't learn anything useful about me, so it wasn't surprising that I was rejected. Sometimes interviewers don't realize that it's a two-way street, and that they need to be just as interested in hiring a candidate as an interviewee is excited about working for them.

And I think if you're serious about hiring someone that you should be excited no matter what, especially if you know they're qualified.


When I am an interviewer, I do sometimes just shut up and see what the interviewee does answering a question. One pattern I see is that people who are uncertain (or outright lying) about something tend to keep embellishing when you give them the space to do so. You then need to circle back to see if they were nervous etc and do have a reasonable grasp, or are misrepresenting themselves (eg doesn't match the resume claims).

Doing it for everything is not useful or productive. Interviewers also need to realise they are selling the company, and while they may not hire the candidate, that candidate will have a career, colleagues, influence etc in the future. I am very wary of some companies and their products (and former employees for that matter) because of the interviewing experience.


Your question seems unexpected, and not necessarily in the charter of every programming gig. I happen to have a great answer to it, after making big improvements to build times, but that is pure chance. The comment at the top of this whole thread has the right idea: sometimes candidates randomly meet unknown expectations, and sometimes the opposite happens.


I don't think his question is unexpected at all for any kind of candidate that is going to have a leadership component. There are a hundred different answers that you can give to his initial question (how did you increase velocity of your teammates). TDD, improved requirements process, improved deployment process, improved monitoring, improved mentoring process, whatever.

I actually think this is a great way to figure out whether someone has actually done what they are talking about and done it successfully or if it's just something they have read about or halfheartedly/unsuccessfully tried to implement. It's easy to say "agile is good" or "continuous integration is good" or "TDD is good". If you're going to claim one of those things as a big accomplishment then you should be able to talk about the specifics of how you implemented it.

I don't even care if I agree with all your decisions. What I do care about is why you made your decisions. If you made some decision that caused the company to go bankrupt but at the time it was the most sensible decision then lets talk about it. If all you can say is "testing is good because it prevents bugs" then I would be concerned that you either hadn't implemented a comprehensive testing program or you didn't understand why you were making the decisions you made.


It's not a question I would ask every time, but it is one I ask sometimes. I just picked it to give an example of trying to get a specific answer but failing.

I might ask this question of an engineer who is interviewing for a lead position. These days, an answer could be as simple as, "I paired with a colleague yesterday," or, "I gave thorough feedback on a pull request."

I would then follow up with "Tell me more," and a candidate might talk about a recent PR where they pointed out a vulnerability, or an optimization opportunity, &c.


True, if real life conversations were like interview conversations, we would judge people/friends whether they gave us the answer we expected when we asked them a question or not. That's ridiculous. People misunderstand questions. If what you get is not what you expect, you can always ask clarifying questions.


I was poking around his blog. Fwiw, it appears he's well aware of this. He calls interviewers who ask vague questions and expect particular answers "Carnac the Magnificent" [0].

[0] http://raganwald.com/2015/05/08/carnac-the-magnificent.html


I saw this video where Bryan Cranston gives advice to young actors. He basically says, don't go into an audition 'looking' for a job, or 'wanting' a job. Go in, do your thing, portray the best you and get out. If they want you, you'll get the job, If they don't ... why would you want to work at a place where they don't want you ?

This was eye opening for me. Totally changed the way I went to interviews.

(Can't find the video now :( )


  > portray the best you and get out
Very true. But I contend that I did not portray the best me. And that is a valuable lesson. This essay is not about the job I didn't get, it's about the lesson I learned about myself.


Can you be sure you would have been given the job if you had portrayed your best you?

It's possible you simply dodged a bullet. Maybe this company misclassified a valuable resource, and (for all anyone knows) hired someone less able instead.

Given your practical background, why did no one ask for practical examples?

I agree with the general point - interviews are really about proving you can save time and make money, and everything else is a warm-up.

But still - the hiring process is notoriously unreliable, and it's going to be interesting to see where this start-up is a few years from now.


This was more than ten years ago.

I'd like to point out that they did ask specific questions, I was just enamored of generalizing at that point in my life, and treated every specific question as an invitation to generalize.


"Bryan Cranston's Advice to Aspiring Actors"

https://www.youtube.com/watch?v=v1WiCGq-PcY

Thanks for the tip. I hadn't seen this video before.


Statistically, regardless of what the video is, most people haven't seen it. I always find it fun when someone is surprised someone else hasn't seen a specific movie or a popular video on youtube. I believe we're well past the point where even if you wanted to spend 24/7 watching videos, you couldn't possibly see everything that exists. Kind of out of the scope of this topic, but just a fun point to make.

I definitely enjoy seeing Malcom's father give advice, or is it a drug lord giving advice... hmm...


I was merely noting that I hadn't seen it before. As I'm a fan of Bryan Cranston and my daughter is an aspiring actor, I had at least two interests that might have led to me stumbling across it. But no, instead it comes to my attention via HN. This perhaps argues for the relatively good S/N quality of HN. Unlike this comment. :-)


I immediately recalled this:

https://xkcd.com/1053/

It looks like today you are one of the 10.000 people learning about this strip ;)


How needlessly pedantic.


Agreed. My bad, probably didn't help. Was in a mood of sharing.


>why would you want to work at a place where they don't want you ? //

Because you like to eat food every day?


If you're going for professional level work then you certainly should care whether they want you there, or more importantly, if you are providing any value to the company. Because if the answer to either of those is "no" then you probably won't go far in the company anyway and so you're wasting your own time.

If all you care about is eating then there's plenty of jobs where you can punch the clock, do your time and get the hell out of there.


Anyone can find a job to survive, even in the depths of a horrible recession.

I suspect the disconnect is a lot of people who say "eat food" really mean "drive a $60,000 car."


Anyone? I think you're deceiving yourself there. My point was really that the comment was clearly from a privileged perspective - not everyone out of work is just lazy.

Working in a job that's not a perfect fit is a small step down the scale of compromising one's career out of necessity. Next step would probably be working on a different industry. Then there is a lot further to go before your cleaning up other people's mess or faeces, scrubbing abattoir floors, or what-have-you.

Agreed on your second sentence, but that's a valid choice.


I "portrayed" so hard that I was let go 3 months after starting because they thought I was much much better than I actually was. They judged me on my theoretical knowledge not my applied knowledge. Oh well at least I know I can talk the talk, just need to learn the stuff for real now.


The actor acts, that's his portraying. He's not saying fake it till you make it.

If you're a programmer you need to "portray" your programming skill.


Honestly, this article is a bit hyperbolic. He didn't blow the interview - I was expecting an article on being totally unprepared, not able to answer a single question. What happened was he aced the technical portion, and went too theoretical / abstract when they wanted things that were concrete / applicable. That's not blowing it - that's a lack of recent interview experience, and is something he will easily fix and correct in the next interviews. But it was refreshing to see that he received actionable feedback from the interviewers, rather than the straight "sorry we can't move forward" boilerplate that usually has to happen.


This was much more fundamental than just not answering questions properly. I realized that I was not thinking clearly about the difference between specifics and generalities, and not communicating properly, in all sorts of conversations, not just when I was being interviewed.

For example, I was also interviewing people, having one-on-ones with reports, and so forth. I think this particular interview was a catalyst for rethinking the way I approached communication in general.


Totally agreed.

> Failing so spectacularly in an interview shook me to my core.

He didn't fail spectacularly, he just didn't get the job. He's lucky he got actionable feedback from a friend to improve. Most bigger companies won't give a reason for a rejection nowadays for legal reasons.

I, however, have truly failed spectacularly in an interview. While it temporarily killed my confidence, it did make me a better interviewee in the long run. I learned the concepts that stumped me in the interview, and I had a little less fear in the next interview since it couldn't get worse.


Perhaps instead of "failed spectacularly," I "snatched defeat from the jaws of victory."


That seems like an incredibly accurate description about what happened to you.


I had the weirdest let-down after an interview this summer. Like the author I thought it had gone fine but something entirely else was going on. The interviewer let me know the reason I was not chosen was that I used agressive micro-expressions and lacked diplomacy. I don't know if my love for technical excellence (a topic broached quite fully during the interview) or my anecdote of an anti-pattern at a previous employer was really presented with toxicity but my takeaway is that sometimes you have just been set up for failure and nothing can be done to salvage your chances.


You dodged a bullet. Any interviewer who judges you based on "micro-expressions" would have been insufferable as a manager.


What are "agressive micro-expressions" ?


Keeping your arms crossed, moving your head back from the conversation, tensing of the body, etc.


If that's what I were worried about then I think I'd just leave it at, "we didn't feel like our personalities meshed well" or "we don't think you are a culture fit" and leave it at that.

"Aggressive micro-expressions" sounds aggressively silly.


They could also be signs of a defensive response on the part of the interviewee, who may be nervous. It is also a typical response of any person trying to maintain their sense of personal space.


So, being nervous?


In other words, nervousness.


>The interviewer let me know the reason

I've never had a single potential employer do this, to avoid liability, I suppose.

To this day I have no idea why I didn't get the job at any of my failed interviews.


I've noticed I'll get more feedback when there's a recruiter between me and the employer. But yes, it's quite frustrating when all you get is "not a good fit" when as far as you can tell the interview went well. Was it a technical problem, or a personality issue, or what?

If it's any consolation, I know exactly why I didn't get the position at a few interviews, and it's because it went poorly - they wanted experience with X and didn't feel Y was a good substitute, or I didn't solve the brainteaser, or other obvious issues.


I interviews around a bit this summer. I found one position that, on paper, I was the perfect candidate. I ticked every checkbox the hiring manager mentioned. I met with the hiring manager first, and she loved me and by the end of the meeting was insisting that I come into the office for an onsite with her team. A few days later, I went into the onsite and nailed it. I mean, there were zero indications that I had flopped. By the end of the day, the hiring manager came in, smiling and asked me the good stuff about salary expectations, when i could start, etc. All good responses.

Then she said that since this is a senior position, we'd have to run it by the CTO, who was based across the country. They decided to do a Skype interview. As soon as the screen came up, I got a sinking feeling in my stomach. The CTO was relatively hostile and didn't smile throughout the whole session, even when I cracked a joke that never fails to get a response. By the end, she gave a terse "Thanks for your time" and that was it.

I didn't get the job.

But this is one of those things where I really believe I put my best foot forward, and I really believe that I was a great fit for that job, and I really believe that there was some other factor completely, 100% beyond my control that caused me not to get the job. Maybe she already had someone in mind. Maybe she was having a bad day. Maybe I had something stuck in my teeth, or maybe someone close to her died. Who knows?

I'm still really bummed I didn't get that job, but at the end of the day, it is what it is, and I have to move forward.

Good luck with your next interview, OP. It'll work out eventually. :)


Having sat in on a fair number of interviews, there's a lot churning under the surface, particularly at smaller shops, and I'd strongly agree that factors beyond your control are a big deal.

One thing I like to do is look at trajectories of companies I had interesting interviews at. It's always enjoyable seeing what I didn't land in (sometimes good, sometimes bad, but always an interesting perspective, since I had a fleeting glimpse into the "inside").


What's the joke?


So this dyslexic guy walks into a bra...

No, really, it wasn't really a joke, but more of a funny story that almost everyone laughs at... except this particular CTO. Sigh. I'd explain it here, but there's some backstory that is required for the story to be funny, and the backstory is a project that I worked on for a few years. They always want to know more about that project, so by the time I'm wrapping up the short explanation, they have enough information to understand why this one thing is funny.

In retrospect, maybe that suggests that she wasn't really paying attention. Maybe I just didn't notice. Hmm.


Reg doesn't go into exactly when this interview occurred, but I have to imagine it was quite a few years ago. The conversation today should go something more like:

Interviewer 1: "So, Reginald, how many years of Angular Bootstrap Scrum experience do you have?"

Interviewer 2: "Fuck off, this is raganwald. You're hired."


This is from when I knew both programming languages: C++ and Java.


Sounds like a bad interview process to me. Crushed the technical interview, had a glowing recommendation, and "blew" the interview on the whim of a founder- for talking about root principles no less. And instead of pulling you back to specifics (ie. leading you to answer the things they're interested in), the founder dismisses you for failing their totally hidden criteria.

From my perspective, the founders blew the interview, not the interviewee. Then again, no one ever complains about the interview process on HN...


This definitely resonates with me as someone occasionally involved in the interview process from the other side. In my experience the scariest bits of "hidden criteria" are brought up under the umbrella of culture fit. Candidates are posed a minefield of completely non-technical-related open-ended questions, with the consequence that the interviewer is free to draw practically any conclusions they want about the candidate's personality and compatibility with the company. These lines of questioning are impressive to recount, as if the interviewer is a clairvoyant with exceptional powers of insight into the candidate's soul. However, I'm skeptical that this process is any better than random at selecting people who would turn out to be valued, effective engineers. It seems to me that, unless there are glaring issues with arrogance/stubbornness/misanthropy, technical chops and engineering skill are what you should optimize for, not personality.

I've heard of "objective" interviews based on a rubric with a set number of points for each question and little room for interpretation. I wonder how that works out. I feel like even if it's pretty bad, the interview is so completely terrible and broken right now that it might be an improvement.


I've just blown a technical interview. Not like this though.

I've got lots of experience, know my languages inside out and have several launched products to millions of people. I did every problem in the recommended book (CtCI) and know data structures and algorithms well. I wasn’t prepared for the nerves though.

I interviewed at a large social network recently. 3 out of the 5 onsites went amazingly well. 1 was okay and the last one totally tanked. It wasn’t a particularly hard question, but I didn’t crack it immediately so started to panic.

What made it 10x worse was that the interviewer sat in complete silence, not responding to any of my ideas. I followed all the recommended strategies: Throwing out a brute force solution, discussing what you are thinking (incidentally, I said the correct solution very early on!), trying different data structures - but he said nothing and checked his phone.

When I got the call, I was absolutely devastated. I had put 3 months of preparation into this and it was all gone in 30 minutes. The recruiter couldn’t believe it as he thought I was a shoe-in. I told him about the interviewer and he was furious. He said he would pass that on as feedback, but there was nothing he could do - they have to respect the process.

I appreciate the humility in this article. As much as I want to blame the interviewer, the process, how technical interviews are broken, how that company isn’t all that, etc etc - the most fruitful thing I can do is learn what went wrong and how I can overcome it next time.

In repairing my shattered self confidence, I’ve found this very helpful:

“Doing poorly on your Google interview could mean a couple things, if you're a good engineer….Which of the two evaluations is more meaningful? A) A few hours with busy people who don't know you trying to guess how good you are, with only a few minutes of a problem they're familiar with as a probe. B) Years of successful performance in your career.

https://www.quora.com/I-felt-I-was-a-pretty-good-software-en...


but he said nothing and checked his phone

I realize that it's easy for me to say this, and I sympathize with your nervousness at the time. But this is an opportunity for you to ask both the immediate interviewer and his superior (assuming he will also interview you) just how serious they are about finding a candidate if they can't even extend basic courtesy to the people they invite in.

Hell, if his manager was going to interview me, I'd have use that opportunity to ask if that was the kind of environment I would be in working for them and exactly what drove the last person in the open position to leave.

There is no excuse for that kind of rudeness. Use it to your advantage.


I wish more people had the guts to follow this advice. I agree, this type of disrespect would have totally turned me off and made me seriously contemplate even wanting the job.


Yes, this is definitely something I've learned and would do differently next time.

Saying that, I wouldn't judge a huge, successful company on one jerk. As much as I want to say "Fine, I don't want to work with people like that anyway" I know that interviews are (often) a poor reflection of overall culture.

What's frustrating to me is that this guy was an anomaly (according to the recruiter) but I have no recourse. The power lies with them and what do they care if they miss out on one good person? There are 20 more people waiting behind me.


I wouldn't judge a huge, successful company on one jerk

That's why you discuss it with his manager or HR. First, unless the company is totally borked, they will understand how people react to that behavior. It's not about getting him in trouble: it's an opportunity for you to see how they react when they receive valid criticism. And a chance for them to correct a problem.

There are 20 more people waiting behind me.

Yeah, but you're better than all of them combined. Think positive!


You've been very encouraging. Thank you!


It's worth remembering that studies have shown the hire/no hire decision has in most cases been made no later than ten seconds after you walk into the room, and your experience confirms that. So:

1. Don't fret too much about how you answer some arcane technical question. That's probably not going to be the deciding factor.

2. Research ways to give a good first impression.

3. Practice not visibly stumbling or looking nervous during the interview.

4. Accept that sometimes the decision will have been made before you show up for reasons that have nothing to do with you (e.g. your competitor will get the job because his dad called in a favor or suchlike).

5. When it becomes clear that a no-hire decision has been made, call a halt early - it's perfectly okay to say halfway through the interview, "But I think you've already made your decision, so let's call it here." It won't make a difference to the outcome this time, but it will protect your self-esteem and thereby improve your performance in future interviews.


I'd like to see these studies and how, if at all, they relate to the technical interview process. I would strongly guess "not at all."

Technical interviews are in fact technical. There is zero technical evaluation that happens in the first 10 seconds.

As for your specific points: 1. Yes, in fact, how you answer the technical questions will very likely be the deciding factor. That almost always was when I was doing technical interviews and on Google's hiring committee. 2. First impressions really don't matter that much for a technical interview... unless you're talking about the first 5 - 10 minutes of the technical portion. 3. For technical interviews, looking nervous doesn't really get people rejected -- at least not at companies like Google and Facebook. It could, however, make an interviewer more forgiving. 4. When candidates get rejected for coding roles companies like Google and Facebook, it's almost always due to their interview performance. It would be very unusual to get rejected because someone else outperformed you. They don't evaluate interviews that way. 5. Absolutely do not call off an interview part way through because you assume that the person is going to reject you. You don't know that at all. People's perception of their performance during a technical interview has no correlation with how they actually did. If you call off the interview because you assume you're doing poorly, this might just be your best interview.

Also, a single anecdote does not confirm a theory. It can align with a theory.


Thanks Gayle. And thanks also for the huge amount of detail and care in your book. It is meticulous and brilliant.

What would you advise for the situation above? The rejection was certainly as a result of my actual coding performance, but I felt like the interviewer played a significant part. The company (strongly) encourages use of your book so I presumed the interviewer would encourage dialogue, give suggestions, give feedback, etc. He gave me a Leetcode question, answered my first question with a smirk ("what output format did he want from the function"), and sat in silence while I threw out ever suggestion I could think of.

Am I just deceiving myself? Do other people push through that awkwardness and disdain?

Anyway - thanks again. I appreciate your book and advice.


If what you say is the case at Google and Facebook, then that's great news, and doubtless a significant contributing factor to the unusual success of these companies! In that case, perhaps one could add 6. The extent to which an interview actually assesses your technical competence rather than just the feelings of the interviewer may greatly vary between companies.


Can you please provide some links to one or more of these studies?


'I contacted my friend. What went wrong? He sighed. “The founders thought you were too theoretical. They got the sense you would be a great coach or evangelist, but lacked the hands-on attitude they were looking for to actually build a team up.”'

They may have been looking for one specific response (and yes, if so they should have directly asked) such as "do you have experience hiring?"


One of my favorite things about how companies interview is how they assume their own competence in actually assessing people at a level that is woefully out of line with reality.

For example. "We ask puzzle questions because it helps us figure out how a candidate problem solves."

No it doesn't, and not because puzzles are a bad way to assess problem solving, but because you as the interviewer have basically no idea what you're doing when performing the assessment.

Typically the interviewer has no clear idea what profile of person they actually need to hire for a given type of job function. Even in the rare case they do have that necessary understanding, they almost certainly have zero training in how to create or identify puzzles that actually align with the kinds of problem solving that match the profile they're looking for. The interviewer will have zero training on what to observe about how the person solves problems and what the signals actually mean. They'll instead almost certainly pick up all the wrong signals and miss all the important ones and interpret the ones they picked up in the wrong way.

Usually people tell me they ask certain kinds of puzzle or programming questions because they want to see how the person solves problems, collaborates, communicates, etc. As a quick litmus test I always respond, "When you ask these puzzle questions to your candidates do you already know the answers?" 100% of the time, "Yes, of course." To which I say, "If you already know the answer, you're unable to remove your bias from the way of coming to the solution, and you're learning absolutely nothing about how they communicate or collaborate. Next time ask them a puzzle you don't know the answer to and work on the solution together. Then you'll have half a chance at learning something valuable about the candidate."


I don't think you should read into it so much to be honest. Everyone looks for different things when giving interviews. You can't please everyone.

Also, you say things like "When being interviewed, we must make sure that when asked to speak in specifics, we answer in specifics"...the interviewer should be nudging you in the right direction if you're veering off track. If they don't and judge you for it, they're not doing their part in my opinion.


Did no one else catch the irony that the entire post is itself a generalization based on a specific experience?


I wrote an essay describing a general principle, using a specific example from my experience, and closing with specific strategies to employ.


Not a criticism – I enjoyed the piece! Indeed, since you were not asked for a specific example, and after all it is your own blog, you are free to share a generalization without violating anyone's expectations.


s/irony/genius


That company appears to be pretty bad at hiring executive technical management.


I thought this was a very insightful article. I had always thought that for those upper-level positions, you would necessarily be talking more about philosophy and mindset than about specific instances. The idea being that you wouldn't be there if your fundamentals didn't stack up.

A lot of advice gets bandied about regarding interviews, and worse, a lot of people seem to think it's just a random walk, but really an interview is nothing more than a specific instance of exercising persuasion. Maybe you're successful, maybe you're not, but there's reasons why in either case. Coming to an understanding of all the angles is precisely the benefit of experience. Articles like this help me to understand what the game looks like.


I went through all five stages of grief in one conversation: Anger, Denial, Bargaining, Depression, and finally, Acceptance. I blew it. Okay, I had lost this chance. But what could I learn for the next time?

Why have we (as candidates) allowed ourself to become so brow-beaten over the years as to nearly always conclude that if an employer fails to read us, that it's automatically because of something we did to "blow it"? That we're the ones who need to pick ourselves up, dust ourselves of, and wallow through a necessary period of mourning and self-reflection before promising ourselves to do better next time?

Long, painful lesson learned: it's a two-way street. The interviewers', and the company's overall performance in the process is just as much open to evaluation -- and question -- as that of the candidate. And guess what -- they're just as likely to make mistakes as the candidate; perhaps even more so -- because they've internalized the idea that as the one on the hiring side, they're the ones with X-ray vision to what determines a "perfect fit"; so that if turns out the candidate doesn't hit all the markers they're looking for, then by definition, it's because something the candidate did to screw everything up.

In this case, it looks like it may have been the company which "blew it" in passing on this guy. Or maybe not -- we have no way of telling from this distance, and it would be moot to speculate. But I would like to hope that we can get past this tendency to automatically beat ourselves

As an aside -- aren't logic problems "over" now, for any but junior positions? Even for senior developers I'd consider them something of a red flag -- a sign that the company doesn't really know why it's doing what it's doing in the hiring process, and is cut-and-pasting from what it thinks other companies are doing.

And at the VP level? Reason enough to look the interviewer in the eye, explain (nicely) that you don't think these questions are a good use of their time or yours -- then to thank them for the opportunity, and walk out the door.


This was approximately fifteen years ago. And it wasn't just any old interview, it was for a company where a friend worked.

I wanted to work with my friend, I wanted to work on the problem they were solving. I was so excited about the opportunity that I was actually considering moving from Toronto to California just to work there.

But yeah, we should not normally be this invested in the outcome of a job interview.


There's a good chance that the same interview (same questions and answers) with another company would pass and be a 'great fit', since they were looking for different things etc, there's always the lottery aspect.


There is plenty of evidence that people make up their minds in 10 seconds and the rest is post-hoc justification. You didn't blow it, they just didn't like you, or already had someone else in mind.


> When talking with others, be aware of when they want to understand the specifics, and when they want to understand the general ideas.

I think this might be the wrong takeaway. In reality when people say they want specific examples then they want specific examples, and when they say they want general principles they also want specific examples.

If they ask for a general principle then maybe throw that in as the last sentence, but most people people simply aren't able to process abstract ideas, even if they think they're able to.


You should consider yourself lucky that you had a way to get actual feedback through a side channel. At most tech companies in the Bay Area, you only know it's a "NO" when you don't hear a word back from them after a few weeks. Rarely, you'll get a generic "Sorry, but your skills are not a match for our position at this time" form E-mail, which although nice, is not really helpful. Good, actionable feedback is very valuable, especially in today's lukewarm job market.


Speaking as one person who has been interviewing developers (and others) for 20 years, getting to specifics is something I try to do in every interview.

It's just not that difficult to B.S. your way through an interview with great-sounding generalities even when you don't know how to actually do anything (think FizzBuzz). It's also an actual problem in real life that some people would rather live in the abstract and never want get into the details of actually getting work done.

The only way I know to clarify that in an interview is to drill way deep into the specifics of something you've done. If you actually did the work, and knew what you were doing, then that'll be pretty obvious -- and you can certainly motivate the specifics with principles as you go.

However, quite often I have to really push to get the specifics even if they are there. People don't expect that I want to be bored with details, or something. So I've learned to be very explicit that I want boring details, lots of them. It sounds like the interviewers in this case didn't do that, whether deliberately or not.


So lucky to get some feedback. I've been on several interviews this year for positions I was well qualified but didn't get. I've gotten zero feedback.

Sounds like the writer was qualified. How many good hires are lost because they have only a single interview and there is a misunderstanding?


I don't know, it sounds more like the interviewers didn't know how to actually interview someone properly. If they have questions they want specifically answered, they should ask them, not just sit around like a meek wallflower.

It could be that the OP just prattled on and on, and bored each of his interviewers and went off topic. If that's the case, then it makes sense, because we've all worked with people like that. But if the OP is actually a great candidate, and the interviewers passed on them because the interviewers didn't lead the discussion in the way they wanted, that's their fault, not his.


Like raising money, you should trust the "No", but not the "Why". There are so many factors that comes into hiring, most of them totally unrelated to you or your performance during the interview.


You can't win them all. In another interview the same behaviour the author exhibited in the article could be seen in a positive light "he always sees the big picture not the specific tools, which implies deeper knowledge"

If the interview answer is going off track, it's the interviewers prerogative to ask for more specifics and clarification, if that's what they want to learn about the candidate

I think you have to be very aware as both an interviewer and interviewee of assumptions you're making about a person and dig deeper to ensure you are right


Great post. I've seen feedback from hundreds and hundreds of interviews, both technical and non, and by far the most common reason for rejecting someone is they did not answer the interviewer's question directly.

Speaking in specifics is important, but more broadly, you didn't do well because you didn't actually answer the question asked. People often get tripped up in their explaination of the answer, or their theory or thinking behind it and just forget to say what they actually did.


@braythwayt, if you don't mind answering, when was the interview? and did your current employer know you were interviewing?


It was around the turn of the century.

I'd prefer not to talk too much about what was going on at my employer-of-the-time. Let's just say that I've maintained a good relationship with my colleagues and managers from that company over the intervening years.


Thank you for the candid response.


It's funny that the behavior that caused the author to blow the interview is also perfectly demonstrated in the article. The author moves from a specific issue (not correctly anticipating what the the interviewer wants to hear) to generalizing in a much broader context ;)


...But then returned to specifics at the end.

:-)


One weird thing I notice is how people say "countries such as Spain and Greece" when they actually mean "Spain and Greece".

Do they feel like speaking in generalities is more prestigious? Is it as a hedge in case there are more examples they don't know about?


I notice that a lot in political debates.

"Socialism is working very well in countries such as Sweden, for example."

I think it's usually an attempt to infer that there are many more similar situations.


"Countries such as Spain and Greece" sounds like it may include Italy. Now I'm curious what properties Spain and Greece have that Italy doesn't.


Journalists call them PIIGS now, which some find objectionable. Portugal, Italy, Ireland, Greece, Spain.


That's another failing of tech interviews, you normally get only one chance to perform.

It is a bit like having one chance to write a correct program, without possibility of iteration/debugging. How often will this produce a correct result? Rarely.


I am more impressed with your project management experience with agile. Did you follow agile process strictly in that company? I love to hear your experience and can be new blog post.


really learnt a lot from reading this. Thanks for sharing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: