Career

Escaping the Local Maximum: Hill Climbing and Paying Debts

December 27, 2025 Career, Personal, Success 2 comments

I would like to talk about something that might be hard to accept and might trigger the feeling of regret but that’s an important topic we must entertain in our brains. Ask yourself a question: If you are climbing a hill right now, is that the highest hill you are capable of climbing?

In computer science, a Hill Climbing algorithm can get stuck at a Local Maximum, a peak that is higher than everything immediately around it, but significantly lower than the highest possible peak, called the Global Maximum. To reach the Global Maximum, you first had to walk down the hill leaving comfort, taking risks, and crossing the valley of uncertainty to reach the right hill and then climb again.

I have climbed too many local maximum hills in my life. The most prominent was my time at the United Nations (IAEA) in Vienna, Austria. UN is a highly prestigious place to work, offering a tax-free salary, numerous perks, that might include education subsidy, extra long paid vacations, great pension payments, etc. If you get high enough you even get a diplomatic passport and be treated as a VIP anywhere in the world. Life in Austria is very stable, you get an incomparable quality of healthcare, and a great free education for kids. It is just the pinnacle of stability and quality of life you can get in central/western Europe.

One of the interesting aspects of working there as a software engineer was that I had to read some very old code. There were not many people I could consult about that code, as the people who wrote it have either retired, or…  died. I recall my interactions with much older colleagues at work and this made me realize that that place, while very prestigious and comfortable is exactly that – way too comfortable. A place to work towards your retirement, not the place to thrive and grow.

The problem is that you cannot realistically climb any higher. Even if I were to spend a good 10 years to reach a director level (unlikely) I would still be limited by “Noblemaire Principle” and my income and net worth, despite being very high in comparison to other salaries in Austria, will grow very linearly. Just to pull some numbers, a director at UN would probably make just <200K$ net, when a senior engineer with just a handful of years of experience at FAANG in the US would be taking home (after tax) a lot more than that. In a summary: D1 at UN is the peak of that specific hill. Hard to get, hard to maintain, capped upside. When merely L5/L6 at FAANG is still close to the base of a gigantic tech hill that is almost uncapped upside.

Moving to Canada, going through years of uncertainty (another immigration process), was my climbing down of the Local Maximum hill only to climb a bigger hill. In a way that was paying “Immigration Debt” in the valley. I worked for Amazon for a good 2.5 years and after switched to Google, which was a great boost to my income and career trajectory. Unfortunately I was still climbing the wrong hill out there. Yes, a lot bigger than the previous hill, but still not the biggest hill on the horizon. At the same time, gaining more certainly by becoming Canadian was my walk along the valley and staying at the “base camp” for a period of time just to get to the next big hill more comfortably.

The debt is not always just temporary paycheck cuts or discomfort of moving, sometimes the debt comes in the form of relationships. I had my university friends back in Ukraine, and my connection with them slowly and gradually decreased as I moved to Austria. These days we don’t even wish each other happy birthdays. The same happened when I moved to Canada. I still have a base of good friends in Austria, but the timezone difference made it challenging to keep the connection. When I visited Austria two years ago it was great to meet all of them, but unfortunately that’s the high price I am paying for moving around. The same has happened again by moving to the US, some friends are just north across the border. I have friends everywhere but the depth of connection is dissolving.

I am now at Meta in the Seattle Area, looking up at this very big mountain. It is a challenging, rewarding ascent, and I am focused on the path ahead. The “risk” of down-climbing from Vienna paid off with a trajectory I couldn’t have imagined back in Europe. Because I have down-climbed before, I no longer fear the descents. Life is a struggle, I accept it, if in some years spot a higher peak, maybe one with a different terrain or climate, whether it’s an updated career growth or something else, I won’t hesitate to pack my gear, walk down into the valley, and start climbing again, ready to pay the price again.


2 comments


A/B Test: Optimizing Career Through Mentorship

December 7, 2025 Career No comments

In sports, no matter how elite the athlete is, they always have a coach. Even absolute world champions have someone who will critique their form, strategize with them about the next event, encourage and push them when they are tired. Yet, in software engineering, I often see people don’t get any help and just try to power through their own career. Imagine, that you can ‘test run’ your career decision, run A/B test on it, and then make the best decision to be deployed to production. This is essentially what mentorship is about.

Q: Why would you want to have a mentor?

There are always people who have been there before. There is someone who went through the same promotion, joined the company you are considering joining, works in the domain you are interested in, built a startup, or is simply in a similar situation. You want to talk to them and learn from them. You will benefit from leveraging their experience. Instead of doing your own O(n) you can learn about optimized O(1) approaches right away.

Q: Shouldn’t you make your own mistakes?

Yes, absolutely. Make them and quickly recover, at the same time there is only so much of this life. You can live a lifetime and not make enough mistakes, and some of them are painful, especially if they are ‘one way door decisions’. So I say: make mistakes naturally while learning how to avoid them and knowing about the mistakes and lessons of others. Other people’s experience is so much cheaper to learn from than making costly mistakes on your own. I think the room for making mistakes is infinite, so, maybe, make them when it is more of ‘two way door decisions’ but get as much advice as possible for irreversible decisions.

Q: How do you get access to mentors that seem inaccessible?

Let’s say you are interested in some particular tool or technology and you know of a person who is voice in that field, say for AI that would be Andrew Ng or Andrej Karpathy. You probably won’t get 1:1 with Andrew Ng, but what you can do is find people who report to them or work with them, who appear on the same white papers as them and get in touch with those people. You can also be very specific when you reach out asking about a very specific part of their work and offering something in return. And I am not talking nonsense – I personally had small exchanges with major bloggers (back then) and with authors of some tech tools, books. What I’m saying is that people are more accessible and open than you might think. This requires high effort, but the ROI on a single response can be career-defining.

Q: Why would anyone be interested in helping you?

Although it might seem you are asking for someone’s time like if it was their charity to you, but that is not the case. There are multiple reasons why they will be interested in helping.

  1. Teaching you forces them to sharpen their own thinking. This is the top of the learning pyramid. 
  2. Networking. More senior engineers are looking for high-potential engineers and mentorship is often a way to build the bench and network across. It’s a win-win.
  3. Sometimes it just gives people satisfaction to know that someone acted on your advice and was able to make progress.
  4. A way of staying in touch with what is happening on the ground, technology stacks, career challenges, etc.

Q: How to ‘match’ your mentor?

One of the mentors I had once said that finding a good mentor is a bit like dating. Not everybody ‘clicks’ even if they seem to be the right fit on paper. In my opinion you need to have a session or two with them to understand. If you are in a big company there are official channels to establish mentorship and I encourage you to try it out. If you are looking for a mentor outside, it might be a bit weird to ask someone ‘Will you be my mentor?’ (sounds almost like a marriage proposal on a first date), but instead you probably want to ask for specific advice on some topic, share your own thoughts on the topic of their interest and build the relationship naturally. Oftentimes for mentorship to be effective you don’t have an official ‘mentorship’ label, and it can just be occasional lunch.

Q: How do you spot a good mentor?

In my opinion, a good mentor will be asking you questions that make you think a lot. They would challenge your thought process. Give new perspectives. Good mentors give you better questions than the ones you come up with.

Q: How do you prepare for the first session?

Treat the first session like a system design interview. Have requirements and constraints in mind. Explain the goals of ‘design’, give some timeframes. For example: “I want to learn how to deal with ambiguity, and this is the situation I’m in …, my goal is to close this ‘gap’ for my next promo by x”.

Q: How do you get the most out of mentorship?

Follow up! Yes – that’s the best advice I have. After each meeting with your mentor, make sure to follow up on the action items. It does multiple things: you are not wasting their or your own time; you are showing respect to your mentor; you are building discipline in yourself. Going to your mentor with the generic “How do I grow?” The question is a bit discouraging. Your mentor will have to put a smart face on and give you a generic answer. Who needs that? Go with very specific questions, create action items, report back on them, put work in. Close the loop!

Q: What’s my model for working with mentors?

I like being accountable and keeping people accountable. As such for my mentorships I keep a list of Action Items and generally strictly follow up on them. This isn’t the only valid approach. Some people find value in more casual and relaxed ‘coffee chat’ conversations.

Q: Do you need a ‘board of directors’ or just one single mentor?

I think getting more perspectives is always healthy. You need one person who is technically better than you, one who is politically savvier, and one who understands your personal values. There is, obviously, a limit to how many mentorships you can handle. Personally I have 1 or 2 mentors at any given time and besides them I have some network connections that work a bit like mentorships where I learn from them, even though there is no label ‘mentor’.

Q: When and how to end the mentorship?

Sometimes you outgrow a mentorship relationship. Let’s say you reached the goal you wanted to achieve. If you have mentorship within the bounds of a company, this is super easy to do, just tie it to the performance review cycle, thank them, leave them good feedback they can use in their perf review and move on. It is fair, a good mentor wants you to outgrow them, it’s awin-win.

If the mentorship is outside of a company, then it is more likely to have natural evolution. Never ‘ghost’ your mentor. Instead give it a logical conclusion, thank them, mention switching to more of ‘ad-hoc’ sessions instead.

Conclusion

You cannot really A/B test your entire life and career. If there are ways to move faster and learn from others then I would say mentorship is definitely one of such ways and you should leverage it. Whether you are looking for a mentor or are ready to be one, remember: we grow faster when we grow together.


P.S. This post is a ‘Thank You!’ to my current and past mentors as well as my self-reminder to leverage this even more in my life for other areas, such as my sports, personal growth, building ideas, etc.


No comments


The Promotion Formula: My Take

August 10, 2025 Career, Success 2 comments

Promotions in tech companies aren’t random, but they’re not entirely deterministic either. Here’s my humble attempt on a generic ‘mathematical’ formula I think makes sense.

Disclaimer: In no way this blog post represents the official position of the companies I worked for in the past or now. While I will try to make this generic, I’m definitely biased by my past experiences, plus my visibility is definitely not that of a VP level, so take this with as big of a grain of salt as you can imagine.

Background

In my career I had 5 promotions, 3 before FAANG and 2 at FAANG. I helped some of the  engineers on my past teams get promoted, mentored a few people outside my org/team, and participated in the promo committee.

I’m definitely not in the high percentile in terms of how far I got with my promotions. There are people who are many levels higher, got there quicker, and didn’t write a word about it. Some think chasing titles is pointless or even toxic. Others say real engineers should just build what they believe in or launch their own startups. I’m writing because it is my thing. I had my path, and you and others have different paths, this is just how life works. So with that healthy dose of self-awareness and some humility, let’s develop a formula for success:

What is the ‘formula’ for promotion?

Unless you’re in a chaotic startup or very small company, promotions usually follow a structured process. The criteria often include your performance, leadership skills, and feedback from others. If I were to boil it down into a formula, it would look like this:

Where:

  • Promotion:  Readiness score where < 1.0 means not ready, > 1.0 means ready.
  • Execution:  Quantifies direct work (impact, quality, next-level scope); 1.0 = fully executing at next level, 0.8 = close.
  • Leadership: Measures ownership, influence, and decision-making, partly quantifiable.
  • Feedback: Continuous feedback and visibility through reviews, leadership exposure, and collaboration; hard to quantify but significant.
  • Luck: Multiplier (0.5–1.5) that can amplify or dampen other factors; includes final promo packet outcome as a last-moment swing factor.
  • Weights: Company and level-specific emphasis on factors (sum to 1); e.g., Meta/Amazon may set we≈0.5, a small company may set wf≈0.7.

Now, lets go over each of these with more details and my thoughts on how you can increase each one of them:

Execution

Most of the time this is the most significant part to promotion, especially at entry and mid levels. It’s the quantification of impact, quality of work, delivering results. Here are some very specific things you can do:

  • Basics: Do your job and do it well.
  • Quantification: Measure the impact of your work before, during, and after delivery. Even maintenance work can be framed in terms of what would happen if it weren’t done.
  • Projects: Focus on high-impact, high-ROI projects. If your project doesn’t seem impactful, either (1) quantify ROI properly, (2) find ways to increase the scope/impact, or (3) if it’s truly low-value, align with stakeholders to drop it and move on.
  • Quality: Show engineering or operational excellence, not just speed. This is because cutting corners may get quick wins, but over time they hurt your credibility.
  • Scope: read the description of the next level and create mini-gap analysis if the scope of what you are working on is going to fill-in those gaps.

There are many other things to consider here, so see what you still need to do to tick all the marks of the next level of execution. That having said, strong execution gets you good hard data, but without leadership and visibility, it may not get you promoted.

Leadership

If you just joined the company as a fresh grad, not much leadership is expected of you, your Wl coefficient in the formula above will be really small (~0.1) and the higher you go the larger this coefficient is going to be. Companies have their approaches to how to measure this, for instance Amazon has 14 leadership principles, Meta has “Direction” and “People” axis, Google and other companies have their own things.

I will say something controversial, and hard to accept, but IMO a lot of your leadership potential is already backed in your personality at adulthood. I am not saying it is not possible to grow as a leader and improve, what I’m saying is that for some people it comes more naturally because they are more extroverted, confident, and more charismatic. To be clear: if you actively work on improving your leadership skills you will get much further than someone who has better prerequisites but isn’t trying to improve.

Usually, if you are going for promo, you would need to tick some boxes, depending on the framing you company is using.

  • Influence. Have examples of influencing others. While influencing with authority is easy, for promotion you would need to show how you influenced peers or your leadership by presenting solid data, writing crisp documents, showing prototypes, telling convincing stories. If you have examples of where you influenced the roadmap at your skip level that would stand out. Trying to influence overly hard can backfire as people could perceive this as you being pushy, so come to them with clarity and data.
  • Communication. Communicate clearly, timely, upwards. While this makes sense it is often a lot harder that it sounds. I’ve seen many solid technical engineers that really really struggle with communication. Sometimes the reason could just be English as a second language, but more often than not it is all the cluttering, odd structuring, that has nothing to do with the language proficiency.
  • Strategic thinking: Strategize about your area of work, even if you are more junior show that you have given thought to how things should pan out in long term and if you are senior the expectation would be to create scope and solve ambiguous problems, or even find problems where others don’t even see them (yet).
  • Trust: Build that trust because it takes time. Higher level leaders often operate on trust they have in their senior engineers
  • Dealing with ambiguity. The more straightforward the task is the less easier it is to automate and the more unvalued it is. At the age of AI, more and more of clearly defined tasks are going to be automated, so you bring value by being human and being able to deal with all of the missing pieces, unclarity and other things of that sort.
  • Leadership gaps: Identify any company specific leadership requirements they might have, these can include: conflict resolutions, raising the bar, mentoring, etc.

At the end of the day someone will have to provide feedback about your work.

Feedback / Visibility

By feedback in my formula I didn’t just mean final feedback you get on your promo package but more of continuous things that includes manager/peer reviews, visibility with leadership, work with other people, this is hardly quantifiable in numbers but does play a significant role in the promotion as this builds that perception around you.

  • Manager: Work with your manager to have a complete alignment on expectations and check-in regularly on your own initiative. 
  • Peers, cross-org, and your reportees: Just don’t be a jerk to others, express gratitude, be helpful. Doesn’t sound like much, but these things are appreciated.
  • Higher leadership. Create a name for the project association in the minds of your leadership. When promo time comes you are not a simple spreadsheet line to them.
  • Deliver visible wins: demo your work, share launch emails, and post in relevant channels so more people see the impact.
  • Credit: Credit the team in public updates, but make your own role clear in 1:1s with decision-makers. Never take someone’s credit but be clear if you did contribute so that your credit is not misassigned.

Now, you might have all the great execution, leadership and visibility, there is one last piece that might override it all and it is the effect of luck.

Luck

One purely deterministic and cold-blooded view is that you are worth exactly what you are worth, meaning that if you somehow think you deserve a higher level this is simply wrong as you were not able to determine what it takes to get that what you want and therefore you don’t deserve it. Big companies have a data-driven approach to promotions, so if you have the data for the next level you would undeniably get it.

I do not buy this idealistic view and that’s why I introduced the Luck multiplier to my formula. It is a multiplier rather than an additive term, because it can significantly boost or dampen the effect of your other factors – you can execute and lead perfectly but still be blocked by bad timing, or get promoted earlier due to being in a high-visibility project at the right moment and because your org has big promo budget that time. You might have worked on a project that suddenly started making millions/billions of dollars growing and riding everyone’s careers with it or you might have worked on a failed project and got laid off. 

So if there is so much you cannot control, do you just give up? Well, maybe, work on slightly improving your chances:

  • Preparation. Deliberately invest learning and self-growth. While it might not give you that immediate promo, it can position you well in the future.
  • Openness to opportunities. Do not ignore opportunities when you see them, evaluate them and act on them. It has some risk, yes, but as one of my first mentors once said “Never moving fish is a dead fish”.

Weights

Weights used in my formula are reflecting your company’s emphasis on each factor for a given level (they sum to 1 for normalization), for example companies like Meta or Amazon can make huge emphasis on Execution, making that We close to 0.5, while your small company really trusts what the others say about you so Wf is 0.7. At a very senior level your Wl becomes a much larger contributor.

Once you know your scores and weights, here’s how to move them.

Strategy and Tactical Plan

Here is the advice I give people when they ask me about promotion and it consists of two big steps:

  1. Career Strategy: Write down a strategy for your career. A long term one. One that describes what the hell you want to achieve in your career in 1, 2, 5 years. You don’t have to share it with anyone, but it will help you build clarity for yourself. Go, do it right now, create a Google doc, write some raw disconnected sentences, and expand to make it more crisp over time. I happen to be at Meta because it was part of my Career Strategy.
  2. Tactical Plan: Find a promo document template and start filling it in, even if your promotion is 1 year away.
    1. Start with a target date for your promotion, work out what makes sense, align that with your manager. If you are not getting definite ‘yes’ from the manager it is the feedback you are too aggressive and you might not see something.
    2. Identify any missing gaps, what’s needed to get you from A to B, start on your own based on your company’s framework and template, involve your manager, and gather feedback.
    3. Identify any blind spots, as usually there will be things you don’t know about, your manager might not be directly telling you. A mentor can help you get that outsider perspective.

Conclusion

Luck is outside your control, but readiness isn’t. Don’t judge others purely by their title, success of their project or generally where they are in their life, everyone fights their own demons and battles, you just don’t know. The best shot you have at a promotion is to consistently operate at the next level in execution, leadership, and visibility. In this post I’ve shared my formula:

Promo = (Execution + Leadership + Feedback) * Luck

If you work deliberately on each part, you shift the odds in your favor. Hopefully, what I’ve shared here gives you a clearer map for getting to your next level.


2 comments


From Google to Meta: A Mid-Career Leap

July 20, 2025 Career, Personal, Success No comments

Disclaimer: opinions in this post are my own and do not represent opinions of my current employer or any of my past employers or any of my or their clients.

I’ve been so busy I forgot to mention some important career changes. In fact, I’ve been so busy it has already been half a year since I started working for META. Not only that – I’ve moved countries again and now live in the Seattle area.

Google

I’ve spent 4.5 years at Google working on the experimentation platform within Ads. It is flattering to think that traffic for billions of people has been supported by the code I touched, however limited my contribution might have been.

Google is an incredible company, great culture, great and bright people. I worked for Google remotely as I joined during the pandemic and then switched to permanent remote when the offices started to open. I wish there was an office in Vancouver, Canada, in which case I might have decided to stay at the company. It did feel that being remote long term is disadvantageous to my career and at times it felt unfair that south of the border the pay is much more for the same job at the same company.

My ride at Google was great- I joined as Sr. Eng, but then got to Staff quickly for someone new. It could have been due to cross-org visibility of the project I worked on, and some luck as well, or, maybe, I’ve done a good job. Whatever it was getting that next level didn’t feel as gruelling as the promo I worked for at Amazon. Good ride and I definitely see Google as a place I might want to come back to.

Meta

Meta is a company with a strong culture, great ambitious vision, and isn’t afraid to make big risky bets. It is quite intense from inside but also very rewarding at the same time and this matches my expectations of what I thought I will get into. Paycheck is also nice, my FIRE goals are closer now. 

I joined Meta, because I wanted to further expand my toolset, learn new ways of building things fast (and sometimes breaking them), as well as be back to closer interactions with people (but that was mostly because of my remote situation). If I were to compare: at Google, I found stability and polish; at Meta, I find speed and higher ambiguity. Both cultures are fostering innovation and are great places for engineers.

My first half of the year at work passed blazingly quickly. I wasn’t even able to blink from Jan to Jul. There is so much to work on every day, that there is no way around it other than finding ways to prioritize, be productive and focused, always making sure there is impact in the end. I’ve come up with new and stable work routines that keep me effective, like starting very early with few hours of deep work, and staying productive throughout the day, but also so that my work-life balance isn’t hurt and so that I can continue my kickboxing classes, rock climbing, running, and having proper weekends with my kids.

What’s next?

In an odd way, having a more intense workload also stimulates me to explore more ways to learn and grow outside. I think we’re more adaptable than we give ourselves credit for. When life asks more of us, we often rise to meet it—and that includes finding new ways to learn, improve, and move toward what really matters.

Personally I am approaching a point where it makes sense to think about life more holistically – not just the next promotion or goal. What do I still want to experience? What kind of life am I building? A meaningful career is part of it, and a big foundational support, but it’s only one piece of a much larger puzzle.


No comments


Design Your Path: Ditch Generic Advice and Think for Yourself

December 27, 2024 Career, Success No comments

Are you tired of all of the online advice? All of these LinkedIn and other social media stories and posts where there are only 10 steps formulas for the ultimate success and happiness. I’m certainly tired. I’m not saying it’s all bad advice out there, it’s just overwhelming, repetitive, often one-sided, half-baked, naive, and unactionable. It’s the most frustrating to see advice that is not original, copied from somewhere, and just posted to grab your attention. Arguably, some people might benefit from specific posts (hopefully you can benefit from this one), but this constant fight for your attention makes it difficult to sift through the influx of information and do anything about it.

I came to the conclusion that at a certain point saturation with this online advice is such that spending more time on it has diminishing returns. At that point it is much better to put YOUR own thinking into it and create your own self-advise. You already know what is missing in your career or life, you already know your shortcomings and desires. You might not be able to spell it out right away, that’s why instead of scrolling through hundreds of stories that may or may not be applicable to you, you would benefit much more if you spend that time on thinking for yourself and trying to understand what is going to work for you, realistically and with all the context of your situation.

For example, for your career, you might want to create a strategy document (yes, an actual document with structure and everything). I rarely see people taking active career planning other than “I want to get promoted”, but there is so much more that goes into it. When I wrote my career strategy document I assessed my current situation and created a vision for the future by asking lots of simple questions and doing pros/cons of  “Do I want to continue to be remote?”, “Do I want to convert to a manager?”, “How about another industry?”, “What are the new skills I want to learn?”, “Am I stimulated and challenged enough in my current environment?”, etc. (LLMs can generate a good starting list of questions).

The end of the year is a good time for self-reflection and strategizing about your own life and career. I think that everyone has to have their own approach based on what has and hasn’t worked for them. Over the years I came up with an approach that mostly works for me. Specifically, I create new year resolutions (since 2010) and then track them (mostly publicly). In order to be accountable and consistent I run weekly challenges and email exchanges with friends who would agree.

Instead of relying on the overwhelming and often repetitive flood of online advice (including this one), take this post as an encouragement to create your own personalized strategy for life and career growth by taking time at the end of this year to self-reflect, think deeply about your current situation, and then come up with approach that truly works for you, not a formula borrowed from someone else online.


No comments


What Kind of Plant Are You? Reflecting on Career Growth and Transplanting Yourself

November 11, 2024 Career No comments

Picture of Bamboo I took in a botanical garden in Austria in 2012

Recently I have been asked what career growth means to be? Without hesitation I shared that it’s two things: first, expanding the skill set, and second, advancement in position (at least in the corporate world). In this post, I want to expand my answer and also share a story or two.

In my opinion, skill development is the foundation for other types of growth. Skills make you more capable, adaptable and valuable in your role and industry. Almost all of the soft skills are transferable to new environments. As for technical skills, the majority are also transferable unless they are very specific to the company you work for (*). Something that might not transfer very well could be team- or org-specific knowledge.

Your skills, knowledge, and hard work is something that allows you to increase the scope of responsibility, gain professional recognition, trust, and as a natural consequence you advance in position, make financial progress and hopefully achieve personal fulfillment.

After answering the question, the person I was talking to shared a Chinese Bamboo Tree story (**), where we can compare someone’s growth to how bamboo grows. There is no visible growth for the first 4-5 years, which is because bamboo is expanding its root system and then in one season bamboo grows very rapidly. This is a very strong parable and I have successfully used it at work when a colleague of mine was seeking career advice.

If you stay at the same role, level, or team for quite some time it doesn’t necessarily mean you are not growing, you could be expanding your root system before you get promoted to that next level. As long as you feel you are learning new things, becoming stronger in your skills, expanding your work network, delivering some things you are definitely growing.

To extend on this analogy of plant growth, I was thinking about uprooting: you work for 2-4 years in a company, you made sizable contributions, got your promo, and slowly started to become more and more valuable and then you transplant yourself to another company. What happens to your roots? Do they survive?

I have seen people who were the first “plant” to a field and were able to grow to be the biggest of the plants, I have also seen people who had good roots but stayed in shadows for too long and stagnated, and others who transplanted themselves so often they could not grow enough on each iteration.

I was asking myself, what kind of plant am I? Google is my 5th workplace and I cannot stop wondering what I would have become if I stayed in any of the companies or countries I left behind. Looking back it seems I made the right decisions as I was able to grow to a bigger and well rewarded plant with a very diverse root system, but I have never become a really big one. Maybe I’m yet to see my real growth, who knows.

What kind of plant are you? What are your thoughts?

(*) Some of my fellow Googlers sometimes joke that we become unhirable outside because of the uniqueness of tools we use and the scale of problems we are solving.

(**) Technically bamboo isn’t a tree and belongs to the grass family. Some species of Bamboo might indeed take 5 years to grow underground before emerging above ground but this isn’t universal or common to all species. Additionally I searched for the origins of this story and it doesn’t appear like it exists in Chinese folklore. It appears this parable was popularized by western culture in modern motivational literature. 


No comments


Is Being a Generalist Software Engineer a Good Thing?

September 7, 2024 Career, Opinion, Success, Uncategorized No comments

It probably doesn’t compile otherwise why be so unhappy?

Somehow I became a generalist software engineer with a diverse domain experience. I started career with C# and moved to Javascript and then to Java and now C++. I worked for healthcare, online entertainment, nuclear energy, e-commerce, and advertising industries. In this blog post I want to share some of the details of these experiences and conclude on whether being a generalist is better than being a niche engineer.

Technology Lens

The very first program I ever wrote was in QuickBasic in grade 6 (1999). The school computer I wrote this was only capable of running some version of DOS. Computers at university ran Windows and I learned to code in C/C++/C# + some more obscure languages (Prolog, Algol, Pascal). In my first job I wrote desktop and mobile solutions using MS technologies, mostly written in C# with WPF & WCF. My next gig was all about performant backend services with a mixed technology stack backing a multi-million user website. At my next job I found myself translating nuclear material accounting code from the 70/80s written in PL/I that ran on mainframe into Javascript or C#. Most engineers who wrote the original PL/I code either retired or died. This job taught me that I can love a dynamic programming language. Then I moved to work for Amazon, it was all about launching new business workflows and scaling it with Java services backed by AWS and ReactJS frontend. Now at Google I mainly write in C++, but from another perspective for me there was a big shift from working on products towards working on infrastructure that supports traffic for billions of users.

Domain Lens

Now I want to have a look at all of the same jobs but from a different perspective. The first projects I worked on were for healthcare providers. Honestly, I didn’t give myself much thought about the morbidity of the things, the fact that much of the software was for hospices didn’t bother me as I was operating on the level of tasks. It was only later when I was working on a mobile app for nurses to visit patients at their homes did I internalize what this all was for. Next job probably wasn’t that noble – it was in online entertainment, more specifically sports betting. I even had an account with a competitor and placed small bets on sport events to understand how they do things compared to us. Saving the world from making more atomic bombs? Yep – that was my next job, kind of. On the ground what I was doing was merely software for IAEA (UN) and its agents who went to nuclear facilities and collected nuclear material data, performed different checks and recorded them in the app for later analysis. I got a chance to visit a nuclear reactor and learn how it works. Next gig was about enabling small companies to sell more stuff at Amazon. This was about enabling an entire channel of dropshipping for the India marketplace: loading inventory into Amazon systems, processing customer orders, invoicing, etc. This allowed me to have a good view on how e-commerce works. These days I work on supporting online advertisement from inside by working on infrastructure and tooling that allows other engineers at Google to deliver solutions to show you relevant Ads. I know ads may sound like a bad thing, but the free internet exists thanks to ads. Ads pay for those transatlantic underwater internet cables and all the other things that power today’s internet.

Cultural Lens

All of the companies I worked for were very different culturally. First job was a very homogeneous environment, all of us were Ukrainians, fairly young and we worked for our American customers who on their side were also culturally similar among themselves. I think communication gaps existed due to time zone differences and English language skills on our side. Next job was maybe half Austrians and another half of East europeans. The product we worked on was our own so I think we cared about its success a lot. I am actually not sure if I fit into this environment culturally, but I thrived on the technical front and delivering results. At the same time this was when I made many new friends who remain friends until now and I even stayed at their home on my recent trip to Europe. The United Nations is definitely a culturally most unusual environment I had to work in, mainly because of the diversity of nationalities and backgrounds. Any day at the UN premises there were people from over 100 different countries, my team alone had people from all of the continents. Something that was a bit less diverse was age, as many of the people who work for the UN are accomplished individuals with some years behind their backs. This was the place of internalizing that not everybody has the same life views on it and it’s all ok. It was extremely fascinating to learn from my colleagues. I would say that on a macro level both Amazon and Google are culturally similar – we are ambitious technically savvy individuals striving to make an impact. Though on another level Amazon is a fast paced, high intensity, customer centric, and deadline driven company whereis Google is more mission driven, long-term oriented, with more emphasis on innovation.

Conclusion

I can probably wear many other lenses to look at my past experiences, such as, Impact, Scale, Learning, Personal Fulfillment, WLB, Collaboration, Communication, etc. But even with the 3 lenses above it is clear that the diversity of technologies, domains, and cultures pushed me to become a generalist software engineer. Arguably, this isn’t necessarily a good thing, being extremely deep into one technology and domain can land you a ludicrously high paying job. I saw people sticking around and climbing corporate ladder rapidly, something that I couldn’t do with all the switched I did, and at the same time I saw directors being laid off just because there is no need for their role any longer. In today’s economies of scale the winner takes all. If you are at the right place and time and win the game – it is all yours. On the other hand, if you are not that “winner”, adaptability gives you an advantage of switching when needed and grabbing at least some piece of the pie or, maybe, a chance to win another game next time. I don’t know what is right, the above was my journey and it continues. What are your thoughts on going broad vs deep in your software engineering career?


No comments


Goodbye Amazon; Hey Google

August 24, 2020 Career, JobChange, Personal, Success 4 comments

Disclaimer: opinions in this post are my own and do not represent opinions of my current employer or any of my past employers or any of my or their clients.

Time for some big news: as of 24th of August I’m a Googler or rather a Noogler, as newly joined employees are being called.

Aligned few T-shirts for my first working week

It has been almost a month since I left Amazon. Here is a “mandatory” badge photo. Amazon was a place of rapid learning on multiple fronts, not just from engineering perspective but from many other. I learned Java or at least enough so that I can write code in it (not that is is much different from C#, which I knew before) and I learned how scalable and resilient solutions are built. But other than that and most of what I learned wasn’t programming related but more of understanding on how truly data-driven, customer-oriented (or let’s say “customer obsessed”) company is run. Seeing this machinery crunching from inside was absolutely astonishing. Probably what’s the most prominent about working for Amazon is its strong prevalent culture embodied in 14 Leadership Principles. Each and every aspect of work is guided by those principles. It starts with your interview to be an Amazonian. It takes you through working days, your promotion, decision making and anything you could think of. People live by these principles.

During 2.5 years I worked on retail project to launch and scale a fulfillment channel in one of the rapidly growing markets. The time allowed me to meet and work with amazing and smart people. The team I was on was awesome and my manager was a boss you can only dream about. I liked the vibe of Vancouver’s office, maybe because it was much more multi-cultural and diverse compared to Seattle (though I might be mistaken). I was promoted at Amazon to SDE3. The project I was on was and probably is gaining more and more of momentum.

Some of you would be curious why I left Amazon if things were going so well. (Just look at AMZN stock price for one data-point). As every job there are negative aspects. Amazon is somewhat notorious for those, but I didn’t leave Amazon to leave Amazon. I am not excluding joining Amazon again some years from now. Current decision is more to learn about another big company, its culture and processes, especially when we are talking about Google.

I don’t know what exactly to expect from this change. Many software engineers see Google as the most desirable employer to join. The company is famous for its high engineering standards, googley culture and so many other things. I’m excited to the core to embrace what is coming at me.

Among 24 checkboxes in my 2020 plan working for Google will tick few of them. This includes double-tick on meaningful work-related change, learning a new programming language (will be coding in Go and Python), and unexpectedly might change my coffee and sleeping habits (if I succeed in regularly getting up before 6AM and not having coffee :) ).


4 comments


Becoming Senior Software Engineer and Career Path

April 4, 2020 Career, Success 14 comments

Disclaimer: opinions in this post are my own and do not represent opinions of my current employer or any of my past employers or any of my or their clients.

Señor Engineer
I just had to put this picture for few friends of mine ;)

Recently I got promoted to Senior Software Engineer position at Amazon. This post starts with my career story leading to the place where I am now and finishing with thoughts on titles, their meaning, and further thoughts on professional growth for software engineers. Bear with me, this is a long post with no conclusion.

Career Path so Far

My first job was with a Ukrainian outsourcing company, Softserve Inc. I started there in April 2008 and left the company in December 2011 to pursue new experiences in Western Europe. During those 3.5 years I got promoted twice. When exiting the company I was titled “Senior Software Developer” leading a team of 8 developers. Most of us were young software engineers just some years out of college, we were in a different kind of business than all of my next jobs (outsourcing vs. product).

My first job is still an inspiration on how I should be approaching my career. Being career driven, ambitious, and overly eager to learn non-stop were the main characteristics of me back then. I was brave enough to speak at user group events, and teach others. I’ve just read old post on leaving my first job and it inspires me. My English is horrible, but the meaning is everything:

I joined my second company in Austria as a Software Engineer (intermediate level) and was extremely happy with the quality of software we were producing and everyone’s skills. This was the first time I started learning about distributed systems and just loved working there. I hammered the keyboard non-stop and was happy. As it always is, every story has its end. I left my second company banally to earn more money. Sad but true. They tried to keep me by offering some XX% salary increase, and… drumbeat… a “Senior Software Engineer” title. I rejected. I don’t know if that was the right move, but that clearly was time when I chose money over title or even over happiness at work. Below is a blog post about leaving second job and reasons why I chose money, if you are interested:

I spent only 1.5 years with second company after which I had long 4.5 years with United Nations (well, the IAEA, which is international organization associated to UN). I started as a contractor Software Engineer – my title didn’t really matter as at first I was self-employed, I could probably have called myself “God Of Software Engineering” at “Greatest Software Company In The World” and it would not matter as for the IAEA I was just a contractor and they made me go through airport-like security each and every day for few years. In the end they hired me as a Staff Member with a cryptic title “Systems Analyst / Programmer” putting me in charge of a team of contractors :). This was another bump in my income as suddenly I didn’t have to pay taxes (yes, let me repeat it – I legally did not have to pay any taxes at all).

The place is definitely unlike any other workplace. There were over 100 different nationals working in the same building with me. I worked directly with people from Iraq, Zimbabwe, Azerbaijan, UK, Australia, Canada, China, India, and so many other countries it was virtually impossible to know who is from where. There was so much learning about different cultures. This alone was awesome. There were tons of other benefits related to working at that place. Not everything was great. For instance, I had to come to work in a suite – yes, software engineer in a suite. More seriously I was looking for more growth. Even if I managed to get promoted that would not make any major difference. Maybe, I would just start wearing a tie in addition to suite. Unfortunately, I don’t have a blog post about leaving that place, even though I have so much to share. All I have is this picture of me getting out of a nuclear reactor and tweet:

Up until 2018 I was mostly .NET engineer with desktop, distributed, mobile and web skills. Starting to work for Amazon meant dropping good portion of that knowledge and learning Java and many things from the “dark side” (oh, sorry, that’s the other way around). I’ve joined Amazon as SDE2 and I didn’t mind joining on an intermediate title as I knew that working for one of FAANG sets me on a totally different growth path that brings challenges of a different magnitude. I cannot talk too much about work at Amazon other than what’s public. But it is not a secret that one line of code change could mean MM$ of loss or MM$ of revenue here just because of enormous scale. This is why Amazon always tries to raise the engineering bar. Amazon is a place of insane growth. Love it.

Do titles matter?

So where am I going with all of this? If you followed me so far, you would notice I always skipped titles either for new experience, more money, or growth opportunities.

So do titles matter? I think it depends on how you look at them. You can be “CTO” at company of 10 people making 100K a year, or be a fresh grad Junior Engineer at top company in bay area and make twice as much. But “CTO” might have a chance to grow her company to giant and make millions because she is in a different growth position. It is not only about titles but what they really mean, what level of responsibility they bring, what is the pay band, what impact, knowledge, and skills are expected. Most often companies define levels boiling down to some kind of seniority and scope of responsibilities and then would define different titles having technical track, management track and maybe few more.

Long story short, I think titles do matter but they matter in a context.

When I look at titles of people whom I knew from my first job I get humbled – some of them got promoted 6 times to the likes of “Vice President of Something” or “Senior Solutions Architect” or even something more pompous. Not all of them, though, some of them who were less ambitious or had different goals took different paths. This makes me wondering where I would have ended up had I stayed. I will never know, but should I even care? Should you care about your past decisions and think too much? We should not! Regret is a painful emotional state to avoid. We need to always try to minimize potential regret.

So how to get to the next level?

Everyone of us has a different path in life and in our careers and that is just the way it is. We care about ourselves, our families and people we know and relate to. So for the most part you don’t care about me or my title the same way as I don’t care about your title or other engineers’ titles. That having said, you might be interested in this post as you might be wondering how you can get to your next level or what you can learn. Human nature is not to be happy with what they have and I am ok with this. This is normal.

Here are original bullet points from me:

  • Do your job and do it well. Really well. Master the tools. Balance delivery and long-term perspective.
  • Never ever stop learning. Improve yourself in all areas. Soft and hard skills.
  • Work on projects that have impact and could grow to something big. If you don’t think you are on such a project change the project or change the project.
  • Find a mentor and work with your manager and others to get you where you want to be.
  • Look at what next level implies and do those things. Take responsibilities. Now.
  • Make your work visible and document what you’ve done.
  • Stay healthy. Sleep well.

How much in a promotion is luck?

This is a difficult question. If I take philosophical approach I would say that a lot is due to luck – we just pop up like little candles in different parts of the world and then we fade away, you might have been unlucky to be born in poorest country in the world or your parents might have started preparing you for Stanford in elementary school. You might have worked on a project that suddenly started making millions of dollars growing and riding everyone’s careers with it or you might have worked on failed project and got laid off.

Another cold-blooded view is absolutely deterministic. You are worth exactly what you are worth, meaning that if you somehow think you deserve higher level this is simply wrong as you were not able to determine what it takes to get that what you want and therefore you don’t deserve it. Big companies have data-driven approach to promotions. If you have the data for the next level you will undeniably get it.

My overnight promotion was years in making.

Conclusion?

This was just a story. You can make your own conclusions. I’m just encouraging you not to give up. Feel free to leave me a congratulatory or any other kind of comment.

Among other things, this promotion completes one of the important parts of my 2020 new year resolution. I’m now 12.5% done and more is to come.


14 comments


Approaching a software engineering problem

January 5, 2020 Career, Opinion, Success No comments

How we approach problems often defines whether we succeed or not or how hard success comes to us!

Me ice climbing

This blog post is my humble attempt to come up with some of problem solving advice for software engineers who are starting in their careers. Why would you listen to me? – You don’t have to. In fact, I would argue, that you shouldn’t take anyone’s advice at glance and at the same time be open to evaluate everyone’s advice and then make up your own mind. I do not have many credentials, other than 12 years of experience as a software engineer in various roles (SDE, Sr. SDE, Tech Lead) and various industries (outsourcing, online entertainment, nuclear energy, e-commerce). My experience is different and success is questionable. I am guilty of making career mistakes and solving problems the hard way. My hope here is that the below could save you from making same mistakes.

Worst mistake

The worst mistake of all is to die with regrets but, as not to get too philosophical, we are talking about software here. So…

It is totally normal to get stuck time to time on problems. If you never ever get stuck it might indicate that you are staying in your comfort zone impeding the speed of your progress. Therefore, imho, one of the worst things you could do to yourself at work is to let yourself stay stuck on a problem without any progress or learning and as a result with no advancement to your future career.

Understanding the problem

The first step to approaching a problem is understanding. You’ve got to identify the issues and envision how the success would look like. Sometimes this might be referred to as “working backwards”. More often than not, there will be preprocessing done by business analysts / project managers / senior engineers which results in some kind of requirements (stories, documents, tasks, etc). Your job as a software engineer is to first understand what is wanted from you. Simply state back to requirement givers in your own words what it would solved problem mean. Once you understand the problem completely proceed to the next step.

Strategizing

The second step is strategizing. You need to come up with a potential solution. You might want to brainstorm on options, evaluate them and try to come up with the best one. Decision matrixes and other techniques might help, but don’t bug yourself too much. At this step you might want to create a plan by breaking problem into smaller tasks. You might work on proof of concept or try one or few things out. I do not believe in plans themselves, but I do believe in planning as it makes you think hard about the approach. It is important not to get stuck in “analysis paralysis” mode, so once reasonable time is spent, move on to the next step even if somehow you don’t feel ready. You will never be fully ready. Take on the problem you’ve got. You might learn some new things when doing so which you didn’t anticipate.

Execution

The third step is approach execution. Doesn’t matter how great plan you had, if you fail to execute you fail. Say, you picked option x and it didn’t work out for you, do you continue to push for x or do you switch to option y, do you give up, do you seek help? What do you do? Do you feel how anxiety creeps in?

From my personal observations generally there are two types of execution: erratic and systematic.

Erratic

Basically you just start bashing the keyboard, throwing different copy-pasted blocks of code and praying it is going to work. This is that kind of approach when “<” didn’t work, so you replaced it with “<=” and it worked, but then you realized that your loop had to start with index 1 instead of 0, and so on. Eventually you arrive at the finish line. I bet that most of us, software engineers, have used this approach and it worked at times but then we felt uneasy about it.

Systematic

You think about each piece of code you write and consequences it is going to have, questioning each line of code and thoroughly testing the code. Why do I use “<” instead of “<=”? Why does the loop start at index 0? Should have I used thread-safe data structure here?How would this button look on small screen? Why does this API accept any number of items? I don’t know about framework ABC, so why not read a doc reference first? And so on – you question everything! This approach might seem like taking much more time and it does, but eventually written software has less bugs, is much more maintainable and truly solves the problem. Arguably, maturity of a software engineer can be recognized by observing them solving problems in this systematic way.

Some other bullet points

  1. Reiterating is fine. Although systematic approach wants you to think about each line of code, you might be overwhelmed to do so at once for larger project. In this case coming up with a “skeleton” solution that does something and then building on top of it (maybe changing few “bones” here and there) is totally fine. This goes along with agile methodology as well. Just don’t scarify quality with “oh, this will be one in the next iteration” and eventually never being done.
  2. Do not just copy-paste. As the joke goes: “Dev1: Damn, copied this from StackOverflow and it still doesn’t work. Dev2: Did you copy from the question or the answer?” Although copy-pasting from other parts of the project or SO, for that matter, is totally fine, what’s not fine is not understanding what you are coping or not questioning the quality of the piece of code you are copying. If the code was written by more senior developer or if most of the project is written “this was” this is not a valid justification to not try to see if anything about it could be improved. As a simple example, a developer before you might have took a shortcut by defining style right in html instead of moving it to a css class in separate file.
  3. “Don’t work hard – work smart” – although true, stinks. Most often I heard this from people who were lazier than others. There might be two types of laziness – a) the one that makes you procrastinate, and b) the one that makes you ingenious in problem solving. I’m fine with b) as long as it doesn’t come at cost of quality of your solution in terms of maintainability. Think of someone doing a+=b; b=a-b; a-=b; to swap two integers because they didn’t want an extra variable and now extrapolate this on on system design of your software where no-one could understand what the hell is going on. Long story short, you need to work hard and there is no way around it.
  4. Pause to learn and deliberately practice. At times you might come around something you haven’t worked with before. Stop! Take a moment to understand what it is. Reading one of two pages of documentation or going through “hello world” tutorial might save you a day or few. As an example, you might need to integrate a library into your project and it may look overwhelming as the project is huge. At this point it is best to implement simplest possible project with the library to understand how it works before spending days integrating it and then not understanding why it isn’t working.
  5. Seek help but do your due diligence. It is totally ok to ask others questions – this is the way to learn. At the same time it might not be appreciated to ask something that can be found online or in documentation with a simple query. Also learn to ask how to ask help http://xyproblem.info/
  6. Time bound. Never get stuck on something for too long. Put some boundaries for specific tasks. If x isn’t working, look at your strategy and unstuck yourself. You might need to escalate this with your manager.
  7. Clearly communicate. Very likely you are working in a team and have a manager. Work on improving your communication so that you can convey your status and whether you are blocked and need help. I would advice against obfuscating your status with needless information – just be honest if you are having difficulties.
  8. Retrospect and analyze if you can improve something for the future. Don’t just take everything at its “status quo”. Say, if environment setup for your project is difficult, and always takes time for engineers go ahead and improve it.
  9. Reasonably document your work. Chances are that someone will have to solve a similar problem or that you will need to explain your work at later stages. Documentation is just a tool to help you out in these situations.
  10. Add your bullet-points/thoughts/disagreements in comments!

Conclusion

It is in my personal view that approaching a software problem consists of 1) understanding the problem 2) strategizing about solutions and 3) execution of the strategy. Observation I have made over the years is that engineers tend to solve problems erratically or systematically. More systematic approach supplemented with the above bullet-pointed guidance might be helpful advice for starting software engineers, but be skeptical as this is purely an opinion. Enjoy and let me know if it helps.


No comments