Career Lessons for New Software Engineers

A collection of learnings from my 15-year Software Engineering career at companies like Meta, Pinterest, and Walmart. 1. To learn how to code, you must write code in an unstructured environment. Tutorials can help initially, but don't get stuck in tutorial hell: these engineers can't actually solve problems. 2. The only way to learn how to write good code is to write a bunch of terrible code first. It is fundamentally about the struggle. 3. Debugging is effectively playing a game of detective. Becoming an expert debugger in a large, complex codebase will make you extremely valuable to any company. 4. For software engineers, most of what you learn in school won't be relevant on the job. The biggest value of a university education is your network. Invest in getting to know students and faculty. Don't worry too much about grades. 5. Networking is about building long-term relationships built on trust and value. Give more than you take and your network will grow rapidly. Remember this phrase: "Your net worth is your network." 6. Everyone in tech faces imposter syndrome. Consider imposter syndrome as an opportunity to learn from people who are further along. Actively seek out feedback and talk to people. 7. Tech interviews are immensely broken and your interviews will probably differ from your job. View interviews as a learning opportunity where you get to meet some other cool, smart people. 8. Realize that the average person will spend < 10 seconds scanning your resume. No one is as interested in you as you, so you need to keep things short. Your resume should be 1 page long. 9. Feedback is the secret to rapid career growth. Make it easy for others to give feedback by introspecting and asking for specific parts of your behavior. A lazy “Do you have any feedback for me?” will often be met with a similarly lazy “Nope, you’re doing great!” 10. If you're not sure what company to join, go to a larger, well-respected company (FAANG) as your first job. Junior engineers benefit from the consistency and stability of Big Tech. 11. Onboarding is a magical time when you get a free pass to ask as many questions as possible, request people's time, and build foundational relationships. Work with a sense of urgency when you're new to a company. 12. The relationship with your manager is the most important relationship you'll have in the workplace. You should proactively drive meetings and feedback with your manager; don't wait for them. 13. Getting promoted as an engineer is not just about skill or output. You also need scope and trust. Most promotions are deliberately planned months in advance. If a promotion is important for you, bring it up with your manager well in advance. 14. Most engineers don't negotiate their offers, but they should. The most important tool for negotiation is leverage. This means competing offers. I put this all together in a 1.5-hour video here: https://lnkd.in/gAH4Q2pD

10 things I wish I could tell my younger engineering self. That would have accelerated my career by years. 1.Technical excellence alone won't get you promoted. Visibility matters as much as ability. Document your wins, communicate your impact, and make your contributions visible to decision-makers. 2.The team you join matters more than the company. Great managers accelerate your growth. Toxic ones stunt it. Choose your boss, not your brand. 3.Being the smartest in the room is overrated. Making everyone around you smarter is what creates real impact and recognition. 4.Learn systems, not just languages. Technologies change yearly. System design principles last decades. 5.Code reviews are career opportunities. They're not just about catching bugs. They're chances to demonstrate how you think and influence architecture. 6.Most career growth happens between 5pm and 9am. The side projects, the learning, the networking - these after-hours investments compound dramatically. 7.Clean code isn't about aesthetics. It's about empathy for those who will maintain it after you're gone. 8.Career capital comes from solving hard problems. Seek out the challenges everyone else avoids. That's where your value multiplies. 9.Relationships determine opportunities. Technical communities, not just technical skills, create career options. 10.Your mental health is a technical requirement. Burnout isn't a badge of honor. It's a systems failure that compromises your most valuable asset - your mind. I can't go back in time. But maybe you can avoid these lessons the hard way.

If you're in your 20s as a software developer, here are 21 rules to remember to become an amazing engineer when you hit your 30s. I was ‘YOU’ once. These are lessons nobody taught me, but they came with experience that helped me make a strong impact at Microsoft with my team. 1. Don’t get too attached to your own code; stay open to improvements. 2. Complexity will come back to haunt you during on-call rotations. 3. Aim to resolve underlying issues, not just the surface symptoms. 4. Remember, users care about the functionality, not the elegance of your code. 5. Keep track of design decisions and document them for future reference. 6. Every piece of code you write adds maintenance risk—think twice. 7. Software is a continuous process; it’s never truly “done.” 8. Make sure you fully understand the problem before jumping into solutions. 9. Write clear and informative commit messages for your future self and others. 10. Avoid adding dependencies that aren’t essential to reduce potential issues. 11. Code reviews are a great way to share knowledge within the team. 12. Every choice in code is a compromise; weigh the pros and cons. 13. Remember that an estimate is not a guarantee. 14. Release early and refine often; iteration improves quality. 15. Following coding standards helps avoid unnecessary debates. 16. Design with future maintenance in mind to save effort later. 17. Everyone has a hard time understanding code they didn’t write. 18. Don’t hesitate to ask for assistance when you’re stuck. 19. You’ll always be learning something new in this field. 20. Simplicity in design pays off in the long run—don’t overcomplicate. 21. Don’t assume your first solution is the best; iterate and refine.

I am a Software Engineer at Meta with almost 2 decades of experience. Here’re the 5 learnings if you want to grow faster as a SWE: 1. Know the next level before promotion After you are performing well at your current role expectations, start approaching the next level. - Learn from seniors, understand their perspective - Look for areas you can help & can get noticed In short, prove that you deserve the promotion before you ask for it. 2. Become your own user - go on reddit or twitter threads - read through the users feedbacks and conversations - be empathetic & maybe have a conversation with few users This shift helped me move beyond just shipping features to actually improving the experience. 3. Data is your saviour Start diving into logs, events, and exceptions more deeply. - Where are users spending the most time?  - What’s making them drop off? - What are the most common exceptions?  - Which workflows are unintuitive? You can make better engineering decisions if you spend some time consuming the data 4. Every problem is not yours to solve Ask yourself: - Is this issue truly high-impact, or am I just trying to get it off my plate? - Is this a problem I should solve, or is it better to guide someone else to take it on? - Delegating was tough at first. But it’s crucial to identify your problems and delegate rest. The best engineers I’ve worked with aren’t the ones who take on the most work—they’re the ones who ensure the right work gets done by the right people. 5. Be a force multiplier - document more to save others time - build tools and scripts that automate tedious tasks - Guide others to help achieve their goals   Your team will move faster, and you will become more valuable—not just as an engineer but as a force multiplier. => Final Thought: The biggest shifts in my career didn’t come from just writing better code—they came from these small shifts. If you’re looking to grow as an engineer, try incorporating some of these steps into your own journey. Raman Walia

Confessions and Reflections of a Senior Engineer at Microsoft after 7+ years in the industry: 1. The hardest code to read is always your own code from six months ago. 2. Perfect code is a myth. Quick, honest fixes matter more. 3. Debugging is about fixing what broke, not blaming who broke it. 4. Tools change every year, but real problem-solving never goes out of style. 5. The best engineers aren’t the ones who know everything. They’re the ones who know where to find answers fast. 6. Good documentation is a lifesaver. Your future self will thank you. 7. “Temporary” solutions stick around forever. Do it right if you can. 8. Most tech skills can be learned. What matters is your willingness to ask for feedback, accept it, and continue to improve. 9. Taking initiative is rare. People who fix things that “aren’t their job” stand out. 10. Writing lots of code is good, but knowing which problems matter is better. 11. Engineering isn’t a solo game. Building trust and working well with others is just as important as writing code. 12. Every team needs different strengths, builders, fixers, specialists, and big-picture thinkers. Respect them all. 13. Get feedback, act on it, and repeat. That’s how you actually grow. 14. Luck matters, but hard work and showing up everyday matter more. 15. You don’t need to be a genius. You need to be curious, consistent, and willing to keep going when it’s tough. What’s the simplest lesson you’ve learned in your engineering journey?

Two months into Amazon, I've learned more about working at big tech than 4 years of getting here taught me. A lot of people DM me asking about my experience at Amazon and what they should focus on when they join their first "real" job. Here are my top 7 lesser-talked-about lessons: 1/ Your impact > Your hours I used to think working late meant working hard. Then I got paged during an outage at 2 AM and realized: it's not about how many hours you're online, it's about solving the right problems. Ship value, not activity. 2/ Documentation is your best friend I learned this the hard way. When you're working across teams and time zones, nobody's going to remember what you said in a Slack thread 3 weeks ago. Write it down, make it searchable, and your future self (and your teammates) will thank you. 3/ Ask questions early, not after you're stuck I used to wait 2 hours trying to debug something alone before asking for help. Now, if I'm stuck for 15 minutes, I ping someone. Nobody thinks you're dumb for asking. They think you're smart for unblocking yourself fast. 4/ Say no to protect your yes Everything feels urgent in big tech. Someone always needs something "real quick." But if you say yes to everything, you dilute your focus. Protect your priorities. Say no to things that don't move your core work forward. 5/ Feedback is data, not criticism I used to take feedback personally. Now I see it as a signal. If my teammates, say, my design doc needs more clarity, that's not a judgement, it's information I can act on. Don't make it personal, but use it for your upskilling. 6/ Work friends ≠ Real friends Be professional. Be kind. But don't overshare. Office dynamics change, and there are many circumstances that might change. Keep some boundaries. 7/ Systems > Speed At Amazon, I'm learning to build systems that scale. Fast is good, but fast and repeatable is better. Automate what you can. Document what you can't. For 19-year-old me in India, Amazon was the impossible dream. Now I'm here, and I'm realizing: getting in was hard, but in reality, staying sharp, learning fast, and building the right habits are the real work you need to focus on. What's one lesson from your job that nobody prepared you for? #amazon #lessons #life

20+ Years in Tech: Lessons That Shaped My Career As I look back on two decades in engineering and leadership, I’ve realized that career growth doesn’t come from a single breakthrough. It comes from a set of habits that compound over time. Here are the lessons I wish I had learned earlier: 1. Ownership is the real differentiator Titles and roles matter less than whether people trust you to move problems forward. When you own outcomes beyond your scope, opportunities follow. 2. Clarity outlasts volume Loud voices may win meetings, but clear, structured thinking is what people remember. A simple framework delivered at the right moment will take you further than noise. 3. Curiosity keeps you relevant Every turning point in my career came from learning a new skill, exploring an unfamiliar space, or embracing a new wave of technology. Reinvention is a career-long habit. 4. Relationships multiply results Building trust across functions often has more impact than individual effort. Careers are accelerated by the people who vouch for you when you’re not in the room. 5. Mechanisms matter more than good intentions Processes, documentation, and repeatable habits create consistency. Mechanisms are what make leadership scalable. 6. Resilience is underrated Setbacks are part of every career. What matters is how quickly you reset, learn, and move forward. A tough moment often plants the seeds for the next big step. 7. Strategic risk-taking pays off The biggest leaps in my career came from saying yes to roles and problems that felt bigger than me at the time. Growth rarely lives inside your comfort zone. 8. Balance is fuel, not a luxury Burnout doesn’t create lasting success. Knowing when to sprint and when to recover is what makes a career sustainable. 9. Manage up with empathy Influence is not just downward. Learning to align with leaders’ priorities and communicate in ways that make decisions easier is a skill that changes the game. Looking back, the common thread is this: careers are not straight lines. They are built on choices, resilience, and the willingness to keep learning. What career lesson do you wish someone had told you earlier? #CareerGrowth #Leadership #EngineeringLeadership #FutureOfWork #MetaShift

In my 20+ year career in Software Engineering, I’ve been an IC, a VP of Engineering, and now CEO. Here is what I tell  engineers who struggle to choose the right career path: 1. Soul search You have to be honest with yourself – do you want to go down the managerial path or continue being an IC? Either way is fine. Today, any good company values both tracks, and there’s no longer a need to move into management to progress in your career. 2. The modern IC path If you want to stay as an IC because you thrive in technical challenges and innovation, you can still rise to senior levels – some companies have ICs at VP, SVP, or even Fellow roles. This way, you can stay hands-on and do what you love most without the responsibilities of managing a team. 3. The managerial mindset The role of a manager goes beyond being the “smartest engineer” with people reporting to them. Managers need credibility, but more importantly, they need empathy and a mindset shift. The question becomes: "How can I bring out the best in my team?" rather than "How can I be the best engineer?" 4. The unseen work of management If you want to be a manager, understand that 90% of your work will be invisible to your team. You’ll be in meetings, managing schedules, and coordinating across departments. You’re there to unblock your team so they can do their best work. These accomplishments may be invisible, so you might go home some days wondering, “What did I really accomplish today?” That’s normal. 5. Test the waters If you’re curious about management, test the waters before you commit. Start as a lead engineer. Mentor a couple of people and see how you guide them through challenges. Great companies support new managers with training and mentorship – if your company doesn’t, seek support outside or be prepared to learn the hard way like I did.  Early on, I thought I had to be the smartest person in the room. However, my mistakes and guidance from mentors quickly taught me that real leadership is about empowering others, not proving yourself. 6. Cultural fit and company support Some companies support managers and value leadership qualities. They know that a great manager is there to build teams that can find solutions (not to have every answer themselves). And they contribute to the company’s bottom line and top line by bringing out the best in their teams. Final thoughts: Today, both paths can lead to a fulfilling career. I know successful ICs who built incredible careers without managing a single person. I also know outstanding engineering leaders who value helping everyone become the best version of themselves. So ask yourself: Who do you want to be, and what drives you?

My LinkedIn tells you that I am a successful engineering manager working at Google & living the dream but here’s what it won’t tell you: ► Back in 2008, after completing my masters in the USA at Cornell University, I  was unemployed for 9 months.  ► I was rejected by Microsoft, 5 times (2 times in the same year & 2 different countries)    ► Startups turned me down because I couldn't write a Binary Search Tree.  ► Google rejected me because I couldn't explain how Hadoop works.  ► When I finally landed a job, I was told: "You’re not good enough to be a software engineer."  I broke production code. Multiple times.   As an architect, I built a product that didn’t scale.   As a new manager, two engineers quit my team—because of me.  But my biggest failure?  ► I caused a million-dollar outage at Amazon.   Millions of users were impacted.   Amazon.com went down for five minutes.   And I was the reason.   3 Lessons from my journey to help you become a TOP engineer: ✅ 1. T : Talent is overrated and You will fail. Accept it, but don’t stop.   - Every engineer screws up. The difference is who keeps going and learns from it.   - Your failures won’t define you, what you do after them will.  ✅ 2. O : Own your mistakes as Writing code is easy.    - It’s easy to blame deadlines, bad specs, or teammates.   - Great engineers take responsibility, learn from failure, and improve.   - No one remembers your mistake forever. But they will remember how you handled it.  ✅ 3. P : Problem solving is permanent. Knowledge is temporary.   - You won’t always know the answer. You’ll forget concepts.   - What matters is your ability to learn fast, debug effectively, and think through problems.   - The best engineers aren’t those who know everything, hey’re the ones who figure things out.  Failures aren’t career-ending. They’re career-defining.  So, fail, learn, and keep building. 

𝐓𝐡𝐢𝐧𝐤𝐢𝐧𝐠 𝐨𝐟 𝐲𝐨𝐮𝐫 𝐜𝐚𝐫𝐞𝐞𝐫 𝐚𝐬 𝐚 𝐥𝐢𝐧𝐞𝐚𝐫 𝐬𝐜𝐫𝐢𝐩𝐭 𝐢𝐬 𝐚 𝐛𝐮𝐠. It’s actually a 𝐝𝐢𝐬𝐭𝐫𝐢𝐛𝐮𝐭𝐞𝐝 𝐬𝐲𝐬𝐭𝐞𝐦 𝐩𝐫𝐨𝐛𝐥𝐞𝐦 requiring high availability and fault tolerance. I realized that choosing a specialization in tech—be it Cloud Architecture, DevOps, or Full Stack—follows the same heuristics we use for 𝗦𝘆𝘀𝘁𝗲𝗺 𝗗𝗲𝐬𝐢𝐠𝐧. Here is the breakdown of the "𝐂𝐚𝐫𝐞𝐞𝐫 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞" protocol: 1. 𝗗𝗮𝘁𝗮 𝗜𝗻𝗴𝗲𝘀𝘁𝗶𝗼𝗻 (Know What You Like): Just as we analyze logs to understand system behavior, analyze your history. What topics do you advocate for during lunch? What GitHub repos do you star? This is your baseline telemetry. 2. 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 𝗣𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 (Heatmaps): In the sketch, I drew a heatmap matching "Good At" vs. "Like." In engineering terms, this is finding the sweet spot between 𝗧𝗵𝗿𝗼𝘂𝗴𝗵𝗽𝘂𝘁 (volume of work you can handle) and 𝗟𝗮𝘁𝗲𝗻𝗰𝘆 (how much drag you feel doing it). 3. 𝗧𝗲𝗰𝗵𝗻𝗶𝗰𝗮𝗹 𝗗𝗲𝗯𝘁 𝗔𝘃𝗼𝗶𝗱𝗮𝗻𝗰𝗲 (The 'Yuck' Stuff): This is crucial. Just because you are efficient at cleaning up messy legacy code doesn't mean you should specialize in it. If a task has high proficiency but low satisfaction, it represents future burnout—essentially, 𝒄𝒂𝒓𝒆𝒆𝒓 𝒕𝒆𝒄𝒉𝒏𝒊𝒄𝒂𝒍 𝒅𝒆𝒃𝒕. Deprecate these tasks early. 4. 𝗘𝘅𝘁𝗲𝗿𝗻𝗮𝗹 𝗔𝗣𝗜 𝗖𝗮𝗹𝗹𝘀 (Ask the Big Kids): Don't rely on cached data. Poll external nodes (Seniors, Principals). Ask about their daily stack, their leadership exposure, and their context switching overhead. 5. 𝗧𝗵𝗲 𝗖𝗔𝗣 𝗧𝗵𝗲𝗼𝗿𝗲𝗺 𝗼𝗳 𝗖𝗮𝗿𝗲𝗲𝗿𝘀 (Pick 2 & Look Closer): You usually have three metrics: 𝗟𝗲𝗮𝗿𝗻𝗶𝗻𝗴, 𝗙𝘂𝗻, and 𝗣𝗮𝘆. It is rare to get strong consistency across all three immediately. Analyze your "Career Castles" (A vs. B) and decide which trade-off is acceptable for this specific epoch of your life. 6. 𝗥𝗼𝗹𝗹𝗶𝗻𝗴 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 (Start): Analysis paralysis is the enemy of uptime. If the metrics are close, deploy the instance that you are leaning toward. You can always rollback or re-architect later. Your career isn't a waterfall model; it's agile. Iterate often. Don't worry about a path not working out, you can always roll back :) #CareerPath #SystemDesign #SoftwareEngineering #TechCareers #Sketchnote