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.

Entry-Level Software Engineer [SDE 1] at Amazon

Ammar C

"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.