Skip to content

Interview Horror Stories

Tech interviews, DSA rounds, take homes and ghosting

t/interview_horror

Coding rounds, system design, take home assignments that took a week, recruiters who ghosted, offers that got pulled, and the occasional interview that went great. Prep resources and real questions welcome.

27 members
16 posts
Created May 2026
+2

Community rules

3 rules for t/interview_horror

  1. No leaking NDA questions

    Describe the type of question. Do not paste a company question bank word for word.

  2. Name companies carefully

    You can name the company. Do not name the individual interviewer.

  3. Argue with the post, not the person

    Disagree as hard as you like. Insults, slurs and dogpiling get removed, and repeat offenders get removed too.

Moderated by Kunal Bhatia

Discussions

3
  • Mock interview swap

    d/mock-interview-swap

    Pair up for 45 minute mock interviews: DSA, system design, behavioural, SQL. Swap roles halfway, post three lines of honest feedback. Use your own problems, never NDA ones.

    33 members

    Read
  • Offer negotiation and rejections

    d/offer-negotiation-and-rejections

    The negotiation scripts that worked, the ones that didn't, rejections that hurt, and the celebrations when it went right

    40 members

    Read

Showing 16 posts.

Posts in t/interview_horror

11

  • the "say done only after dry running your own example" rule. i lost a round last month by saying "done" and the interviewer immediately typed [] as the input. silence. 💀
  • I was the interviewer on this one. The "defending instead of listening" at minute 18 is the one I see most. The follow-up is a gift and people treat it like an attack.
17

  • From the on-call side: whatever you build, log every 429 with the key and the rule that fired. The first incident will be a big customer behind one NAT IP getting throttled as "one user". Ask me how I know.
  • Strongly agree on fail open vs fail closed per endpoint. One more: put a small local token bucket in each gateway process in front of Redis. If Redis gets slow, the local bucket stops abusive clients from turning a Redis brownout into an outage.
    1 reply

  • Accepted answer

    Mahin, I'll be honest because I know you can take it. On Codeforces, a judge reads your code. In an interview, a human is scoring HOW you got there, because on the job your teammates have to follow your reasoning in design docs and code reviews. What "communication" means concretely on their rubric: 1. Restate the problem and ask 1-2 clarifying questions (directed? weighted? can it be disconnected?), even if you already know. 2. Say the brute force in one sentence, and why it's too slow. 3. Say the idea before coding: "multi-source BFS, because...". 4. Narrate lightly while coding. Not a TED talk, just signposts. 5. Dry run a small example before saying "done". Give the complexity without being asked. 6. Readable names, no macros. You're writing for a reader now, not a judge. Your speed is a huge asset. Slow down to 70% and spend the saved time on 1, 2, 3 and 5. You'll be a strong hire everywhere. And yes, I'm still saying LeetCode-style interviews are their own skill 😄 You can be much better than me at CF and still need this.
    1 reply
  • Very common with strong CP folks. You think in jumps, interviewers grade steps. Practise by recording yourself solving one problem a day out loud, 10 minutes. Painful to watch, very effective.
35

  • constraints table is basically what every CF guy does without thinking. two corrections tho: n ≤ 500 can also take O(n² log n) comfortably, and 10^8/sec is for simple ops in C++. python is like 10^7 on a good day
    1 reply
  • Coming back to DSA after a 6 year break, and this is the first cheat sheet that explains why and not only what. PFB my query (haha, old habits): is the prefix sum + hashmap approach expected from freshers or only experienced people? Thank you Nikhil sir.
    1 reply
6

  • Agree on requirements. I've been on both sides of maybe 200 of these. The candidates who fail usually start drawing boxes in minute two. The ones who pass ask how many submissions per second arrive when a contest starts, because that spike is the real problem in a LeetCode design.
    1 reply