I actually have an algorithm for this:

1. Look at the job description for the role at your dream company.
2. Learn 80-90% of what's listed as required and nice to have.

Example: <https://boards.greenhouse.io/spacex/jobs/6930808002?gh_jid=6930808002>

Startup Engineer

Michael Lee

What are some of the most common people problems/conflicts you encounter as a technology leader and what do you do to avoid or minimize them for your organization?

Sorry for the open-ended questions that begs for an essay response.

1. What do you think are the most *complex* classes of problems? Is *complex* the same as *difficult,* in your opinion?
2. If intelligence (commoditized in the form of AI) were as abundant as electricity tomorrow, what would be your strategy to obtain massive leverage?
3. There's a high correlation between intelligence and success in big-tech jobs. Even though some people are incredibly humble about it (Alex), you can easily tell they're way above average when they speak or explain their thought processes. Do you think this concentration of intelligence is a net positive or something to be concerned about?
4. When will "gaming" (some form of it, comparing that to couriers) become a normal job that regular people can live off of? 

What's your theory on why success compounds (getting into Meta gets you into any tech crowd, why does the rich get richer), and for the things you know you should be doing...

1. Why are they so hard to do?
2. Why are they so... Obvious and abundant? I think literally everyone knows what they're supposed to be doing.
3. Will it eventually lead to good outcomes in the long run, i.e. become a 100% causal relationship to whatever goal you have in mind?

Just my two cents but your anxiety may be stemming from a lack of confidence or belief in yourself. Instead of seeing it as your skills are decreasing in value, it would be better to see it as a chance to enter a new stack where you can bring all your experience and expertise to augment it. It might seem like some whiz kids are so much further ahead of you, but the reality is that it's impossible to know many things deeply. Dig a bit deeper and you'll find that those same experts will lack the skills that you've honed for many years simply because they were focused on something else-- and the thing is, they'll still need your skills and talents to accomplish whatever they're trying to achieve.

\+1 to all the other responses.

Always come at it from the perspective of "What value can I provide *them?*" instead of "What can they do for me?" Surprisingly (and you'll have heard it in some of Rahul's videos), some people actually want highly motivated mentees who can grow to provide a lot of value for their organization. There are stakes involved, i.e. their performance is linked to yours. Just take that into consideration and do your best!

> So the question is, how can I best invest my personal development time so that as I progress in my career I can continue to meet, or even surpass, exponentially growing expectations?

I don't know if my answer will help in terms of progressing your career... But something I notice when listening to engineering leaders is that the "quality" of their thoughts is always extremely high. I don't get the impression that they go around collecting knowledge or reading books just to say they have done it—rather, that's how they cultivate the quality of their thoughts and how they sharpen their minds. *It's not what they know, but the quality of their thoughts.*

One thing that should be a question for everyone is: if you had to start over at the bottom in a completely different field, would you be able to do it? This harkens back to the beginner's mindset and the *winner's* mindset. To be the best, you must constantly destroy the things you are really good at but aren't optimal for you in a future environment. I constantly think about whether titles will be the same, with AI doing most of the heavy lifting in the future.

> My question is, other than Leetcode, is there any way I can prep for this? I'm looking for a better way than Leetcode since I won't be asked a Leetcode question.

I've been reading a lot of engineering blogs lately to see what the state of the art is for *particular* *systems*. For instance, I'm reading blogs about how companies design their activity feeds because I want to make sure that the one my company has is as efficient and scalable as possible. Because a service like this has so many concepts embedded in it, it allows me to think beyond just the theory and really understand it from a product perspective.

> Any recommendations on how to best succeed given the current context?
>
> - General recommendations for succeeding in this ambiguous domain?
>
> - Resource recommendations?

Read the docs! Knowing what's available and how the developers want you to use their API is part of familiarizing yourself with a new tech stack.\
\
For resources, I used **A Cloud Guru** and their playground to learn about the services AWS offers. I would just think of AWS as a set of prefabbed microservices that easily operate together. The sdk encourages **Code as Infrastructure** so I would lean heavily into learning how to architect these services and the right way to write **CloudFormation** stacks. 

- Mindset — it's easy to think software engineering is based on talent and not on systems and habits
- Understanding career potential — levels, total compensation, difficulty (effort and time) to achieve
- Shortcutting and learning from the lessons of others — contrary to popular belief, premature optimization is great for career growth
- Expectations — what a high performer looks like in terms of code quality, velocity, PRs, communication ability, internal motivation, etc. You'll find lots of gems if you reflect on the answers and perspectives here.

A lot of the *tactical* advice has been extremely useful. They're essentially cheat codes for career acceleration—like a map in a dark forest or a survival guide telling you what mushrooms are safe to eat.

I tend to focus/fixate on things I can form a habit or reputation from, such as:

1. Mindset (most important thing IMO). I can't tell you how disillusioned and cynical I used to be. With the right role, responsibilities, and work culture, you can actually feel like a "professional" and not just a glorified code monkey (or someone who sees themselves as not really doing anything important but has to act like it).
2. Behaviors around communicating ideas and progress
3. Things like spending time dressing up PRs and *over*\-describing in written communication
4. What to disregard if you want to optimize career growth (distractions such as the "hot new framework or thing")
5. General career planning, i.e.:
   1. Understanding that you can't just submit an application and hope—you need a solid plan and time/security before you start
   2. Techniques to record your accomplishments in your current role
   3. Knowing the TC of Big Tech and the expectations that come with it (no one actually tells you)
   4. Knowing Big Tech standard practices so that it isn't a surprise later on
   5. Being exposed to a larger world of possibilities and seeing a concrete destination

Things like code velocity and quality are more individualistic and depend on the engineer, so I deemphasize advice that talk more about talent than repeatable systems. There are tactics for *getting better at coding* on Taro, but obviously, you can't get better by just reading advice and not exploring, programming, failing, and persevering.

I definitely echo Jonathan's post: I'm passionate about programming because there's a nice big bag of gold for the person who's able to master it. If the same was true for Math or Physics (what I'm truly passionate about), I'd quickly pivot as well.

> I worry that I don't have what it takes to be an outstanding engineer in the tech industry. I work every day, but I feel lost and unsure about where my career is going.

Maybe you were meant to be the world's greatest post-modern art critic. I think when we see things happen to other people in the world, we want that for ourselves but miss that the *actual big* opportunities are the ones where no one but you could have done that thing.

Maybe the question to ask is: is being an *outstanding* engineer your **ultimate** purpose in life? Why is it so important to you, and what are the things that happened in your life that make it so important?

> During an interview recently, the interviewer said that I had good communication skills and should focus on technical topics.\
> \
> My stack consists of JavaScript/Typescript, React, and I know a little bit about Python and Django. Typescript is mostly what I use.\
> \
> Is there a specific approach you recommend I take to this technical part?

Every interviewer is different and will generally be looking for a specific thing depending on the company's immediate need. When someone gets that feedback, it generally means:

1. They didn't communicate the technical depth for the specific topic the interviewer asked for *in the way the interviewer wanted to hear*.
2. They didn't communicate enough breadth of knowledge for the broad questions the interviewer asked *in a way the interviewer could understand immediately*.

Candidates will generally blame the interviewer and say something like, "They should've clarified," or "If they wanted me to answer in that way, they should've said so," or "They should've followed up to let me know that I didn't answer the question deep enough"—but, to me, that just indicates a lack of experience, and not being qualified for the role. The right candidate should know precisely what the interviewer is looking for in the position they applied to and give authentic, not canned, answers. It's their time to show others what they're made of. If someone need prompting from the interviewer, the interview is probably going poorly. If it's an entry-level position, interviewers will let *a lot* slide.

"Well, he didn't really answer my question, but he's new and doesn't have that much work experience."

If it's a mid-level role, it disqualifies them because they're competing against other candidates with better responses. The universe of the interview includes them, the interviewer, and *other potential hires.* Remember that the company has to live with its hiring decisions, and making the wrong hire is monetarily costly and can negatively affect company morale. We want good candidates to find jobs that are a good fit for them, and we want bad candidates to get hired by our competitors 😆

It's also the case that maybe the interview didn't go well because of other subjective measures:

1. Not a good personality fit for the company
2. Goal misalignments
3. Red flags based on the interviewer's previous experiences

A lot of things can go wrong, so luck plays a significant factor in the hiring decision.

Here's a link that will introduce product design in a way that cannot possibly be covered in a single comment: <https://start.uxdesign.cc/>

The keyword I always come back to is **leverage.**

AI is taking over? Use that information to your advantage. Ask yourself these questions:

1. How can I leverage these new tools to create even more opportunities for myself?
2. What skills can I leverage to make myself more marketable or efficient at generating value for others?
3. What other non-AI-related tools can I leverage to force-multiply my output, whether that is with code or impact?
4. What are the areas in my life that I can improve that will raise my base competency, whereby these tools can then multiply (not all areas can be multiplied with software)?
   1. My health?
   2. My cognition through a better sleep schedule?
   3. My typing speed?
   4. My knowledge of IDE keyboard shortcuts?
   5. Design patterns?

Every little bit contributes to becoming AI-proof, but it is ultimately about standing out from the crowd and doing what the competition is too lazy or unaware to do.

> Should we do start integrating AI in all our projects/workstreams in order to stay sharp?

Yes! Ever wonder how some people are so productive? Hint: it's mainly the tools they use and the systems and processes they've developed that work best for them.

Here's an excellent article about PMF: <https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit>

Hard work is never wasted if it is used to build good habits.

The "product skills" Carmack is talking about is basically capital D "Design", specifically Human-Centered Design since he's not talking about art or philosophy but something with utility. AI is probably centuries away from figuring out what we want, value, and find aesthetically pleasing. That is my guess 🤷‍♂️

In case you're wondering what I mean by "capital D Design": <https://start.uxdesign.cc/>

@Rahul, I so much want to see the full interview with Steve... Someone suggested a Slack channel purely for videos/resources to share. Since that is only available for premium members, I would love to see the minimally edited version 🙏

> how good does that look on your resume?

Unless it's a brand name, whatever's on your resume will only be considered for 10-15 seconds tops. `software developer productivity team` is super specific and won't even cross a hiring manager's mind on what that's all about. `backend engineer` will be more salient as to what you did at that role.

> Should I consider giving interview for this role?

For me, I would use it as practice if it's worth the time. Most roles usually aren't, and it's like [the Secretary problem](https://slate.com/technology/2014/12/the-secretary-problem-use-this-algorithm-to-determine-exactly-how-many-people-you-should-assess-before-making-a-new-hire-or-choosing-a-life-partner.html) where the chances of your next job being better than your current job—and if your current job is your best job—is statistically low.

The question to ask is: will problems that can be solved with software cease to exist? \
\
In my frame of mind, it takes a population of people to discover a problem and pockets of engineers to experiment, fail everywhere over a long period of time, and then finally succeed at solving the problem. The cycle may be shorter with AI assistance (since it's like magically finding the necessary talented engineers), but ultimately, you can't take the humans who care about the problem out of the equation. 

I second Notion. I extensively use it for notes, data tables, and bookmarking webpages (web clipping). I especially like using its AI feature to improve my writing.

There are no rules... You have to stand up for yourself sometimes and not subject yourself to the whims of the person right above you in the org chart. You deserve to feel a sense of dignity and if you feel like you're being disrespected, tell them that although you are grateful for their time, you must also have some autonomy/ownership of yours. I don't know if ending the 1:1s is appropriate since they're only once every 3 weeks.

One mistake I made starting at a new job was not looking at the company's past design docs and learning how they implemented solutions. For example, in the first month or so, I went about trying to write a 10+ page design document for a very general re-rendering performance problem when most of the company's design docs were only 1-2 pages long tackling very specific issues. The lesson is: *do not rush trying to prove yourself.* Gain a lot of context on the problem first—then your solutions will be much more refined. Honestly, give yourself 3-6 months before proposing anything... This will save you time in the long run.

> Yes, that's what I thought too... What gives me hope is that this is only part of the work. There are also non-technical part and even technical like system design, architectures, cloud, web, etc. Would you look for that as well or you rather not be interested if there are significant technical gaps in the core stack?

I think any candidate who is excited about the non-technical parts is one step ahead of the competition. Talking about the ways you and others can grow as software engineers is a huge signal that this person will be an asset to a team. People who can communicate really well in both written and verbal forms is a big positive and that's basically the behavioral portion of our interviewing process. If you can communicate technical stuff to me on a topic I have no expertise in (like building a datalake or designing an infra stack), I would put that over you not knowing a specific language or framework (like JS, React, or NestJS).

> Have you ever interviewed and hired a candidate based on that only? Candidate who had gaps in the tech you are working with? Isn't it too risky? Could you please show me examples of how you recoginze motivation, curiosity and ability to fill gaps in a candidate?

I am probably not qualified to say that *I* specifically hired anyone but I have been part of hiring committees as a second-stage interviewer. I don't think we've ever hired anyone without the prerequisite skills outlined in the job posting. This is because we usually have a direct need. They also usually get screened out or dismissed at an early stage... But speaking from the candidate's side, I do believe a lot of people are hired in an opportunistic way, where the candidate is too good to pass up because of how they present their motivation, curiosity, and ability.

From the perspective of a Senior Fullstack Engineer who mostly writes TypeScript:\
\
On paper, it's very hard to be convinced that a developer can become productive and add value in a short amount of time with a language and ecosystem they haven't worked in. You'll mostly be compared to other applicants who have some kind of past work experience with JS, TS, or nodejs.

But people in tech are pretty smart and talented, so there are no hard and fast rules when it comes to hiring. The standout applicant who doesn't fit the job description would be someone who's motivated, curious, and—most importantly—can fill a gap or be a person who can grow to fill the gaps in the organization.

I can also tell you my pet peeve though... When applicants are asking for *too much* and offering very little in return. I am in the camp that believes the purpose of employment is to generate more revenue for the company—and not creating social impact, using it for career progression, or to play with new technology. Those are the side effects of helping a company meet its mandates.

It's unlikely to be *that* useful compared to the skills you'll build at an *engineering* job. But like everything, it's the value you get out of it that matters. For me, I was inclined to choose a Master's in an adjacent field that has knowledge that is rare and hard to pick up—which is why I did Human-Computer Interaction.

I also tend to think of qualifications as something of a red herring... The thing that is going to make you stand out is not going to be your Master's degree. Just food for thought: your competitive advantage when competing for a job is more influenced by supply and demand (the rarity of someone's skills relative to the market) than the qualification itself (M.S. in CS, 5+ years of experience, knows Java, C++, or Python).

> Am I delivering 20% more value? I think so, but even if not, don't see much harm in asking for the raise and getting a no.

I would factor in company culture and if this is a normal/innocuous thing to do. 

> I agree with the broader point you are both making which is that getting a new job is the best and fastest way to dramatically increase comp. Working on that.

Even though companies know that it costs them more to find and hire new people, they literally won't give their employees raises. I don't know why... Complacency? 

Also, I hope you don't take me quoting "healthy" as snark. The field has such dramatic salary differences that you can clear an increase of 100-200% TC with a single move.

I'm going to answer this question from another angle: people's first impressions are notoriously hard to crack. One of the worst ego-fueled bad situations would be getting promoted ahead of your former boss or making more money than they do. Example:\
\
<https://www.youtube.com/watch?v=AtzG3wdF_IU>\
\
Even if you've grown a lot in the last two years, this hierarchy is pretty much set once you get hired. This is the main driver for why engineers choose to switch jobs in order to "get promoted" instead of waiting for their organization to recognize them. In my opinion, you're doing too much work for that "healthy" 15-20% raise.

It's pretty annoying when engineers are more interested in their own strongly held opinions than what's good for the company. I found that sometimes discussions are a form of procrastination since it's quite difficult and demanding to tackle hard problems. Similar to the strategy of overcoming inertia, sometimes you just have to get started, build momentum, and then make critical decisions later—rather than spinning your wheels rehashing what to do.

> The approach I am trying right now is to understand the functionality of that part of component, trying to understand the code written for that and start making my own tests cases. I am also looking at the other unit tests written for other components but feeling super overwhelmed as I am clueless what to do. Could someone please advise me how to approach this problem ?

This is probably not an effective enough way to get started. What I probably would do is ask for 30 minutes from someone who has experience writing unit tests (and is really nice) and write some tests together. You need some help unstucking yourself if you're getting called out in standup and if you're entry-level, why not take advantage of the fact that you're "still learning"?

Trying to figure it out all on your own right now is the worst thing you can do because:

1. It'll stunt your growth as you'll need practice in communicating that you need help.
2. It doesn't feel good to not be absolutely crushing it at your job and the stress will negatively affect your health.
3. It's really inefficient to thrash on "solved" problems.
4. Our own feelings of anxiety can weigh down other people.
5. You have to respect other people's hard work and match them to some degree, even at different seniority levels. If the gap in expectations is too wide, you might want to ask whether the company is too demanding or if you need to put in more hours—and then ask yourself whether that is the kind of WLB you want.

You can check out this list: <https://layoffs.fyi/>\
\
Usually, big companies will have a hiring freeze if they're laying people off. In rare circumstances, people will get hired outside of the usual recruitment funnel. For new college grads, it kind of sucks because there's not much you can do but wait until economic conditions improve.

> It looks you are trying to say something to look smart instead of actually answering on the questions

I am responding to your question based on what I gathered from it, from my perspective for what it's worth. You are not required to listen or affirm that what I said is useful. Here's my perspective on why I gave my reply based on the content of the question:

The content I see:

- "work on a legacy code which is so old and so bad you can't see good practice at all"
- "no code reviews (sometimes there is bad it is very rare)"
- "no unit tests"
- "performance review is only about client's feedback and so on"
- "It's about the money only and nobody cares if you are good or not if the client is happy"
- "In very rare cases I have started something from scratch but all of my colleagues were so bad progmmers"
- "I've seen so many bad practices that I have no passion to do anything anymore"
- "How can I fill them when nobody will teach me anything new"

The answers you want:

- Is it possible to apply best standards in an outsourcing company?
- How can I fill all the gaps I have at the moment?

Series A Startup

Senior Software Engineer

> Still after reading your thread I don't see an actual answer on any of the questions.

It seems like you're asking for a "how" solution as though a different engineering process is going to 10x your productivity and ability. The simple answer is that just knowing how FAANG operates is not going to make a person suitable for that company—they select for the behavior they want, they don't necessarily create the behavior themselves.

To briefly answer your questions, even though I've never worked at FAANG companies:

1. Yes.
2. All learning is from within and the fundamentals that make you a great software engineer are less technical than you'd been led to believe.

The secret to growing as a human being is that external transformation requires first an internal transformation. A mindset change of viewing only yourself as being responsible for your career will lead to behavioral changes.

Think about these three scenarios:

1. You spent 12 hours of work on an issue and got a working solution. You submit a PR with only a day left before the sprint ends. One of your coworkers looks at your code, thinks it's good enough, but suggests a better solution you haven't thought of. What do you do?
2. Someone reports a critical bug on your team's chatroom. Five minutes go by and no one responds. What do you do?
3. It looks like you're going to miss a deadline because someone else's pending changes are blocking you. They seem to be putting out fires and looking productive while you are left looking unproductive waiting on them. What do you do?

None of them are technical questions but they ask the following: do you care only about doing the bare minimum, or are you willing to do the best job you can? Is it someone else's problem, or is it a problem you can fix? Will someone else determine what you get done, or will you be proactive and decide your performance for yourself? These are all questions that need to be asked in order to find the answers that will lead to personal growth and transformation.

Just a few off the top of my head:

- Where you work determines your level of ability:
  - People in general have a very unhealthy view of brand names and legacy institutions. Software engineers should not box themselves in when trying to become the best engineers they can—just because you work at an unknown dev shop doesn't mean you can't contribute to the ecosystem, and just because you work at Google doesn't mean you've reached the pinnacle of programming.
- TC is the most important aspect of software engineering:
  - Compensation is incredibly important. But, you can make much more money elsewhere and with much less work. Thinking about compensation as the only goal will cloud your judgment and take you longer to figure out what your strengths are and how to leverage them. Leverage is how you make huge impacts in the world.
- You need to know every framework and language to be good at software engineering:
  - Rahul had a great video on this: <https://www.youtube.com/watch?v=8_j3PShkieg>
  - It probably matters 10-20% what technology you use to solve a problem. Mental models, problem-solving ability, and organization of processes are the bulk of what you need to do anything useful.