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.
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.
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.
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'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.
* 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.
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.
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.
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.
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.
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.
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.
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]
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 ?
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.
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.
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."
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.
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.
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.
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.
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
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.
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.
Thanks for the tip. I hadn't seen this video before.
I definitely enjoy seeing Malcom's father give advice, or is it a drug lord giving advice... hmm...
It looks like today you are one of the 10.000 people learning about this strip ;)
Because you like to eat food every day?
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.
I suspect the disconnect is a lot of people who say "eat food" really mean "drive a $60,000 car."
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.
If you're a programmer you need to "portray" your programming skill.
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.
> 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.
"Aggressive micro-expressions" sounds aggressively silly.
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.
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.
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. :)
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").
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.
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."
From my perspective, the founders blew the interview, not the interviewee. Then again, no one ever complains about the interview process on HN...
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 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.
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.
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.
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!
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.
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.
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.
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?"
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."
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.
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.
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.
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.
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.
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.
Sounds like the writer was qualified. How many good hires are lost because they have only a single interview and there is a misunderstanding?
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.
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
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.
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.
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?
"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.
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.