Taro Experts

(Note: I had ChatGPT ingest my taro profile, and give out this response)

Every engineer, at every level, has shipped a bug that made it to production. It’s part of the job. The fact that your manager and teammates aren’t making a big deal out of it should tell you something: This happens. What matters is how you respond.

1. Own It, But Don’t Dwell on It

You already acknowledged the mistake—that’s step one. No need to keep beating yourself up over it. Instead, shift your focus to learning and improving.

2. Identify How It Slipped Through

Instead of just feeling bad, ask yourself:

• What kind of test could have caught this earlier?
• Was there a gap in validation? Could a better unit/integration test have helped?
• Were there warning signs in the code review that you or others overlooked?

3. Build a Simple Fix & Prevention Plan

• If a fix is still needed, prioritize it and make it right.
• Then, take the initiative to improve the process—maybe by adding better test coverage, refining code review checklists, or automating something that would have caught the issue earlier.
• When you do this, it shows growth and ownership, which will impress your team far more than the original bug.

4. Zoom Out—This Won’t Define You

Your reputation isn’t built on one mistake—it’s built on patterns of behavior over time. Engineers aren’t judged by whether they make mistakes; they’re judged by:

• How they respond to them
• How quickly they recover and improve
• Whether they take ownership and level up

5. Move Forward with Confidence

Take what you’ve learned, apply it, and keep shipping. No engineer—no matter how senior—writes perfect code all the time. What separates great engineers is their ability to iterate, improve, and move on.

This won’t be the last bug you introduce. But if you use this as a learning opportunity, you’ll come out of it as a stronger engineer—and that’s what really matters.

If he tells you to figure it out yourself that probably means he doesn’t know the answer / doesn’t have strong thoughts on it. If we were coworkers and you asked me how to mix purple paint I’d go into a 5 minute description but if you asked a coworker who’s not a painter they’d probably tell you to look it up yourself.

If that mentor is no longer a fit, chances are you both sense it. You can have a meeting with them and ask “hi thank you for all your help, I know youve been pretty busy and I’m wondering if we’d like to put our mentoring sessions on pause? I enjoy our sessions so please reach back out when you feel youre ready, and in the meanwhile I’m going to meet other people I can mutually learn from.” So you formally off board with them.

Afterward or in the meanwhile, you can ask your manager for another mentor. If you ask your manager before you off-board let your manager know youve yet to have that meeting on <a specific future date> so that they don’t spill the beans before you do.

Outside of formally asking your manager, I would also request 1:1s with people in your org and ask them about the work they do. If you like them, at the end you can ask them for regular occurring sessions with a termination (eg “meet weekly for a month” and then cross the bridge of continuing or not when you get there) where you can pick their brain and also help be a rubber duck for the things they’re working through. For example, the fact that I’m thinking thru and writing out a response to this has reminded me that I can also set up 1on1s with people in my org and forage for mentors that I have initial rapport with that I’d like to develop.

In my opinion, a mentorship is where there’s a primarily flow of info from one person to another but both should be learning and benefiting from the session. As a mentee you should be an inspiration and share your perspectives as well, and be their ear to their ground. Daresay canary in the goldmine lol.

Even at the Taro meetup, I shared what the current team match process looks like at Meta with Alex and Rahul so they can stay up to date with my position.

It's a skill issue. No matter how "bad" the economy gets, there are going to be people who land tons of interviews. Your job is to be one of those people.

You can still land interviews as a new grad. I even dropped out of my Master's in CS and landed 3-5 interviews a week in Fall 2023, when the economy was supposedly terrible.

There will always be a market for exceptional talent. So show that you're exceptional.

As they say at Taro:

• get good
• land interviews
• pass interviews

I've made similar pivots in my career as a full-stack dev. I went from a mostly web-based FSE to a fully mobile FSE. I talked up my mobile experience in my resume and applied for roles that were mobile-heavy, but listed as full stack.

In my opinion, full-stack hires are often "unicorn" hires, so it's easier to land a role without having deep experience in one area of their stack as long as you show competency and experience in other areas. If I were in your shoes, I would apply for backend-heavy full-stack roles for your next job, and then jump from that role to a pure backend role.

Windsurf is the AI IDE for better large context management. It's much better than cursor, but I havent messed around with it too much. I'm still sticking to cursor because I find that the QOL improvement from the code completion to be much higher ROI than asking LLMs to write code.

The code completion is usually doing boilerplate tasks that allow me to focus on the logic instead of "what did i name this variable" or "which file did function X belong to again". Or if I convert a list to a set, then it automatically updates the syntax in existing code to the set syntax instead of manually doing it

See this thread on why windsurf is better from the founder: x.com/_mohansolo/status/1899630153636118529

The TL;DR is they spent a ton of effort and lot more compute per query to find the right files for your query