I found myself interviewing with a hedge fund last year because they liked some of my open source stuff (and approach to API design)...

I had about six conversations with a bunch of the team and a conversation with the CEO to sell me on the position. The last step was a seventh “conversation” with the Chief Data Officer to figure out if this was something I really wanted.

The CDO had different ideas… he joined the Zoom, started sharing his screen (with no introductions), opened a Google Doc and told me we were going “write some code together”.

I was pretty confused and flustered but tried to roll with it. He first asked me to “reverse a string”. OK. My lil Python snippet was fine but he didn’t like that it wasn’t “the most memory efficient way to do it”. He then asked me to write a function to approximate “e”. I just ended the interview right there.

I came into this thread to comment about a similar experience. Had a call set up with the company founder for a consulting role, for me generally this means an informal chat where they share the pains they're experiencing, I share my background and thoughts related to fixing those kind of pains and, if we both determine we can see it working, I put together a proposal.

However, instead of the founder, an engineer ambushes me in the zoom call and starts a full on technical interview. In retrospect I should have ended the call there and then but I had already committed the time and it was only 30 minutes so I did my worst technical interview ever.

I'm still annoyed at their behavior, the company ended up folding so that's the silver lining.

I had a small consulting firm for a few years, and spent a few years as a solo consultant as well... what you describe is probably above all else what drove me away from that business model. Often I would walk in as "the sales guy" and they would want to turn it into a full blown technical interview. Disrespectful and a waste of everyone's time.

Isn't it just great? In my experience it's often the in-house technical team that ends up being overprotective about their turf.

And I kinda get it, I've been in-house tech leadership for companies where consultants have been pushed on me because they're someone's cousin or because they're a big company and therefore immediately trusted. But it can be frustrating...

I’m sorry that happened to you. Do you think that the engineer that ambushed you felt threatened by your candidacy? I’ve been around a bunch of engineers who hate hiring to “raise the bar”…

It's possible, I have also seen that, especially in small companies where everyone is very protective of their turf. I also had a terrible interview experience years after that where I was being interviewed for a CTO position by the company COO and the CTO that was leaving.

The CTO was really harsh in the interview, he gave me a bunch of brain teaser questions, followed by some algorithms questions where he was expecting one correct answer and would interrupt me if I was going a different way. We barely had any of what I would expect would be proper questions for a CTO interview (eg stakeholder management, people management, technical architecture)

It was so bad that the COO sent me a personal note apologising after the interview, but said that they had to go with the CTOs judgement on who was better qualified to succeed him. That was a pretty surreal experience and I think it was because the CTO already had someone in mind to replace him.

That’s not bombing the interview in my book, that’s just being thrown in front of a bus. Seems like they have terrible hiring practices.

The whole process was pretty informal as I never actually applied (they reached out because of my code!)

I’ll never know exactly what happened, but it I had to guess I think the CDO felt undermined by the “rogue” employees who sourced me as a candidate and pushed me through the process without his consultation…

Still sounds like a terrible hiring practice. You can have an informal hiring but still do it proper; at least make sure all the stakeholders are aligned.

Probably bullet dodged

presumably regarding the string reversing: they probably wanted a reverse in place (then making sure you handle the even/odd edge condition). however, Python strings are immutable, so you'd have to use a bytearray, but if you have a huge string, converting it to a bytearray, reversing the array, and converting back to a string would likely take longer than having python's string reverse function allocate a new string and write the reverse into it (I would have written both implementations, a timer, and test with increasingly long strings, assuming coderpad).

For the 'e' question: I mean, we learned functions to approximate e in high school. There's a summing series you can do to approximate it- were they expecting you to remember that off the top of your head (if so, you probably dodged a bullet). Otherwise, e*x is its own differential, so i wonder if you could write some terrible routine iterating from a random value to the right one by computing finite differences of various values.

If I remember correctly e can be defined as the limit of (1+(1/X)^x as x approaches infinity, so could simply plug in a very large x to approximate. Super simple, but something you have to know, and not very useful in the typical se job. these kind of trivia maths questions are really obnoxious.

It's a rather stupid question because there are plenty of libraries that can do it better than you could come up with. It's the kind of thing that if I saw a developer wasting their time with at my company, I would immediately fire them, it's akin to rolling your own cryptography.

That series is the definition of the exponential function, literally high-school math.

As I said depends on the role. Normal SWE? Sure, it's trivia and a rather stupid question. For a more science-y or finance role, I'd be very concerned if the candidate doesn't know it.

What about a finance role requires one to know how to inefficiently produce approximations of known constants?

The real question is what else you don't know if you don't even know that...

The power series definition of the exponential function is basic mathematics, and is widely used in financial modeling. This cowboy attitude towards math is just depressing.

An alternative closely related interview question that's a favorite of mine is "please compute the monthly payment for a $200,000 mortgage over 20 years at 3% yearly interest".

You shouldn't be allowed to graduate high school without knowing how to do that, and you'd be surprised how many self-described economists can't answer it.

But the farther from high school the less likely to remember.

Yes I did that in my C++ class in high school. But no I couldn’t do it now and end up with the right answer without some review. I’ve spent a decade and a half doing other things that should matter more than sword drills.

jesus christ, similar experience.

this kid wanted me to sort an array without using array.sort method in js.

that was the most stupid thing i was asked to do in my life, i had to end the interview.

i went as far as telling the founders they made bad hires. other red flags was overengineered web app, too buggy, no seo, no ogp, shit in mobile responsiveness.

their startup was defunct within 6 months, no wonder.

What is your approach to API design?

I'm curious to how you ended the interview

I have so many stories that I bombed the interviews, but this is probably the most interesting one.

In 2008 I was searching for my first full time job. At the time a social network company flew me out to SF from Toronto for interview. I was promised a 5-hour block but only lasted 3 hours before they walked me out. I don't remember the questions, but I do remember that the VP of Engineering at the time was browsing his BlackBerry and weren't listening to me. Needless to say, I felt humiliated for awhile after that experience.

Fast forward to 2018, I interviewed at this startup in SF and I did well in the first 2 sessions. The 3rd session was the CTO and he was the same person that ignored me 10 years prior. This time I did well enough that he immediately got the CEO to meet with me and offer me the job on the spot. I thanked them and ended up not taking that job due to a better opportunity elsewhere.

The CTO didn't remember me nor I confronted him about it, but it's a small win in my book.

Wow! It's amazing how much stuff can come back around in the tech world... A nice reminder to not burn bridges :) Thanks for sharing!

Worst interviews are ambushes. Things are going fine, you're discussing tech stuff, guy decides you need to "code" right now in an alien coding environment.

First time, guy asks me how I'd do some problem, I talk him through it, I mention there's an easy O(n^2) way but with a bit of thinking there's probably an nlogn way. He doesn't want to let me think for half a minute, just rushes me into the inefficient solution. So I do that, and at the end it's "oh I think there's a better way".

Second time I've been through a bunch of rounds, 3rd party recruiter calls me to ask to go into the office to meet the boss, to discuss terms and numbers. I get there, he wants to code some BS algorithm on a piece of paper. I do the whole thing, he finds a bug. Won't tell me what it is. As far as I can tell, he isn't a compiler. So I search around a bit, find the bug, whatever, I don't get why he can't just let it go when we've talked through the algo. So we go on, second problem, I nail it again. Again there's some bug. I tell him listen, if this wasn't on a damn piece of paper in crappy handwriting, it wouldn't be a problem. Why are you trying to hire a head of trading technology using a piece of paper and a pen?

Didn't get the job, funnily enough.

>Worst interviews are ambushes.

That's a great description that hiring managers / HR / people who design and conduct interviews should contemplate. Are we ambushing candidates or are we seeking to understand their strengths and weaknesses?

I don't know why you'd ever do an ambush interview for a developer position. Programming is very much a 'think and plan' type of activity.

Actually, I wonder if the prevalence has anything to do with the fact that an ambush interview style has certain advantages if you're hiring an HR person and therefore the people designing interview norms think it's a good idea?

(I can see this style having some utility for positions where the candidate has to deal with high-stakes social situations with very little prep, like HR or PR. "Prove your ability to calmly handle the unexpected and reorient.")

I'm shocked at how many of the responses here describe ambush interviews, I did not know this was a thing! Thanks for sharing :)

1. I froze during a whiteboard interview where I was asked to pretty print a tree in front of two people. Performance anxiety made me implode and stumble so much that I failed to implement basic recursion :')

2. I froze again during a live coding interview when I was asked to correct code under test for a coin change problem. I couldn't get over the fact that someone was judging me based on what they were seeing live and I messed it up so badly that I told them I'm not good at live coding and left it at that >_<

FFS after ~15 years in the field having worked on firmware all the way up the stack one would think I'd be great at throwing out solutions to trivial problems off the top of my head...nope not my brain :D

I've found for myself that there's a massive difference in how someone approaches live coding. If it's a colleague or even my entire team I know that we are doing this together because we have a common goal and will support each other...unlike in an interview where it's set up to be antagonistic and that throws me off completely.

To be fair, I've forgotten how to do basic recursion (and a lot of other basic stuff) while coding with no one watching me haha. Thanks for sharing!

Interviewed onsite at a company where I was asked some leetcode-medium binary tree problem. This was a well-known company with easily available lists of frequently asked interview questions you can find online. Luckily, I had solved this exact problem a few days back.

Unfortunately, this problem has an easy and ultra-straightforward solution using deques with O(N) space complexity, and an another slightly tricky solution with O(1) complexity. I had spent some time the other day cracking this O(1) solution. I decided that I would take the risk of reproducing the tricky solution and wow the interviewers.

Naturally, I didn't. I got confused and had to start from scratch several times. And the interviewer kept hinting that I could use a data structure to make this simple, but stubborn me thought I was just minutes from a working perfect solution.

I deeply internalized the saying "Perfect is the enemy of good" after I was marched out of the building after only two interviews instead of the usual 4. I've had my fair share of interview bombs but I consider this the worst because I was lucky enough to have faced a problem I had solved recently, and for which the interviewer was willing to accept the easier solution, and yet I managed to nuke it to oblivion.

I interviewed at Stripe, pre-COVID, and it was an onsite interview after I suffered a concussion. I should have cancelled the interview, but I was excited about the opportunity, and had underestimated how disabled the concussion left me.

Objectively I think I interviewed fairly strongly, however for the hands on coding portion of the interview, I basically couldn't even write more than a few lines. I couldn't remember simple things like function or class definitions. I had to look up a few syntax things, and my already challenging dyslexia was exacerbated to the point where I could barely type.

I recognize looking back on it that I had a freaking concussion and wasn't even supposed to be looking at screens or reading, but it was still really embarrassing.

My son was only a few months old. I had made it to the final rounds the interview process at a FAANG. He hd kept me up the night before as he had a cold I tended to take care of him in the night so my partner could sleep.

Next day I was asked all kinds of fun, esoteric questions about the C specification. That’s was hard. I was frazzled.

The final question I was asked to implement knn. Which I did brute force. And then I was asked to optimize it. And I was basically falling apart at that point and couldn’t recall a k-d tree. I blundered my way through some dead end.

This was for an engineering position embedded in an ops team. Sensing my interviewer’s frustration I asked if they’d ever have to implement knn on a page in a limited amount of time in order to bring the system back online. They said no. I never got an offer for that one.

All of the people who admit their process is flawed A) don't change the process and B) don't hire people who point it out

Imagine the people who don't know the process is flawed and treat it as sacrosanct. They'll sacrifice you at the alter of their process-god if you complain about it.

My first interview out of undergrad back in 2004, at a bank to write trading software. The recruiter told me I didn’t need to know anything about finance.

The first round grilled me about bond coupons and asked why I would apply to a bank if I didn’t know what that was. Completely flustered, I was handed a pen and paper Java assessment, and I completely froze up. Not even algorithms, simple stuff about scoping and how primitives and Objects do or don’t retain mutations after you return from a method. I bombed. The last interview was a clearly coked-up trader making fun of me, calling me an idiot, and asking me “how the fuck you got into MIT.” I cried on the way home.

If you've bombed an interview in a skillset that you've done productive work in, the fault is with the design of the interview. This doesn't mean that you won't be expected to skill up in the different set to pass those interviews, but don't take it personally either way.

As an example, almost no bit of coding work is done in an environment with no reference material, no autocompletion, no compiler feedback, and no debugger, yet many companies expect people to do whiteboard interviews with syntax and language features from memory.

That's exactly why so many of us get so frustrated with the state of technical interviews / technical hiring / HR at tech firms in general. The interviews seem designed as some kind of frat-like hazing gauntlet rather than a legitimate discussion / demonstration of how this professional could contribute to and benefit the organization.

I like the just talking approach. The best jobs I had when the interview was just talk.

But on the other hand so many people totally lie about their experience I can't believe it. People tend to have misleading cvs and overexaggerate their responsibilities very often. It makes me sad, because we can't just hire and continue the project, we need to spend few months getting people into the project, "giving a chance", to finally discover they just can't code, until we finally find the right person.

I think we've all seen this scenario you describe... I'm not opposed at all to there being some code in an interview - assuming it is a coding role. Too often though the exercises seem to be designed as a "gotcha" or to show how "smart" the interview is, rather than to augment the discussion. Or, as others have pointed out, actually end up demonstrating incompetence on the part of the interviewer as they don't understand their own question or the possible alternative solutions to their question.

At least twice been invited to interview for roles that were not hands-on-keyboard roles, yet the entire interview process was coding activities. That's the kind of thing that drives me nuts, as it makes it obvious that the company doesn't even know what they want to hire. At least one of the times was a company that shows up on HN as a "darling", which makes me even angrier...

> misleading cvs

If you want a real chuckle, go look at the LinkedIn profiles of some of those "few-monthers" and take a look at how epic and groundbreaking their contribution was when they worked for you.

Tbh I disagree.

Just talking means a "talker" can bs his way through.

I ain't got nothing against a white board question as long as it is understood that syntax errors can obv happen but aren't the "point".

Whenever I interview vendors or contractors, I have a little bit of leeway from following company policy, so I sit them in front of a computer with Visual Studio and internet and tell them they can use whatever resources they want to solve the problem.

From the other side, I haven't had a technical interview for a few years, but back when I did, I eventually addressed the whiteboard thing by bringing a laptop and telling the interviewer that I suck at whiteboarding code, and I'd like to do it for real instead. I think I've tried that in three interview loops and gotten the job twice.

CEO: "please sit down"

Me: *sits down*

CEO (whispers to my ear): "this is my chair"

I love this so much

Did you get the jerb?

Google relies on writing syntactically correct code in a google doc with no autocomplete/auto indenting during their interviews. The cognitive load of this plus having to answer very difficult obscure algorithmic questions was too foreign from my normal workflow and too heavy of a cognitive load for me to be able to answer the question accurately in the time given. I hope they don't build production code this way.

Now I'm just imagining an april fools event where they replace the really nice internally hosted code editor with google docs, disable code search, and call it interview awareness day.

Got contacted by a FAANG recruiter, had a nice general chat and she said she wanted to get me together with the hiring manager to learn more about the role. She emphasized that it would not be a coding interview, which I interpreted to mean it would not be a technical interview.

So I didn’t prepare at all, anticipating a chat where they did most of the talking and I maybe talked a bit about my work history.

I get on the call and the guy starts peppering me with specific questions about a technology I had said I liked but hadn’t worked with for like 5 years.

I made the mistake of BSing a few things. the guy immediately caught on to the BS and seemed to have a good time calling it out. Very embarrassing. It felt like I was getting cross examined or something. After about ten minutes I managed to get off my back foot and end the interview, salvaging some of my dignity.

He weirdly became extremely friendly after I said I didn’t think this was a good fit. Still not quite sure how to interpret that.

at a guess, he possibly realised he was acting like a dick and thought he'd give you some slack

or possibly he thought - yes I've won and the pressure was off humiliating you

I've come to realise with time, keep your BS down to a low level, and if caught out out admit the truth - DO NOT DIG DEEPER

In one interview, I was asked to check if a string was equivalent to its reverse in python. I was so excited because I knew the one-liner to do this (string==string[::-1]). But once I did this and the interviewer wasn't happy, I was super confused. I struggled to figure out what the interviewer wanted, and it wasn't until the end when he just told me what he was looking for. Which was to use a two pointer solution, and generators because what if you have a huge string, you could return early without inverting the whole list, etc.

The funny part too is that I had been preparing for interviews with Leetcode and practicing big O notation, but I was just so excited by the seeming simplicity of the question that I completely threw out all of that prep. I'm glad that happened though, it taught me a good lesson :)

The interviewer failed then. That is an acceptable answer. They should have then asked probing questions on how you would change it to be more efficient for a 1 million line string or something else about how could you make it more efficient.

Let's see. The first time I was asked to implement quicksort, in code, on a whiteboard. It was not an algorithm I knew (I was a hacker, not a computer scientist) and I managed to figure out the algorithm on the fly but not the implementation with two pointers. I guess I didn't bomb since I actually progressed to the next phase.

Most recently, I was asked to implement os.path.normpath in plain python, getting it right, and then told I failed with no feedback. Later I realized the problem is in leetcode and I had answered everything right, so I'm still curious what I did wrong.

I don't understand why folks are asking leetcode questions straight off the website without even changing the test cases, or not providing a function signature, docstring, and some test cases.

Ultimately, I've learned you have to simply accept when an interviewer is an idiot and move on. Even if you've been blocked for moving forward on a role that you're perfect for. Now when I administer and interview I work extremely hard to allow the interviewee to demonstrate their positives.

10+ years ago I've been applying for junior ruby dev roles while still at university.

At one company they gave me a pen and a piece of paper, told me to sort an array and gave me a couple of minutes to write my answer.

I assumed I'm at command line, so I generated a rails scaffold (model, controller, view, db migrations), created and migrated the database, opened a database prompt and wrote a SQL "select ... order by" statement.

I think I wanted to demonstrate that I know rails and related tools; but I was also stressed and didn't communicate well. After looking at my answer they quickly ended the interview, told me "we'll be in touch" and I got a rejection email on my way home.

I laughed out loud at this one. Nice one!

I left my job in 2021 to create a startup that raised $6-7 million and in late 2022 I exited for about $2.5 million. I wrote about half or more of the code. I consider myself a very proficient full-stack engineer and I know typescript, react, databases, and Rust, among other things. Over a decade of experience.

I’ve since decided to apply for two different software engineer jobs (since I don’t want to make another company yet) and didn’t get an offer for either. No idea why but I think it has to do with the technical interview. On one I didn’t even get past the first screen.

I amusingly find it harder to get a good software engineer job (let’s say which pays $200k+) than to create a company and raise millions (at least in the bubbly 2021 market). The technical interviews are just ridiculous and almost feel like a mild form of harassment. It’s like just because I don’t ace whatever esoteric code exercise they come up with, I’m ineligible for the job.

I was interviewing at Apple some years ago and was in the final on-site interview with some people from the compiler team. I offhandedly mentioned that std::atomics was allowed to be implemented with mutexes and was in this particular edge case on common platforms while I was explaining some decisions in example code. The interviewer immediately snapped back that it wasn't true. I pointed out is_lock_free(), which they didn't believe existed and offered to look it up to resolve the disagreement (rejected). It went on for several minutes before I could get the conversation onto a new topic, but the interview went from intense to actively hostile for the remainder. All the other sessions went well from my perspective, but that presumably caused a hard no. I still have no idea if there was some other point being made or the interviewer just wasn't familiar with that corner of C++.

I was kinda goaded into an interview by someone. I've always been a Linux, C, and lately, some Go guy. This company was Windows and .Net. So I politely declined, but this person told me to just interview and it would be fine.

So I joined. Person who made all these assurances is on, as well as this younger guy. Proceeds to ask some rather academic type questions about features of languages I haven't looked at in 20 years. To be clear, not bad questions, but more suited to someone just out of CS, or from Java/C# land.

Rather than just BS my way through, I declined to answer and said I'm not comfortable speaking to it.

The original guy who asked me to interview got flustered, cut it short after the third question, and said I'm not so and so material.

The whole thing was a bit surreal to me, to be honest.

In about 2006, I ‘bombed’ an interview by telling the CTO that they were going to miss out if they ignored mobile. I’d been involved in building some early mobile sites and thought that this was something that was going to be truly significant quite soon. The CTO of this dev shop held up his feature phone and told me that no way would people ever buy anything on a phone. He didn’t think phones would evolve much more than that.

It quickly became clear that I wouldn’t want to work there and the CTO thought I was such an idiot they didn’t even seen me a rejection email, despite having passed 3 other interviews. Soon after the iPhone was released and mobile became significant.

I learned that I can't talk through my thought process while in the middle of writing code.

During a remote interview I was asked to code up Fibonacci, an algorithm I'd implemented plenty of times before. The interviewer wanted me to share what I was thinking as I did the work.

I struggled and struggled and just couldn't get it. I lost my train of thought every time I described what I was doing.Eventually I was told I could stop.

After I hung up the call, I banged out the correct code in thirty seconds.

It's easy to walk someone through my code after it's written. But apparently I don't get to consider a problem space in $LANG and in English at the same time.

I had the exact same experience with writing code for Fibonacci in an unfamiliar online coding environment. I completely froze up, couldn’t think straight. It was really embarrassing and hilarious at the same time. These interviews take some practice, it’s very different from everyday coding. I can track down and fix the most complicated bugs in complex systems, yet bomb the most basic assignment if taken out from my comfort zone. As with everything it takes practice.

I interviewed for an ML scientist role (remote) while I was feeling a bit under the weather. I got through to a round with the founder/CEO and things were going well. However, this was a few days later and I was beginning to feel not so good, lots of brain fog and fatigue. The interviewer asked me a fairly basic question about a certain module and why one would use it and what the effect would be with given parameters. I sort of dropped the ball and said something reasonable but not super rigorous, and I could tell the interviewer wasn’t very satisfied.

The next day I took a COVID test and it was positive. I should’ve postponed the interview as soon as something was off but it would be weeks until I felt better. I ended up getting a better offer at a better company but it still hurt to be rejected at least in part because I wasn’t feeling 100%. Live and learn.

I applied to one company that's well known in my broad field around 5 times before getting a phone interview. The job was for a developer of scientific software and they were looking for people with a stronger domain science background, not developers in general.

The core of the interview was a series of puzzle questions, some of which were domain questions, some of which were not. The interviewer would frequently answer a question before I had sufficient time to think about it. I could have figured out the answers had they not been fired off in rapid succession. I think they believe these questions are fundamental in some sense, but I'd question the importance of most of them. And scientific software developers rarely need to solve problems 30 seconds after hearing the problem statement.

People say that the interviewee should be interviewing the interviewer too, so after the interview I wondered how they might have reacted if I started asking them some puzzle questions that I think are fundamental as well. I want to make sure that they know their stuff too, right? I bet they would have absolutely bombed that.

I think their process selects for people who memorize answers to questions, as I skimmed the company's Glassdoor before the interview and saw many of the questions posted on there. So I doubt this process is actually selecting the most qualified candidates. Plus, these days I think ChatGPT might do a fair job of quickly answering these questions...

"How would you deal with a problem employee?" Without missing a beat, I asked, "Does he have a weapon?"

My boss years ago had to fire an employee when a background check indicated that they were an IRA member. He fired the guy, got in a cab to the airport, and got the next plane out of Ireland back to the US.

oooofff... I had to fire someone once with a serious anger management problem. This was legitimately one of the scenarios we considered in how to best let them go and not have anyone get hurt.

Circa 2010 I got an email out of the blue from a Google recruiter. “We looked at your LinkedIn and you’re a good candidate for a ‘product manager’ role.”

Cool; let’s talk by phone, I replied.

The phone interview was insane. I asked the woman what about my work history made her suspect that I’d be a good PM and she was not able to respond. I asked her what product she anticipated that if work on and she said we would figure that out after I started, as if that was the most natural thing in the world. And I asked her how they handled remote employees, to which she replied that the person who took the role would be moving to Mountain View.

“So,” I said, “you do not know why you are hiring me, and you do not know what I would be hired for, but no matter what it is, the job is in Silicon Valley?

She said yes, already sensing where this was going. I asked her if she could make sure Google never contacted me again for any reason and she agreed that was probably for the best.

I did not get the job.

>“So,” I said, “you do not know why you are hiring me, and you do not know what I would be hired for, but no matter what it is, the job is in Silicon Valley?

Cue that well-known [1] joke about an engineer and a manager/MBA and a hot air balloon.

[1] https://news.ycombinator.com/item?id=25855303

I'm not against any of those roles, and have been in 2 out of 3 of them (not the MBA), just don't like stupidity (though have done a lot of that too :)

Definitely bombed my very first interview.

After sending almost 150 CVs I had the opportunity to schedule a call with a manager at Apple for an internship, this was supposed to be the classic "get to know each other for a couple of minutes and then talk about how this is going to work".

Everything was fine until the manager asked a very basic problem (checking if a sudoku solution was valid), I did not expect a coding question during this very meeting so I was very nervous at the time and messed up.

They told me that they had found another candidate for the position saying that they do first come first served. I don't believe a single word of it, they took another candidate just because I was not good enough during the coding part and that's okay!

Moral of the story: don't believe what they say about the interview that it's going to take place, don't make assumptions, just be prepared for everything that could happen.

manager at netflix told me that i used an older java version in my take home which indicated that i am not someone who keeps up with latest tech.

Some dude at airbnb asked me if had gone to IIT ( indian institute of tech) and ended the interview early when i told him i didn't. This was after they flew me into sfo.

This is not an example of bombing an interview, if they wanted a recent java version they should have stated that.

Unless you chose a java version old enough to have a driving license, in which case I could understand that response.

it was java 7 when the latest release was java 8.

That's dodging a bullet rather than bombing an interview.

a very high comp cushy bullet :)

I was literally a protocol software developer and screwed up the “what happens when I type <URL> in browser”

I was sooo deep in specific wireless network protocols I had to take a step back and really try not to go too deep too fast. I got way too deep into the specifics of wireless networking and everything that can go wrong. They seemed disinterested, and that killed my confidence. I mumbled over my words quite a bit and struggled to keep at the right level of abstraction. I felt rather intimidated. I had a strong vibe this person interviewing me didn’t want to be there anyway and they weren’t helping me along.

I applied to a FAANG for a leadership IC position and the code challenge was the literal exact question I've asked maybe 100+ candidates. I completely forgot everything about it and had to solve from first principles.

was it a leadership or individual contributor position?

Both - principal engineer

I had an interview with a startup, completely owned the questions on the technical interview. When time came for the 1 - 1 interview with the CTO I had luck to ask them about their growth rate and investors. No regrets.

I was given two hours to answer two questions and to program two algorithms. I answered the two questions right. Finished the first code challenge but my tests only passed 75% (forgot some edge cases?) and the second problem I was two mentally exhausted to give a crap, so i described the solution in natural language and called it a day. I was not thrilled about the position (i had something better lined up), just took the code to see how hard it would be. It was not so hard, if given more time.

Update: first problem I solved with a breadth first search, the second was a minimum spamming tree.

Earlier in my career, I had pretty good luck in interviews. I think I got offer from pretty much every place I had interviewed at.

I stayed for pretty long time at my last company. In mean time, interview processes changed and it was all about LeetCode. I knew a little bit about it but all I thought was that it is similar to FizzBuzz problem. And I enjoy puzzles, so I thought that it would be fun.

I applied at Facebook, the recruiter tried to warn me but she also told me that since I have been programming for so long, it should be no problem. I didn't really looked at real problems, instead just tried a few examples that were there to get to you familiar with Facebook interview environment. They were pretty easy, so I was feeling very confident.

Needless to say in the actual interview, I could not even decipher problem. The interviewer helped me understand it. I was able to create brute-force solution but could not optimize it. Felt pretty dumb.

After that I looked up LeetCode, spent hours practicing it. I forgot about everything else.

Eventually, I restarted interview process. The next company I applied for was to warm up. I passed all their 3-4 LeetCode and System Design rounds. I started to feel good about it.

But I was so focused on technical aspects that I forgot about behavioral interview part. My brain was so focused on puzzles that I thought all those normal behavior questions were trick questions. I blanked and mumbled mostly. I really liked the interviewer too, I thought he had similar personality as me.

Then I went back to basics and wrote down answers to various behavior questions. And tried to revise those questions before my next few interviews. There I got still rejected but got a few offers. However, this experience also taught me that I cannot rely on my previous good luck anymore and should spend time preparing.

I can think of a few.

Uni interview at Cambridge for physics, I was asked to: derive the equation of motion for some coins sliding into each other on a table, and identify the oscillatory nodes of a tea cup struck with a spoon. Needless to say I didn’t get in and have the utmost respect for those who did!

First technical job interview I was asked whether a heavy or light element is better for absorbing nuclear radiation. Now that one I am embarrassed I didn’t get having completed my physics degree. Lighter is better.

Was that for an undergraduate at Cambridge?

Undergraduate, yes

I don't know if I bombed exactly, but here's 2 of my most frustrating technical interviewing experiences that didn't go well for really dumb reasons.

> Had a 6AM interview with a developer in India with a very thick accent and who didn't have a good microphone, which made it very difficult to communicate. He didn't have a copy of my resume, wasn't completely sure what job he was interviewing me for, and started asking me React trivia questions for what should have been a primarily Python role.

> Had a technical interview with a cool startup doing some dumb leetcode style problem. We had some repeated video connection problems and started the interview 15 minutes late because we couldn't get a connection. Because of this, I was pressing and stressed out to finish the task on time and made a few silly errors because I didn't have time to think the problem through. Got most of the task done despite this, but it's frustrating to think that I missed out on this position because of some dumb video chat glitch.

I've had very good luck interviewing but when I was looking for jobs in college I bombed not necessarily from the technical portion but from the soft skills.

Was interviewing at a super friendly seeming company that happened to also do a ton of government and security work. They asked me how I've dealt with someone on a team I didn't work well with and I mentioned someone from a senior project who wasn't pulling their weights. I basically said pulled up his slack and moved on but then "destroyed him during reviews." I didn't realize how much of a faux pas this was for this type of interview and was told I didn't get the job because of issues working with others.

Having conducted hundreds of interviews now I realize the error of my ways but I still maintain writing a bad review of someone is not that bad when compared to the other unhealthy ways to handle it.

In the end I lucked out because that would have put me in the world of high clearance government worked that I've grown to hate these days, they may have been able to Stockholm syndrome me into liking that kind of work.

I, a React developer, took three months off developing in React, only to forget how `useEffect()` works when you pass it no dependencies (vs when you pass it an empty array.)

Idea: Build a map of things that are easily forgotten and treat it as a map of places where the API needs improvement. (Following ye olde Law of Least Surprise. Thanks, Larry Wall!)

The fact that it’s unintuitive and different is why hooks are a joke. Class components just make sense.

TBH I disagree, I prefer strict functional programming, mostly for composability. Class components feel like translating everything into latin numerals and then back out again.

Hooks help me avoid that pain. But is the API perfect? Nope.

There are also frameworks like solidjs which have similar syntax to React but avoid the complexity of hooks with a simpler API and no hook rules. Classes are not the only solution

Lately I've been investigating Svelte. It looks really good, but I think I'm going to stick with React/Nextjs simply because of the ecosystem and switching cost.

Again, this isn't 'American Idol for frameworks'; I'm not picking React because I think it's the best, or even better. I'm picking React because of the habitat, and because that habitat is now, in a sense, my hometown.

Yeah of course, you always have to do what is best for your company/clients and React is always a great choice (can't beat the ecosystem)

It's the same reason why I non-ironically recommend Wordpress to a lot of people that have super limited budgets and want the moon.

I do enjoy trying all the different new approaches to UI development though, especially as I'm not a frontend developer so most of the time I write frontend code I'm building either internal tools or personal projects, so I get to experiment a lot.

I never had a problem with the explicit lifecycle methods in class components, and the concept of a functional component effectively being the render method in isolation. To me there’s only one clear advantage to hooks and that’s sheer reduction in raw lines of code. Having said that, it’s a pretty huge advantage for something like redux.

I, a React developer for ~8 years, don’t really remember what useEffect does without the second param. I never needed it, so I forgot. I almost feel it should be a required prop, and I doubt that that knowledge alone would fail or pass an interview.

One of the things about React is that local codebase conventions really influence what parts of the API are high-touch for you.

I too have been coding in React for that long (precisely that long, oddly enough ;D) and I used `useEffect()` in pretty much everything I was doing.

There are reasons for this that are local to the project I was on for most of that time.

And yeah, I'm pretty sure my embarrassing confusion cost me the interview in question.

Coding is a lot like playing a musical instrument, or singing. Without daily practice, you get musty. You can scrape off the must in a matter of days or weeks, but in the meantime, you can be expected to bomb any audition.

This is why it's so good to have something on the go on GitHub. It's not about the star-count, it's about keeping your hand in.

Google. I literally lost my voice and could barely understand the Chinese interviewer's accent. All my interviewers that day had an accent. Little did I know I had COVID. I failed the interview and had to take some time off to recover emotionally because it was a difficult interview.

Also failed at Amazon because they brought me for an interview and it started 9am and ended at 5pm. I was too tired and they kept trying to make simple question harder by adding constraints. I gave up because it wasn't worth it.

Do yourself a favor, if you don't like the interview and interviewer just leave in the middle of the interview. It's not worth the emotional and mental cost. Also there is a good chance you don't like the company and the company culture if the interview is not going accordingly.

I bomb most technical interviews if I'm being honest. I struggle quite a bit with the text book questioning part of the process, mostly with using the correct terminology. I think this is partly because I've been remote for the last 10 years and don't talk programming with other developers very often, but also I'm just the kind of guy that struggles grasping the words I'm looking for in conversation and ends up saying things in a round about way.

I'm probably in the minority here, but I prefer live coding exercises. Definitely more confident showing my competence than trying to explain it.

In Summer 2001 I had been laid off from the failed startup I had left IBM to join the year before and the job market had gone downhill fast. So while the year before I had gotten 3 offers going to interviews wearing jeans I was now suiting up (I'm normally a casual dresser). Well I interviewed at one place which I think was a small company that made available financial disclosures on the Internet and the main programmer was a young guy wearing sandals. Well I think the ex-IBM guy in a suit terrified him and at some point when I asked him what he was looking for he said something about someone who would fit in. He couldn't see that I was only suiting up out of respect for the interview. I didn't hear back from them.

Google Interview after my first university year for a masters internship (might not have been the best idea in the first place).

Got asked how to manipulate a collection, showed the interviewer 10 different ways how to do something, each time a bit different as he rephrased the question to get me to the result he actually wanted to see (I knew what it was but tried to be snarky, if that's the right word).

Actually fucked up the right answer at the end because I lost track in the process...

Also forgot that remove(obj) will actually iterate through the whole list each time it wants to delete an element if the element was added last..

The other interview was even worse because communication was bad.

I'm unable to feel shame or embarassment in interviews anymore. Have encountered sufficient share of assholes, had enough time and hopes smashed and thrown away. If your point is to find incompetent fraud, let me be your incompetent fraud.

One of my first interviews while I was still in college the guy bombed me with question after question that I couldn't answer - about threadsafe programming, certain Frameworks I had never heard of as well as DBMS design - and at some point when I took a while to "remember" ACID his tone took another sharp turn to the point where he always sounded pissed. Obv I didn't get the job but it was the absolute kick in the behind that I needed to study a lot on my own, after which every subsequent interview felt like an absolute breeze.

Bombed more than one technical interview but here's one example.

Phone screen interview with Google. Interviewer asked about how I would keep track of the nth highest value in an infinite stream of values. I said I would use a heap. Then interviewer asked to me write the code for that heap in a Google Doc. I can't remember what I wrote, but I'm pretty sure that I barely got started. Boom.

Lesson here is that simply knowing something in general might not be enough. If you think you know something, try implementing it from scratch to be sure.

>Phone screen interview with Google. Interviewer asked about how I would keep track of the nth highest value in an infinite stream of values...Then interviewer asked to me write the code for that heap in a Google Doc.

I guess at least you had Google Doc to presumably share with the interviewer... I remember a phone screen about 20 years ago where the guy asked me to write some C code (of course position wouldn't involve C...) and then repeat back over the phone character by character what I had written. I got through the phone screen and invited to an onsite, but the process was so utterly stupid that it pretty much permanently turned me off of that household name company in Seattle.

I errored when I accepted two thechnical interviews on the same day - in person, same city. The first went well but it drained me much more than I anticipated and I had no brain power left to function. The second interview was harder, some leet code problem I never encountered before and well... they did not call me back :D it was 10 years ago and I still have frustrations over it. Horrible. I just want to put down that memory and forget about it.

I’m reading all these stories and think that most of them describe good engineers facing unreasonable interviews. Seriously, the processes being described are outright broken for most of these companies, and I would have walked out laughing at most of them. They are actively weeding out great talent. Thus, I would say the companies were the ones that bombed these interviews, not the engineers that were subjected to them.

Google phone interview long time ago. Can’t remember what I said or did wrong, but realised I wouldn’t get a call back when the guy asked: ”do you know what a set is?”

Wrote an O(n²) solution not thinking n would be 1000000000.

While I don't know if I "bombed it" per-se, I told a HR guy and a senior systems architect that I didn't have any experience with fibrechannel and SAN because it's too expensive for regular joe's to get into.

(I've since been told the position is still available, because there are two available and they haven't decided who is filling that other position on top of the one I applied for)

Despite having almost two decades of experience they asked me the kinds of questions that only someone who recently aced a CS theory class could answer. The kinds of things that do not matter at all to the job.

I didn’t even bother. I just said I didn’t know the answer, and that them asking those kinds of questions made me not want to work there.

I guess that counts as bombing, but I really could not have cared less.

Do you have an example or two?

IIRC they wanted to know the efficiency of different algorithms like big O notation stuff. Maybe it would be understandable if we were doing high performance real time programming in C. The job was writing HTTP APIs. I aced all the HTTP and SQL questions.

I've given the "(I know the answer but) this is a dumb question" in response to "using two stacks, how would you implement a queue".

I think being able to implement a queue using two stacks is kinda neat. But, nevertheless, it's not a good interview question.

I’ve bombed every single one because they don’t let me use a notebook with all of my notes, Google/search engine and additionally bring in my other friends who we mutually discuss and solve problems with as a group.

Consequently, you don’t get the kind of employees who are good at solving the problem, rather they are good at social chit-chat and taking your asinine…

Truly, truly asinine… “Test”

I was fostering a bunch of kittens but one of them caught a bad virus and had to be put down. The very next I had an interview lined up. The question asked was a standard puzzle/algorithm type question, 5 minutes into solving the question my mind went blank. I was still upset over what had happened and I told the person I can't do this and I cut the call.

Sorry for your loss.

First time I just go so nervous I coulnd't think at all, and what should have been an hours long thing was broght to a close with him saying "well I know all I need to know" and my heart sank.

Salesfore asked me to implement a sorting algorithm (final round) for an intern position and I said I wouldn't because I just couldn't. It was after other multiple questions.

I had one this week! Not a total "bomb", but I'm claiming recency privilege in order to talk about it anyway.

Did a full loop with a company notorious for asking Leetcode "hard" coding questions. I've been practicing "medium" questions for months, but I practiced about 10 "hards" specifically for this loop and was feeling unusually good - or at least more nervous about the behavioral interviews than the coding.

After 2 behavioral & system design interviews that went OK-ish, there was a coding interview. The first part of the question was to check if a binary tree is a valid binary search tree. I solved that part easily using the first familiar pattern that came to mind, with tests. However, the interviewer seemed confused by/skeptical of my solution, which spiked my anxiety that I had overlooked something horribly obvious or had even solved the wrong problem entirely.

For the second part, he asked me to come up with a plain text representation of a binary search tree and write code to build a tree from its text representation. This isn't even an objectively difficult problem - perhaps "Leetcode medium" at most, and it's the kind of problem I could solve alone in a quiet environment, but I have always struggled to think about recursive problems under time pressure and while "talking through my approach". I have to think hard when I tackle a recursive problem that is new to me (or even a familiar one I haven't seen in a while) - once the pattern clicks, it's dead obvious, but I definitely don't have the kind of brain that finds these problems easy. And in an interview situation, it's as if the talking part of the brain suppresses whatever other part is somewhat capable of grokking recursive problems. Particularly when there is a coding interview immediately following several very "talky" design & behavioral interviews.

Anyway, I flopped around for a while trying to get it right, but quickly ran out of time. The interviewer tried to offer guidance a few times, but this mostly just broke my train of thought, unfortunately.

The interviewer was a soft-spoken guy with an Architect job title, and my anxious, stereotyping brain, insecure about its own algorithmic ability, decided that this is the kind of engineer who can solve Leetcode hards in his sleep, so he's going to consider me extra dumb and incompetent for messing up this pretty "easy" problem. A talker who can't actually code, even. Of course, it's possible he sucks at solving algorithm problems under pressure almost as much as I do :-)

Waiting for the result.

I have pretty severe C-PTSD and structural dissociation and this has resulted in some moments... Usually this is just a tendency to have memory issues under stress. I have blanked on everything from the names of my own projects to names of companies I have worked for.

When I get triggered in an interview very "interesting" things can happen. Probably the most "legendary" is when I started uncontrollably crying and sobbing in an interview. They obviously wanted to bail and reschedule but I composed myself and was like "no keep going. I am fine". The irony was that they completely lost focus and did a terrible interviewing job but I did pretty good. Shockingly, I did not get that job.

Just last summer I bombed a take-home interview project with Lufthansa Technik. They wanted me to implement Rock Paper Scissors a litte bit "over-engineered." Long story short their definition of "over-engineered" was much more involved than mine. I thought I would just need to implement it such that I showed that I wasn't bullshitting them about being able to do that which I said I could. Maybe 2-3 hours of work. I was wrong. Knowing what I know now, I would have had to spend at least 8 hours on it. They expected me to implement a complete backend, frontend, test suites, and design the application such that they would I would be able to extend it to fit an unknown requirement that they only revealed to me during the review of my assignment.

This culminated in the Engineering Manager saying to me at one point: "Wow, you have a lot of experience, it's sad you didn't show us that in your assignment."

TL;DR: Bombed a take-home assignment with the vague requirements of "over-engineer it on purpose" because my "over-engineering" was not over-engineered enough even though it completely fulfilled all requirements. If you're going to give take-home assignments please define hard requirements up front and avoid vague guidelines like "over-engineer this please k thanks"

One of my first interviews was at a place that made a job interviewing web app platform. After a programming exercise they decided to bring me in for an in-person interview. Long story short, I bombed with every person that I talked to over the course of the next 3-4 hours.

The first part was a system design interview. I had never done one of these, and my experience up to this point was basically working on small scale web apps at a local software development agency.

Next I continued on to an algorithm-focused white board exercise. It was something about trees, but again I was not able to articulate anything. I remember saying something like, "Recursion is bad", and immediately I could sense that that was a mistake. What I meant was that with Python you have to be mindful of recursion because you can get that "Maximum call stack size exceeded" error.

Next we ate lunch. I attempted to engage in conversation with an engineer by asking her where she had studied. She replied, and I then made the mistake of speaking negatively about the school that I knew was her school's competitor. Basically my attempt at comradery fell flat and I just looked like an idiot. The thing is that in reality I could care less about people's schools. I was just trying to be conversational, but failed.

After lunch, I had a meeting with a person who held a high-ranking position in the engineering department, possibly a director. His spacious office with a window indicated his significance. During the meeting, he inquired about my academic background and what I had learned in school. This particular part of the interview left me with the impression that I had failed to learn anything of value.

He had me work on some problem about a "Bipartite Graph" - Like prove that this graph is bipartite, or something like that. He had me do it on his window with expo markers, and it was taking me so long to get through this problem he actually left the room for a good 5 minutes and left me in there to mull it over.

The final part of the interview was with the front-end people. I don't remember much about this other than talking about React, since it was the hot new thing at that point.

By the end of the day, I knew I had done a bad job, and I felt very dumb. I remember emailing the guy shortly after leaving, basically apologizing for doing such a bad job, and that, "I promise I will do a good job if you choose to hire me".

I still cringe thinking about this experience, but it's also kind of funny that I could have this type of experience at a company who literally made an interviewing platform. I thought that was pretty ironic. I recognize that I did a pretty bad job, but nobody deserves to feel like I did after that interview.

I used GOTO's