How do you choose your next job?
Assess whether the expected success and day-to-day challenges match your aspiration.
Recently I’ve had dozens of career conversations and I often heard folks framing their next thing in terms of a specific technology or skill, such as,
I want to build products
I want to design backend systems
I want to work on machine learning
While many job posts are written in such flavor, I fear that such thinking over-indexes on the solutions/tools and loses sight of what problem to solve.
Here’s why such thinking may do you more harm than good:
A: What do you want to have for lunch?
B: Anything with chopsticks!
A: In theory, almost anything can be eaten with chopsticks. What do you want?
B: Japanese food!
A: Would you like to have sushi?
B: Sure!
A: Great, here’s a three-star Michelin sushi restaurant but they require you to eat the sushi with your hands. Is that okay with you?
B: Of course! Why not?
At Google Ads, there are search quality teams and UI experience teams that focus on different product and technical stacks but share the same nature of work—optimizing for metrics that represent the long-term value. Both teams put a significant amount of work into exploring various “knobs” through A/B testing:
Search quality teams play with quality knobs (e.g. machine learning hyperparameters).
UI teams play with UI knobs (e.g. typography and information hierarchy).
It’s a misconception that the “quality knobs” look more impressive because both teams are trying to find the metric improvement that will lead to bigger headroom.
Through this lens, “frontend” or “backend” doesn’t matter as much. While it’s helpful to have specific learning interests (such as machine learning), I urge you to ask yourself the following question:
What problems would I enjoy solving on a daily basis for 3+ years?
The nature of problems will affect how you spend time, your ideal outcome, and what it takes to achieve success.
For example, if you enjoy solving optimization problems, consider these factors:
Daily workflow: Research, hypothesis testing, number crunching.
Joy: Move the needle in light of “aha moments”
Success: Intuition, domain knowledge, and prior learnings will help you prioritize the most probable hypotheses to test.
Pitfalls: Random trial-and-errors without a rigorous hypothesis-testing process; mistaking the volume of trials with real progress; spending lots of time on data analysis.
Now that you get a sense of what shapes your happiness and overall job satisfaction, you may wonder,
But is this job right for me?
Here are a few questions that may bring more clarity:
Am I comfortable with thinking about these challenges at night?
Will I be proud of achieving such success each month and one year later?
For folks who enjoy solving optimization problems,
The challenges, in addition to the pitfalls mentioned above, would be getting stuck with unreliable findings or non-economically viable solutions.
The joy would be UI engagement, recommendation quality, user growth, and moving metrics.
In comparison, for folks who enjoy system or application building,
The challenges would be investigating and addressing customer feedback.
The joy would be converting product requirements into engineering design and implementing well-defined product specifications.
Since you know exactly what you need to build, there is much less trial-and-error and much more rigid project management and timeline expectation. You will be coding for the majority of your time, and your success depends on choosing the right architecture and frameworks and writing high-quality code.
The key idea is to get clarity on what fun and challenges you’re signing for.
Finally, let’s talk about your career growth. More specifically,
How do the successful people on such teams look like? Would you like to become someone like that?
Take horizontal teams and feature teams for example.
The nature of feature teams is to build and test new things quickly, so that you end up finding and launching more useful features. Success often prioritizes progression (a MVP with 10% capability) over perfection (a 90% full-fledged product) so that you can get more user feedback. Experts here often focus on the breadth across stack.
The nature of horizontal teams is to perfect their own components (e.g. increasing uptime/QPS for a server, reducing training time for log processing/model training, and improving web page loading time). Experts here often focus on a specific domain in the abovementioned area.
I hope this letter provides the framework to help you think through ways to make more impact on your current or next endeavor. If you have any questions, feel free to leave a comment or reply to this email directly.
So, What do you want to have for dinner tonight?
To a more joyful and fulfilling future,
Chris