Mid-level Engineer Career Development Videos, Forum, and Q&A

I've just started at a new company in Big Tech and have taken over responsibility for a large codebase. I learned that most of the people who were previously responsible for the code base (and who may have developed it) were laid off earlier this year. Is it OK for me to reach out to those people or is this bad form and maybe breaks some rules? The purpose of reaching out would be to get an overview from them on the codebase and perhaps ask questions as they come up.

I joined Meta around 2 months ago. After I started to ramp up on my team & initial project, there were major reorgs that happened in the past 10 days. Now my project was deprioritized and leadership is figuring out where to reallocate resources towards. I'm still very new on the team, so I wasn't super ramped up or invested in the first project. But now I feel as if I'm in limbo and it's potentially slowing down my ramp up and learning period. What should I be doing to navigate this environment as a new hire?

So I realized that bulleting my answers is helping me a lot. Do you recommend that I write down all the actions/results? For example, I tend to need to jam pack as much as possible to prove I was independent. I would love some input into this barebones structure I landed on when I tried to use chat gpt to help me summarize my thoughts. This is THE project I would probably need to present to get leveled at mid level properly. Streaming X Challenge 1. Problem → Need to Ingest 1B+ events of X into the UI from 7 different places (the user should see the events flow into the ui in realtime). Users needed both real-time & historical data updates. The journey started by implementing the old architecture end to end as assigned I found these performance problems below by taking on more of the task by elevating it. However, the volume of writing historical events is NOT as fast as we want to be able to read quickly. 2. Debugging & Fix Attempts → Tried multiple optimizations first Scalability fixes (replicas, indexes, optimized queries). Didn’t fully resolve issue → Had to rethink architecture (Manager came into the picture after I presented the detailed metrics to prove it didn't work after trying the solutions above). 3. Solution → Architectural overhaul + rigorous validation Wrote Design Document. Had to model all the edge cases around the data ordering before I had this meeting. Had meeting: Disagreement about payload size (We can get into this another time) Stateful streams introduced subtle stale data risks. The challenge: ensuring correctness, not just performance. Whiteboarded ordering logic to avoid stale rebroadcasts. Used integration tests to rigorously validate correctness. 4. Impact → Faster, cheaper, and now used in another project Reduced system lag, improved user experience when viewing those high volume data streams. (Measured by checking the system metrics and running scripts) Minimal cost increase, optimized architecture. (Inferred by system metrics and cloud budgeting) Became a standard approach, and I’m now reviewing future implementations in other initiatives. (Measured by new design docs using the same pattern I started)

I’m a machine learning engineer (MLE) working on an e-commerce recommendation system, while our backend engineers manage the serving server. I’m facing communication challenges with the backend lead: We're building an e-commerce search system, but he refuses to use a search engine due to maintenance overhead, insisting a regular database is sufficient for vector search. However, a search engine offers better algorithms, scalability, and faster improvements in click-through rates. - (a) Should I just acknowledge his opinion and say I'll bring it back to my team instead of debating in meetings? Because we are discussing the business requirement with PM in that meeting, not focusing on the tech stack. - (b) If he still refuses, should I find other collaborators or have MLEs maintain the search engine ourselves? He often shares strong opinions on ML algorithms in meetings, but while 80% is correct, 20% contradicts my understanding. Our discussions are usually focused on system-level topics, if I challenge him, the meeting may go off track; if I don’t, others (PM and other engineers) might assume we agree, leading to misconceptions. How should I handle this?

Saw this quiz trending on twitter and was curious what people here have scored: It's basically a test to see how SF/tech bro you are 😅 I scored a 74 so not too bad

I'm halfway through Rahul's Onboarding Course and am wondering if his advice in the course changes given that I'm on a contract 6-months to start. What triggered this thought was he says in the video Get Maximum Value Per Answer that you should consider yourself "Fully Onboarded" by Month 6 (and therefore take more time before asking questions). Since my contract is 6-months to start, I imagine I should strive especially hard to onboard quickly, but that the advice in the course doesn't really change. There are, after all, human limits to how quickly you can onboard and those don't change whether you're FTE or on contract to start. I believe my situation might be closer to that of an intern. So maybe I should go through Alex's Intern Course? Appreciate the feedback!

Can someone share the slack channel invite with me? (And also any other communication platforms Taro uses) I just joined a couple days ago and want to be on all Taro's communication platforms.

Observations after watching the time management course: I’ve noticed the focus block really takes a lot of activation energy and then it eventually gets smooth. Hence why I think I get the point why it should take 4 hr minimum. Are you saying that’s how it should feel and therefore that’s why you need a super long block? I honestly feel this is correlated with sleeping properly cuz then I have the energy to overcome this activation energy. Is this usually how most productive engineers view productivity and how the focus block fits in?

I'm a lifelong Windows user, with a bit of Linux/Ubuntu experience as well. Now that I'm at a Big Tech company, I'm using Mac. I feel like all the Big Tech companies use Mac. Does anyone have tips for getting adjusted? Big important things to know would be great. Here's my first idea: instead of using my Windows keyboard, I'm going to use the MacBook as my primary display and therefore use the mac keyboard as my keyboard. This will force me to use the native mac keys (Command, Option, etc) rather than the Windows equivalents. Thanks! EDIT: after spending a day on Mac, I think I got the hang of it. It's not too different, some of the key combos are different, but I think that's about it.

Hi Taro Community, I joined Microsoft in February, and interestingly, my manager started just a month later in March. As we’re both relatively new and navigating uncharted areas, I felt the need for more structured technical guidance. During a recent one-on-one, I suggested the idea of having a mentor or a designated technical point of contact. Initially, my manager acknowledged this need and planned to discuss it further up the chain. However, the feedback I received later was that since we are in the process of building a new team here in India, we should first attempt to resolve issues internally. Subsequently, for additional insights, I’m advised to engage with the chat group, which includes around 100 members. Here’s where I find myself in a predicament: My manager, being new himself, sometimes faces similar uncertainties, which complicates our internal resolution approach. Posting in a large group specific guidance doesn’t always yield practical advice due to its broad focus. Any insights on managing these dynamics or personal experiences would be incredibly helpful as I look to establish myself and contribute effectively in my new role. Thank you for sharing your thoughts and experiences.

I was given the task to scope out some tickets for next year and to assign time estimates to them. How should I go about doing this? I have 4 tickets to time-estimate. At a high-level, I'm thinking that I should be working to decompose the tasks down to simpler parts which should also be simpler to estimate. But how granular should I go into decomposition? Looking at my (more experienced) colleagues' work on estimating their tickets, there estimates for their tickets are anywhere from 1 to 4 weeks. They also jotted down a few bullets on assumptions and some of the decompositions involved. So decomposition I would guess is step 1. Before I even do that though, maybe I should be speaking with the stakeholder assigned to the ticket so I can get a better understanding of what's involved. So I need to a) talk to stakeholders; b) decompose the ticket into chunks; c) come up with an overall time-estimate. Did I leave anything out? The fundamental challenge here is that it's hard to predict the future and know how long something will take before doing it. Thanks!

I'm a Data Engineer at Instacart. Every day, I get a lot of emails relating to PRs that are up for review or have been reviewed and are being merged. I'd estimate ~30, but prob as high as 50 some days. The emails can come from my anyone on my team (~10 other people) or department (probably ~30 other people). My strategy for dealing with these until now has been to only look at and review code that comes from 4 other individuals. These 4 people are the ones who I work most closely with. I asked my manager about doing code reviews for anyone else and he said to just stick to the core 4 other people I work with (including him), which makes sense given that I have plenty of work to do and those 4 other people produce a fair number of code reviews to do. My question is, is there any value in me receiving emails for all those other people in my department who's code I don't care about (at least for now)? Should I try and either unsubscribe from or auto-archive their emails so I don't have to delete/archive those emails every time I access my inbox? Just wondering what people's strategies are for this. Thanks!

Ex-FAANG employee here. I successfully switched firms recently and purposefully down-leveled myself (went for mid-level position instead of senior) since I felt I might be burned out, resulting in a lower pay as well. Though I guess in hindsight I could have handled the pressure. But no regrets there. I'm still on initial 6 month probationary period in new firm but now few hedge fund and HFT recruiters have presented an opportunity that seems like too good to pass. The role is exciting and potential pay is substantial. The roles are limited and usually fill up fast since many folks apply for these. I believe I can crack the interviews if I just can dedicate a good amount to the interview prep work. However, given that I have started new job, I find it difficult to focus on both interview prep and full-time office work. I kind of don't want to put my eggs in one basket and just focus on the interview prep cause I fear if I don't make it through, my lacking performance might lead to a firing at current role itself and the job market is already pretty rough. Yet, the present opportunity is something I do feel like giving it my best. Hence, I do want to learn how folks manage to balance job hunt whilst performing at current jobs as I feel I kind of get overwhelmed easily by the prospect. Working 8-9 hours a day at job and then another 4-5 hours on interview prep just feels mentally exhausting. Any tips or suggestions here to help ? How do I evaluate my limits and then learn to overcome them in time ?

I am thinking of setting up mentorship office hours, to help guide juniors on how to create artifacts that can be approved quickly. What I think will help others Help speed up other engineers Help make speed of delivery and change an organizational and company asset. What I want to get out of it skill wise Get better at reading code and docs of others whose work I am not too familiar with. Question Am I being an optimistic idiot?

I’m working on a side project in my free time—completely unrelated to my day job—and I’d like to gather user feedback on the proof of concept. I’m also planning to invite people to join a waitlist for its potential launch. The project doesn’t use any company resources or knowledge, but I’m wondering: Should I check with my manager before posting about it publicly (e.g., on LinkedIn)? If the project starts to gain traction and I decide to monetize it, do I need to formally disclose this to my manager? If so, how should I approach that conversation? Thanks in advance for any advice you can share!

Background I have joined a new company recently and was tasked with building a Task Management System ( for clients and internal Employees ). So in short this software is going to be re-iterated again and again for improvement after we launch its first MVP ( targeted 2 months at max ). ### Scenario I have come across a use case where I want to handle errors using a custom error handler, its a function to which I pass any error thrown my APIs and based on error type ( error code a reference from prisma docs ) it returns a specific structured error response that can be useful for frontend devs and also help debug better. ### Question Is going this far for handling many errors worth it, i was recently listing to Alex for the Code Quality Course and what i understood its worth it as it would help me and my juniors debug better while in production and local development as well. ### Tech Stack Prisma ORM, Postgres, NextJS

I'm a software engineer currently working on a dynamic page that replaces a more static, hardcoded version. The issue is that much of the existing code was written with a "just make it work" mindset — hardcoded values, minimal abstraction, and very few edge cases handled. Now that I'm trying to do things properly and account for various scenarios, I'm running into situations that weren’t considered before. When I raise these edge cases or try to clarify requirements, I feel like I'm coming across as scattered or overly concerned with "what-ifs." It’s starting to feel like I’m that person who overcomplicates things, when in reality I’m just trying to build something maintainable and future-proof. Has anyone dealt with a similar situation? How do you raise valid concerns and push for better practices without seeming like you're overthinking or slowing things down?

I currently work as a contingent work at Big Tech company On my resume I just list the name of the Big Tech company I'm at, but it's through an external consulting firm. Reading prior taro discussions I do believe I embody the culture of the company im at, i even work in person and have similar scope/work to my teammates who are FT employees In my resume I only list the company name and have not mentioned it is a contract role. I get way more callbacks this way Q: When should I reveal to the hiring team that it is a contract role? How does this play in background checks?

When you do a behavioral interview in the middle of a project you're owning or mentoring someone through, there isn't realized impact but small nuggets that give confidence that it could land. This is assuming full impact of the work takes months to accumulate in practice. This leads to Results from STAR feeling like it will almost get there, but it won't quite land the same as getting it done before the interview date. Take this example: I give a junior (and the rest of my team for that matter) scripts to abstract away common daily debugging and maintenance. I showed this junior engineer how to problem solve (what questions to ask themself: how to check kafka lag to debug performance bottlenecks). He works on a complex project and asks me for nuanced help now instead of basic questions. But he is 3/4 of the way there to get it to production. Am I in a disadvantage of sharing stories like this where the actions in a vacuum seem reasonable and high signal, but aren't backed by a result now, but 3 months later? My guess is just show projected impact and intermediate impact in R section of results.

Interview Prep Question Has anyone ever asked about solutions engineer vs. SWE? I have heard so many different things about interviews here - that you do NOT need to do whiteboarding and DSA (AI startup series B) for a TPM/solutions architect type of role, vs. you DO need to do DSA for a TPM role at an YC-backed early stage AI company. #### Type of Role Lots of my friends are also solutions architects/engineers and PM types and have recommended I try that as a role instead of TPM (product has too many politics they say), or SWE (too boring being just a regular IC if you have business/PM skills that doesn't let you utilize other soft skill strengths I may have). #### Comp I know that it tends to have a bad rap bc of lower pay, customer success or client facing etc. I also have heard the opposite (that it pays more). Thoughts?

I have weekly meetings with leadership, and they consistently ask more about our timelines and engineering work, which I understand we need to provide. Having said that, what are some of the questions we engineers can ask leadership/product to hold them accountable for some of the requirements? What are some of the customer-centric questions we could ask?

Would you count scope expansion as more than just asking the team if i can build 3 extra features that are related to the original project? I am interpreting it as way more than building those 3 extra features beyond what the scope of the project is. And even if i do that, it might even be a net negative unless it really matters. My understanding is it has a larger area. It can also be building monitoring or alerting tools as part of my project, or even doing some janitor work on the surrounding code, or even addressing areas that got missed when the plan was put in place. Am I on the right track? The confusion is stemming from the idea that cleaning up gaps seems like a walk of shame due to rework, not a true scope expansion.

According to the dynamic that taro defines as senior the senior scales impact across 4-10 people? How can 3 senior engineers scale impact across the 2-8 junior or mid level engineers? That sounds like too many cooks in the kitchen. But I also hear the opposite is classic scarcity mindset and this isn’t Ivy League admissions for L4-L5 at top tech companies where 3 mid levels clear the next level bar consistently but only one can make it and the others are stuck until they switch teams or get put on a pip. Abundance mindset is key here so I am missing something. Any insights would be really helpful.

Does anyone have slides of . I went through the course but I want to quickly revise the important things but don't have enough time to go through videos again.