See if there are organizational goals that involve moving a metric (ex. we want to reduce our infrastructure spending from XXX to YYY by EOY, etc). Usually, companies will decide their roadmap at the beginning of the year where these goals are made and as a result you can come up with projects to try and hit these goals.

Additionally, I would recommend looking at the roadmap of other teams, talking to people within your team and external stakeholders to see what problems they face, and taking a look at the history of operational incidents that have occurred within your organization to see if there are any improvements you can make.

Software Engineer | Ex-Amazon

Ammar C

So I just realized that you are applying for L3 (entry level?) roles. I would encourage you to check out the following

[How do you fail an E3 behavioral round at Meta?](https://www.jointaro.com/question/RSgJ9uJm3PVU7qOq31Su/how-do-you-fail-an-e3-behavioral-round-at-meta/)

After the discussion, what was the higher-level/fundamental learning you had from it? Why did you follow his idea? Great conflict stories have elements where two people have different value systems and fundamentally disagree on how something should be done 

- Ex. I want to add more processes to the team to ensure we don't make mistakes vs I don't want to add processes because it slows everyone down

If the resolution to a conflict is simply "I discovered more information about the task and we resolved it" then it's not a suitable story.

Usually I will

1. Update the status on many of the open tickets I have and what the next steps are
2. It's hard to get a hold of my lead but when I do I always have questions prepared for discussion (ex. here's the update on this task -&gt; my next steps are ... -&gt; Do you agree?)

I was laid off from Amazon in 2023 and spent \~10 months unemployed (with a seed stage startup gig that fell through and a rescinded offer in between D:).

After my second rescinded offer, I committed to doing whatever it took to land a job, no matter what, including

- Applying to new jobs on Otta daily and jobs on Linkedin that I thought were a reasonable fit
- Following up with recruiters for open roles daily
- Reaching out for referrals with tailored messages + Job IDs for people I personally knew
- Posting on LinkedIn to boost engagement to my profile. Additionally, I could have built side projects in public and blogged about them if I felt my resume was not solid enough
- Attended NYC tech meetups to see if I could get an outbound lead (I actually did get another startup contracting gig from this that I declined)
- Contacting consulting firms like Robert Half for opportunities -&gt; This didn't lead to anything unfortunately

Finally, I landed multiple offers and chose a Cloud Infra Engineer role in the AWS space, leveraging my prior experience at AWS.

Your job search does **not** need to be this intense, however, this is the approach I took to maximize the number of interviews I could get. Simply cold applying isn’t enough if you’re not getting responses.

For example, someone on Taro from NYC regularly attended meetups, and would somehow obtain the contact information of tech executives and leverage that to land interviews. I've seen it happen.

I echo your frustration as I used to overthink writing every email/slack message especially when talking with senior leaders in my career.

The thing is, once you have established a certain level of credibility -&gt; speed is better than exact correctness in giving answers, especially for questions that aren't super impactful/important.

Similar to Jonathan's answer, I advise being comfortable giving answers more quickly, especially without knowing the full context. You actually can see this on Taro itself, as many renowned posters will provide answers to questions that don't even have full context needed to give an extremely accurate answer.

Entry-Level Software Engineer [SDE 1] at Amazon

Are you trying to go from SDE1 -&gt; SDE2? If so, then I would recommend just finishing your promotion to SDE2. Every team at Amazon has scope for SDE1 -&gt; SDE2 promo and it's not something that is affected too much by politics. You also have already been on the team for a year so you already have the context to make a more significant contribution.

Finally, becoming an SDE2 will make it easier to switch teams internally and even switch locations if you choose.

In my humble opinion, no job in the entire world can make you fulfilled if you don't have anything outside of work to look forward to (family, friends, SO, a hobby, etc).

I have a very simple rule for generating fulfillment from work and that's to find the **next opportunity to learn something new or do something you've never done before**. It could be leading a large cross-functional project. It could be mentoring a junior engineer. It could be working with a tech stack you've never worked with before, etc

Nothing kills fulfillment more than being in an environment where you aren't learning anything at all or learning something so niche and specific it doesn't translate into anything fundamental (ex. very specific frameworks, etc)

For getting better at writing design docs

- Put in volume, write many docs, and get feedback often from accomplished people that you trust.
- Look at other people's docs and look at the feedback they have received
- Also mentioned here, it's fair to reach out to others and ask about their thought process
- Make a note of any acronyms that you repeatedly see in these docs and ask what they mean as well as perhaps document it in a wiki page for newcomers to more easily figure out

I have never gone through Formation but I believe the program can be worth it in some situations where self-studying simply is not working. Personally, I have experienced this myself and seen many others experience this where

- **In DSA interviews**: Candidates can practice leetcode problems in silence but fail real interviews because they fail to identify invalid inputs, evaluate tradeoffs, point out edge cases
- **In system design interviews**: Candidates simply draw boxes about what they have read about but have no real background on why these boxes solve the problem at hand

I would specifically reach out to the team at Formation to see if their mocks can correct the weaknesses many people experience above.

Also, I believe Formation offers a flat fee of $10k in addition to the variable pricing.

Are you talking about improving at DSA interviews or writing code on the job? The two are in fact, quite different.

**For DSA interviews**

- **If you are brand new to DSA**: Put in a lot of volume and complete questions from **Neetcode 150** or a similar curated playlist of common leetcode problems.
- **If you already have completed Neetcode/etc**: Complete the problems from Neetcode but this time try to internalize the pattern and see if you can modify each question slightly to incorporate a different technique for the same pattern
  - **Example**: Everyone knows that you can use binary search to search for an element in an array. Did you know however that you can use binary search to split an array into two halves and search for the minimum in the right half or a maximum in the left half? It's important that you really internalize how these patterns can be used differently than what they appear on the surface.

**For coding on the job**: Here's a hack to learn how to code better ASAP

1. Write **a lot** of code and get it reviewed by peers. Try to internalize all the feedback they give you and ask questions if necessary
2. Look through all of the code reviews for the past year and see what feedback teammates are getting on their code. Bonus points for following a trusted senior engineer and seeing what comments they specifically write
3. Try to learn a bit of system design on the side to better understand how the code fits into the overall system. I would read design docs internally and if not, check out a few problems from [HelloInterview](https://www.hellointerview.com/dashboard)

Have you tried mocks on Hello Interview? I tried them and I was pretty happy with the feedback.

I don’t believe they have mocks for JavaScript however.

Are we the same person? I worked at Amazon for a year before being laid off after receiving a 'Needs Improvement' rating. I later discovered I had been unofficially PIP'd when an AWS partner rescinded a job they offered me since even subcontractors had to have hiring eligibility.

I didn't know about Taro or other tech career resources back then. Unfortunately,

- I thought that being a great coder was enough for great performance at FAANG until I dropped the ball on my first ambiguous project by failing to manage stakeholders and project timelines (I was more concerned about tinkering with the API instead!!). 
- Since back then was an easy tech market, simply memorizing answers to common leetcode problems was enough to get into big tech, and oh boy did I struggle to try to get my next role. 

I was unemployed for \~10 months before I found a proper stable role, and even now my current job is not a place I can see myself growing my career in the long term. I also had to move to a new area that wasn't ideal (isolated suburbia).

I had completely blew it and had to start over.

After, I took a long look at myself and realized I was arrogant and wanted my great coding skills to compensate for everything else in my life. When I moved, I told myself that this time was going to be different.

Now

- I try to focus more on my communication and keeping stakeholders updated rather than completing as many tickets as I can at work
- For my first 6 months, I would go into the office every day and chat with whoever I saw there
- I would leave work at \~5 PM ET, not open my laptop for the rest of the day and focus on other aspects of my life which include
  - Cooking my meals instead of eating out every day
  - Going to the gym regularly
  - Exploring the area and even chatting with locals
  - Planning Taro meetups

Now, I'm in a much better place and feel confident in the next recruiting cycle. Everyone's journey is different but I would say to understand that life is not a race and to try and focus on your health/connecting with others for the time being. I know you are smart and capable enough to find the next role that empowers you!

You absolutely can ask about the input size but the solution that the interviewer is looking for is most likely not going to be dependent on the input size the same way people can guess the optimal time complexity for leetcode questions based on the question's listed input size.

Interviews are very much unlike leetcode. You are not expected to figure out the optimal time complexity according to the size of the input, number of test cases, etc.

In addition to what everyone else mentioned, I would also ask if you can get refreshers/prevent yourself from getting diluted out of your equity for strong performance.

When I received an offer from a seed-stage startup last year, the founder mentioned that was an option for high-performing employees.

In addition to the great points everyone mentioned here, Amazon backloads their stock grant because they essentially want to filter out only those who can make it from SDE 1 -&gt; SDE 2 in \~2 years.

What you are seeing on [levels.fyi](http://levels.fyi) is probably an average or some sort of calculation based off of the four years vesting.

In addition to the great points everyone has mentioned here, I would try to look at as many code review comments and design doc feedback comments as I could to get a better feel for the project context -&gt; That's what these mechanisms are for.

Your experience is absolutely valuable. IMO, the brand alone from working at Spotify and Netflix is enough for you to craft a compelling story for your next interview even if you did not do much (which I strongly believe is not the case).

I failed **a lot** in the last \~2 years, and I completely understand your frustration as it feels terrible to fail again and again. Besides retrospecting on what you could have done better which many others have suggested, my biggest advice is to **not feel bad for yourself because this is life, mistakes happen, people end up in unlucky situations, and to be completely honest you probably will end up in more unlucky situations in your life**.

The worst thing you can do is to believe these unfortunate events are a reflection of who you are instead of just being a minor bump in the road, and to not be ready for your next opportunity.

I totally get this. Once I started working, I realized there would always be a ticket around the corner for me to do. With a ticket backlog so large, how will I ever have the time to get alignment, scope a project, and drive it to completion?

What I eventually realized is that ***you need to make the time***. If you don't set aside some dedicated time every week to work on your highest priority item or come up with a new project that will drive your career, then you will endlessly be working on tickets that may or may not be impactful (and suffer a context switch every time you do it).

> For me, I feel like I have a pattern of getting pulled into these tasks during my sprints and sometimes missing my deadlines by few days and so have adapted to avoiding these tasks

Can you batch some of these requests together instead of completing them ad hoc? Can you reasonably avoid completing these tasks?\
\
I'm not sure if you are personally assigned work for each sprint or if you pick up tasks to do. One thing I realized with many engineers is that those who are proactive in finding impactful work to do and seem busy are not as often expected to perform many of these ad-hoc tasks.

"I think the issue is that switching libraries midway through development costs a lot of time when you discover the library isn't what you wanted"\
\
There's

1\.) Switching libraries/architecture because the requirements weren't poorly defined/a use case popped up that the team didn't know about and

2\.) Switching libraries/architectures because as a company/organization matures the business use case changes

Point number 2 above ***will*** happen at some point (it's called technical debt) so there's no point trying to optimize for a use case that didn't happen yet.

Regarding trying to optimize for point number 1, I echo Sai's point in that you typically want to pick the most stable dependency with the most amount of community backing OR the dependency that your company typically uses IMO. This is because

1. The dependency is less likely to have bugs as more people will find, report, and even fix them (if it's open source)
2. The dependency will more likely have more features released in the future if it's popular/in demand

Glad you asked this question. For years I used to live an unhealthy lifestyle where I would eat greasy food or not anything at all because I never felt hungry. Two of my resolutions this year were to

1. Adopt a healthier diet that does **not** involve eating processed food
2. Consistently eat three meals a day/snacks + get in the gym to get to a healthy BMI

Some of the recipes I make are as follows

**Breakfast rotation**

- Eggs
- Oatmeal w/ milk and peanut butter

**Lunch and dinner rotation**

- Rice w/ meat and vegetables and homemade white sauce
- Pasta w/ different sauces and meat
- Burritos with meat, vegetables, and cheese
- Burgers with cheese, onions, tomato, and various sauces (ketchup/mayo)
- Curries (Don't make this too often but I have a coconut curry recipe that I like)
- Noodles (Also don't make this too often but I have a peanut noodle recipe I like)

**Snack rotation**

- Peanuts (or just about any nuts really)
- Greek yogurt
- Protein bars

You can buy all of the items above in bulk from Costco. Also, if you are like me and do not want to spend 1 hr+ cooking every day then buying an air fryer (to avoid a mess in the kitchen) and prepping your meals ahead of time is **absolutely** necessary.

Also, when starting try to *avoid* making certain recipes of different types/cuisines because the recipes themselves are ingredient and time-intensive. A few examples include

- **Anything** that is deep-fried
- Many Indian curries
- Pizza
- Pad Thai/Ramen/Pho

Hope I gave you a few ideas on how you can live a healthier (and hopefully tastier!) life.

The recruiter needs to decide what level you are interviewing for (junior/mid-level/senior/etc) so try to frame your answers in a way that makes it easy for them to decide what level you are.

For example, if you are interviewing for a senior position you are going to want to talk about leading large projects across more than one dev team, dealing with stakeholders, mentoring junior engineers, and even taking part in shaping the roadmap.

Try to understand the leveling guidelines first before coming up with your answers.

I found this article pretty helpful when it come to evaluating startup offers\
<https://www.vinayiyengar.com/job-guide/>

You don't have to build something original. You just need to find something that exists and do it better.

Also, it helps to have a product-focused mind. Ask yourself with products that you use every day "How can we improve this product?". You would be surprised how many products today can be vastly improved.

Fun fact, big companies oftentimes cannot deliver the "best" experience for customers because they are saddled with a heavy payroll. For example, Google cannot even consider building something unless it makes $100m+ because their payroll is $50m (these are arbitrary numbers btw). This is where startups shine in customer obsession.

Always go outside and get some kind of physical activity/exercise after work. This can mean going for a run, playing a game of basketball, hitting the gym, etc.

In busy times (ex. preparing for an important interview) I would at least go for a walk outside to reset my mind.

Anecdotal but there was an interview I had with a startup where I needed to write a program and host it on a docker image/container to call a given free public API.

Software engineering interviews will not typically ask containerization questions but infra/platform positions likely will.

Remember, not all platform/infrastructure-based positions exclusively use Docker so try to understand the different ways software is hosted on AWS/GCP/Azure (for example Serverless vs Container-based architectures)

I always do some outdoor sport/activity or at the very minimum take a walk around the block at \~6:00 PM every day after work. This helps to decompress my mind.

I know this thread is about working from home but I always found that working at the office was **much** better for my mental health. I'm based in the New York suburbs, so I often travel to New York City for work, and let me tell you: the hustling and bustling, energy, passion, and intensity of the city never gets old.

Try to get concrete details regarding your situation. For example

- Ask your manager how you are currently performing rating-wise if he had to submit your evaluation for performance review (needs improvement, meets expectations, exceeds expectations, etc).
  - When asking your manager, make it clear that you understand he/she cannot provide you with a completely accurate rating however an estimate is satisfactory
- Come up with a concrete plan with expected deliverables to understand how you can reach the performance rating you want (ex. exceeds expectations, meets expectations, etc). Also, understand what rating is necessary if you want to be promoted
- After completing the two points above, ensure that you review the progress of your plan in subsequent 1:1s with your manager

After clarifying the above points, your manager be able to provide a better timeline for your promotion now that much of the ambiguity has been resolved

One technique I would try when assigned tasks I did not know how to do was to either blame the code or search the ticketing system for solutions to similar tasks. Sometimes I would even reach out to people who completed similar tasks to ask what their thought process was.

I understand you work at a 3-person startup. Is there anyone else outside of your startup who can give you advice on how to solve these problems? I remember being in your exact shoes (and asking a similar question on Taro hehe) and what got me through it was reading through all of the code reviews of senior engineers to find out their thought processes. 

In my experience, there are a few situations where up-to-date documentation makes sense. For example

- Onboarding new engineers to the team
- Oncall runbook on how to diagnose/fix/rollback common issues
- Onboarding team members to a new service, how can a team member compile/start/run the code and start tinkering? What are the coding standards/guidelines for that repository, etc
- User guide on how to use the product you are developing (this documentation is for the customers but engineers should contribute to this too)
- Design docs on how the architecture of the service works at a high level
- Documentation that roughly outlines the stakeholders (upstream and downstream dependencies, etc)

Quality over quantity is crucial in documentation, as it tends to become outdated. Ask yourself if the documentation you are writing falls into any of the categories above. If so, is the documentation at a sweet spot in terms of depth? I often find that documentation that's too specific cannot be understood by many and documentation that's too generic is not helpful.

I once worked at a consultancy where we had to document every hour of our work to show clients how their money was spent. Try to avoid working with such companies if possible.

A manager for example can best make an engineer satisfied with his job by understanding what he wants to achieve with his career.

- Does he want to get promoted? Great, let's identify stretch projects that will help him get promoted and provide him feedback based on the work he is currently doing
- Does he feel more satisfied working within a specific technology domain (ex. frontend, backend, infra, mobile, machine learning)? Awesome, let's identify projects that align with his interests
- Does he want to prioritize wlb? Ok, let's create a plan where he can be productive without stretching himself too thin

This is just one example but there are many others. The idea is that before you help someone out in some way, you need to truly understand what they are looking for first.\
\
**Fun Fact**: Taking an existing solution and putting it in the hands of customers without understanding if it solves their pain points is not customer obsession/user empathy.

Here's my recommendation

- Build a side project and post about what you learn from it on social media (or maybe even start your own blog)
- Go to tech meetups where you live regularly (if there are any) and chat with the engineers and the event coordinator there about how you want to get involved in the tech community
- Try to find others who are in your situation and live in your area and learn what strategies they are using to get interviews

Ultimately, becoming a familiar face to those who not only can help you but also those who are experiencing the same as you will go a long way in helping you find success in the long run

I genuinely do think the market will get better in the first half of 2024 (J. Powell announced rate cuts next year, SPY is up and gas prices/mortgage rates are coming down) but I do think that will take some time to propagate.

I agree with Alex on this one in that it sounds like you enjoy your job minus the commute so my recommendation is that you try to currently work out prepping/applying/interviewing while working.

Believe it or not, some people find it easier to prepare/apply/interview while being employed (I'm one of them). Even though there is less time in the day,

- Being employed forces you to have a structured day
- Being employed forces you to socialize with others
- You don't have to worry about an employment gap when you are employed
- If you are unemployed and spend the majority of your time interview prepping, you might have high expectations for passing your next interview. Interviews, as we all know, are random and if you fail you might feel bad given how much effort you put into preparing. Sometimes it's nice to accomplish small wins at work to keep you going

I was also laid off from Amazon in April and am still looking. In my experience, I don't find this to be the case because I have been interviewing with both smaller and larger companies. Similarly, I do find it harder to get interviews at smaller companies unless I have a connection and personally reach out in some way. Note that many of the smaller companies I have interviewed for are geographically located near where I live so I believe that might be a factor in them deciding to interview me.

My recommendation is to only worry about the things you can control (I know, it's really hard :/). I'm active on Taro so feel free to message me if you want to discuss how job searching has been since Amazon layoffs. Take care.