Comment by joshka

> It has really annoyed me; I ended up doing three interviews over the course of four weeks, and I'm pretty confident that I got the technical questions right. It could be that my resume is too "jumpy", which is fair, but they could have read my resume before they wasted my time and theirs with three multi-hour interviews.

If they're interviewing you, then it's likely that at least someone read your resume and decided that you were possibly a good enough fit to spend many hours of time talking to and debriefing about. It's more likely that you didn't provide enough good signals to hire in the interview.

The way to look at any interview is that it has to provide a signal to hire. Technical correctness is just one of those signals. It's an important one, but the other aspects are also important. Some things that will set you aside from other technical competent people:

- Tech is often a place where the interviewers are actually doing the job at a similar level to you rather than just being HR / Managers. Treat interviewers not as a gatekeeper to a job, but instead as a potential future peer. Start with the mindset of "Would I like to work with this person, and how can I convince them that they'd like to work with me". This reframes the interview as more of a collaborative effort to getting you that job than just a "solve the problems, tick the boxes" type thing.

- Learn / write / *practice out loud* a good way to introduce yourself. What's your 2 minute story, what drives you, why are you here? Interviewers often most recall the first and last things you said in an interview the most and perhaps one other moment. Looking at the first line of your hn bio "Eccentric math-enthusiast/wannabe-intellectual in NYC." has 3 words that hold at negative interpretations / no hire signals. Sometimes less is more here. In a recent interview, I had a longer 3 paragraph intro prepared, but the interviewer jumped in after the first and basically said something similar to "That's exactly my story, we need more people like that". I shut my mouth immediately on the rest of the intro because the connection bit was done.

- You mentioned in several comments below being corrected in interviews but knowing you're right. This really actually doesn't matter in many cases. These moments are perfect place for you to demonstrate humility and how you deal with feedback. These are key skills of a team player. What actually matters most is how you handle that interaction. Take that and use it to proved a signal to hire by acting like a colleague not a robot. Something as simple as "I hear you want to ..., let's dig deeper into that in case I've missed something in my approach." is the very basic part of this.

- Put yourself in the mindset of having gotten the job and started working in the job. What would that look like? How would you act? You often have a small amount of time at the beginning or end of an interview round to ask questions about the person's job, team, work environment. Ask questions that provide good signals and demonstrate that you're someone that they'd want to work with. E.g. ones about day to day activities, team interactions, culture, internal promotions, etc.

I'd recommend finding a way to get a software development manager friend or acquaintance to interview you and provide feedback. Reach out to your network and find someone that can give you honest advice (if you know other employed devs then you have second degree contacts). If you can't find this in your network, then consider paying for it (e.g. something like interviewing.io or hellointerview.com). The benefit of doing it with a friend is that you're much more relaxed about things and can take that same relaxation to the way you interview.

For most software development interviews you're going to have a system design and a behavioral round. Watch youtube videos about tech interviewing and system design (Hello Interview, . Spend time practicing using the tools that you might see in interviews (e.g. coderpad, excalidraw) so that you're not spending time learning the tooling and instead you can focus purely on the interview.

A few soft skills books worth reading are "How to Win Friends and Influence People" by Dale Carnegie, and "The Secrets to Consulting Success" by Gerald M Weinberg. They're not interviewing specific, but both have a bunch of things related to giving and taking advice (which is what we spend a lot of our time doing as software engineers).

---

Something that you might consider trying is using a LLM to help you prepare (ChatGPT or your favorite local model). Vibe code your own interview personality coach.

First, set yourself up with a bunch of context: all the (mainly) non technical questions you've been asked in interviews, a copy of your resume, and any extra relevant info about yourself (your projects / goals / etc.), job roles and descriptions docs of jobs that you might want to do (find a bunch of these on big company websites). Ask the LLM for ideas for other context to add.

Then write your answers to the questions. Have the LLM analyze your tone, look for signals to hire, and suggest improvements to the way that you answer. Have the LLM come up with similar questions that might be asked and start practicing them. Have the LLM build a framework for answering that suits your approach. I like the CARL (Context, Action, Result, and Learning) approach over the more typical STAR (Situation, Task, Action, Result) as it provides more and better signals earlier in your response.

Use the LLM to meta-analyze the process ("come up with the top 10 reasons that software engineers fail in interviews for ... with ... context. Build a checklist of areas to analyze response"). If you have access to agentic tooling (e.g. Github copilot, Codex CLI, Claude Code), use it to build markdown summaries of things to look back on instead of leaving this info in your LLM chat history. Perhaps feed your blog posts and twitter history into the same checklist - you might find that the signals that you're putting out to the world have some glaring obvious problems that you're blind to because of your intimate familiarity, biases and assumptions.