1. Wiki
  2. /Work
  3. /Career


The fastest career growth comes by finding work that aligns with both your interests and what matters most to the company.


  • Dropbox Engineering Career Framework
  • Interview Questions to Ask Your Interviewer #interviewing
  • Finding your leadership style
    • A few helpful questions that one can ask themself to identify their leadership style.
  • Managing people 🤯
    • Not sure how I feel about this one. Not very insightful and I disagree with some of the points.
  • Help Your Teammates Navigate Moments of Self-doubt
  • How To Criticize Coworkers
  • My guiding principles after 20 years of programming
  • Levels of Technical Leadership
  • Tech Dept
  • The Code Review Pyramid
  • The unreasonable effectiveness of one-on-ones
  • How Google, Twitter, and Spotify built a culture of documentation
  • Prioritization as a Superpower
  • Maximizing Developer Effectiveness
  • Operating well – what I learned at Stripe some take-aways from Sam Gerstenzand's time at Stripe.
    • Operating well is a state, not an outcome. It's constant process of tweaking, iterating, and tuning.
    • "Turn up the heat in every interaction and ask uncomfortable questions." - ask uncomfortable questions.
  • Engineering Levels at Honeycomb: Avoiding the Scope Trap
  • Things they didn’t teach you about Software Engineering
  • Project Management for Software Engineers
    • Initiation - Initiating a project means recognizing that a new project exists and clearly setting out the scope, deliverables, and expectations.
    • Planning - After initiation comes planning — clearly defining the work breakdown, roadmap, and project plan. Most project plans involve some form of Gantt chart or roadmap, though I would suggest tailoring this to your company needs if you are working in a more “agile” setting.
    • Execution - During this phase, the project team spends most of its time completing work, coordinating with people, helping to ensure quality work, keeping track of resources, and updating stakeholders.
    • Monitoring and Control - In parallel with execution, the project team tracks the progress of the project based on the original project plan. This includes tracking the schedule, budget, and scope of the project to make sure it is on track.
    • Closure - Closing a project involves the delivering final results, measuring success, and compiling lessons learned for future projects.
  • Recognition and rewards at work
  • Brag now, remember later: Document your accomplishments
  • DevOps culture: Westrum organizational culture
    • Good culture that optimizes information flow is predictive of good outcomes
    • High cooperation - Create cross-functional teams that include representatives from each functional area of the software delivery process (business analysts, developers, quality engineers, ops, security, and so on). This practice lets everyone share the responsibility for building, deploying, and maintaining a product. It's also important that there is good cooperation within the team.
    • Train the messengers - This means we want people to bring us bad news so we can make things better. Hold blameless postmortems. By removing blame, you remove fear; and by removing fear, you enable teams to surface problems and solve them more effectively. Also create and foster an environment where it is safe to take smart risks and fail, so that anyone can surface problems at any time—even without the ceremony of a postmortem.
    • Share risks - Along with this, encourage shared responsibilities. Quality, availability, reliability and security are everyone's job. One way to improve the quality of your services is to ensure that developers share responsibility for maintaining their code in production. The improvement in collaboration that comes from sharing responsibility inherently reduces risk: The more eyes on the software delivery process, the more you'll avoid errors in process or planning. Automation also reduces risk, and with the right tool choice, can enable collaboration.
    • Encourage bridging - Break down silos. In addition to creating cross-functional teams, techniques for breaking down silos include co-locating ops with the dev team; including ops in planning throughout the software delivery lifecycle; and implementing ChatOps. Another tip is to identify someone in the organization whose work you don't understand (or whose work frustrates you, like procurement) and invite them to coffee or lunch. Informal discussions help foster better communication, and you may understand why they do what they do—and you can come up with creative solutions together.
    • Let failure lead to inquiry - Again, hold blameless postmortems. The response to failure shapes the culture of an organization. Blaming individuals for failures creates a negative culture. If instead, failures lead you to ask questions about what caused the failures and how you can keep them from happening again in the future, you've improved your technical system, your processes, and your culture.
    • Implement novelty - Encourage experimentation. Giving employees freedom to explore new ideas can lead to great outcomes. Some companies give engineers time each week for experimentation. Others host internal hack days or mini-conferences to share ideas and collaborate. Many new features and products began this way. When you release your employees from habitual pathways and repetitive tasks, they can generate enormous value for your organization. And remember that novelty isn't limited to new products and features. Also encourage and reward improvements in process and ideas that help foster collaboration.
  • Motivating Developers to Care About Documentation
  • 10 Tips for Running Engineering Meetings on Zoom
  • Make haste slowly: quantify economics - how to priortize features
  • What Is Negative Engineering?

    Negative engineering is the time-consuming and sometimes frustrating work that engineers undertake to ensure the success of their primary objectives.

  • Career Cheat Codes I Know at 36 That I Wish I Knew at 26
  • Burnout
  • How to make difficult technical decisions you and your team won't regret
    • What is the cost of making the wrong decision?
    • What is the ramp-up time of the decision? E.g. do you have early adopters you can try with?
  • Mastering Programming by Kent Beck
  • How do I make sure my work is visible?


  • How you can ~1.5x your salary through negotiation
    • Always start by asking for salary range (when being hired)
    • Approach the negotiation as a conversation, not negotiation
    • Seek leverage:
      • Get other offers
      • Line up other interview as a future leverage
      • Make the company really want you by excelling in the interviews (prepare for them, consider it an investement)
      • Sometimes the leverage doesn't need additional work: the company needs you to sign quickly, the company doesn't want to loose you, the company wants you to be invested, etc.
    • Negotiation isn't just about salary base: additional equity, signing bonus, relocation bonus, extra time off, etc.

Software Engineer


Senior Software Engineer


  • Connect the dots between engineering and revenue


  • A Senior Engineer's CheckList
  • An incomplete list of skills senior engineers need, beyond coding
  • What Makes a Senior Engineer? Writing Software vs Building Systems
    • Defining Requirements - work with the Product Manager to understand what problem they want to solve; maybe you’ll have some ideas on how to solve it with much lower effort?
    • Defining NFR’s - talk to your PM about the non-functional requirements - how many users should the System handle, what are the requirements for performance, throughput, latency? Are there any security or compliance considerations? Do we need auditing? What’s the desired availability?
    • Planning Iterations - work with your team to propose an implementation plan; make sure you define small, demoable milestones, so that you can start delivering value ASAP; agree with the PM on the milestones.
    • Determining Dependencies - make sure you identified all the dependencies outside of your team and work with your EM or with the teams directly to get some ETA’s for them. Adjust your milestones accordingly.
    • Testing - depending on how your company operates, decide on your testing strategy with your team or with the QE team. Agree on the quality threshold needed for the rollout (e.g. no unresolved Major bugs or test coverage above X%).
    • Deployment - work with your team to decide how the system will be deployed. Do you need some new infrastructure for it or can you reuse the existing? If you need a lot of it, what will be the cost?
    • Observability - decide how are you going to monitor the health of the system and set up processes for solving production issues (e.g. team on-call). Use a third-party solution (like Sumo Logic) to set up monitors and dashboards for that purpose.
    • Rollout Communication - once you agree on a rollout date with your team and the PM, make sure that all stakeholders are aware of it. Check whether any documentation changes are required.
    • Measuring Success - decide on metrics that will tell you whether the project was a success. Is anyone using the new system? Do users manage to accomplish their tasks? You can leverage your Observability suite for this purpose.
  • The Senior Shift
  • Path to Senior Engineer handbook
  • How to find great senior engineers #interviewing - some suggestions for interview:
    • "What important truth do very few people agree with you on?"
    • The Three Why's - similar to what one would do during incident analysis, ask why multiple times to press for more nuanced answer
    • Use case-studies. You lay out particular technical scenario and ask the candidate to figure out what they would do

Staff Engineer


Setting technical direction: providing vision for long-term technical development of specific area, e.g. API design.

  • getting people from vague sense of "getting better" to clear idea of what "better" is and why

Mentorship & Sponsorship^1: sharing experience and advice along with understanding the recipient's context.

Providing engineering perspective: self descriptive.

Exploration: being assigned on new or burning topics to quickly iterate on finding a solution (or failing to do so which is fine as well).

Being glue^2: doing the needed but often invisible work to keep the gears turning.

  • Timeframes get longer with higher titles, early on in the career the development cycle can be within weeks or months. In senior roles it shifts to months, quarters, or even longer.


Engineering Manager


VP of Engineering