careers¶

Function, Industry, Geography: Career Framework

Your career is a combination of Function, Industry, Geography.

That's it.

That's the framework.

You can change one of these. Not all three at a time.

Why only one at a time?

If you want to change your function, you need to learn new skills.

If you want to change your industry, you need to understand the new industry and the skills required to be successful in it.

If you want to change your geography, you need to uproot your life and move to a new place.

But what if I want to change all three?

You can, but it's difficult and perhaps needs a lot of thinking cycles and internal conviction.

Cheat code: Higher Education

MS/PhD/MBA helps folk change 2 of these at a time:

1. You might get into a PhD program which changes your function and industry both
2. MS abroad program which changes your function and geography
3. MBA program which changes your industry (e.g. IT services to consulting) and geography (e.g. India to US)

Clarity Helps a Lot

The more granular you get, the easier it is to decide convert the wants into actionable steps.

Painful: I want to be a Machine Learning Engineer.

Tolerable: I want to be a Machine Learning Engineer at a Big Tech company.

Acceptable: I want to be a Machine Learning Engineer at Google.

Good: I want to be a Machine Learning Engineer at Google in New York.

Great: I want to be a Machine Learning Engineer working on the problems around generating human-like speech at Google in New York.

What if I am not clear about what I want?

If you are not clear about what you want, that's totally fine.

You can start with the most granular level and work your way up.

Start with the job description of the role you want. Talk to at least 12 people who are in that role.

Ask them what they do on a day-to-day basis. Ask how they got to where they are today. Ask what they ask when they are hiring or interviewing.

People on the Internet call this thing informational interviews and there's plenty of decent advice out there.

Recommended Reading

1. The Antidote to I'm Feeling Stuck? from Swanand
2. Act Like You're 35 from Nirant

Beyond First 90 Days

This one's gonna be brief and echoes 2 Less Obvious Ideas to the younger me.

I am assuming that you already know the hygiene factors: Make few promises. Keep most of them and exceed few of them atleast. Get to like the top 5% in the skill of effort estimation for your own work at the very least. And so on.

Contribute to Developer Ecosystem

Improving any part of the developer ecosystem is useful and visible at the same time. For instance, let's say you add tests for a code path on which 10 developers are working. You've made the lives of 10 developers easier. They'll remember this when you come to them for help.

For some projects/teams, even the build time is quite large and error prone. Any improvements there also save a lot of contributor or developer time.

As Joel Spolsky (the person behind Stack Overflow) wrote: There is more than 1 way to help:

• Maintaining an issue tracker
• Write a decent functional specification

You get the gist. Get creative and figure out points of leverage: low effort, high return on your time.

Engineering Brand Efforts

You already know what are the 1-2 things your team's best is e.g. speed, scale, cadence, or software quality.

Take those 2 topics and write down 5 reasons or points of evidence on why you think those are the 2 topics on which your team is best. For instance, if I was writing "speed" - one of my points would look like, we make 20 releases a week to almost 500K users. Or, we have fewer than 20 bugs for a release thanks to our amazing testing and QA friends.

Now - expand these 5 points into a short, bullet point essay like this one. Ask your manager and other senior engineers for advice. You say something like, "Hey, I wrote down what our team does best - do you think I captured the essence and reasoning?"

Done?

Great, now go write this as an internal and external blog. Submit this at a technical conference which cares about the dimension on which your team is the best. Bringing accolades to the team, with their blessings is much higher returns than reading 10 Medium blogs.

Dos and Don'ts for ML Hiring

This is primarily for my future self. These are observations based on my own experience of 2 years at Verloop.io and helping a few companies hire for similar roles.

Do

• Seniormost hire first: Start by hiring the senior most person you're going to hire. E.g. start by hiring the ML Lead (assuming you already have a CTO)
• Have a means to tell that your investment in data science is working out or not
• Closest to User first: Hire the person who will consume the data to build for the user first
• Sourcing: Begin sourcing early and over-emphasise two channels: Referrals and Portfolios
  • Typically, in India - expect:
    • ~2 months to close a full time role at early career (0-3 years) and
    • ~3 months to close a mid career (3-7 years) and
    • 6+ months to close a senior hire
• If a developer has open source code contributions in the last 2-3 years, consider waving off the coding or algorithmic challenge to speed up the interview process
• Pay above market cash salaries
  • In 12-18 months from now, when your ML Engineer will have internalised all the requirements, company culture and built a bunch of important tooling - she would get an offer which is 2-3x of today. If you're already paying above market salaries, a 20-30% jump is quite often enough to retain many folks
• Have 3 at least versions of your shipping timeline
• Do hire full stack Data Science people/teams. If you're hiring for early members for your team, this is practical necessity. An example of T shaped skills could look like

Don't

• Rely on HR or your usual backend engineering hiring channels to work well for you, in general
• Don't hire the person who builds the means to move data (e.g. ML before data engineering) before hiring atleast 1-2 stakeholders in ML
  • Why? This is because it's cheaper (and often faster) to change ML modeling approach than to make changes in data engineering pipelines
• Don't start by hiring an intern to implement papers or take things to production before you've done them
• Don't expect data science to deliver or ship at the same "user value" pace as Product Engineering
  • Why? Data Science suffers from the twin problems of being new and experiment-driven
• Don't assume that you've so much data, and since all of it is queryable, it's all usable
• Hire ultra-specialists e.g. post-docs and PhDs too early, barring products which requires invention and not application