ooh. I'd take the Anduril SWE option. Not because your stocks will hit the moon, but because you'll stay a software engineer. 

As a business engineer, you wouldn't do as much hardcore coding.

**take this with a grain of salt though, some more informed people will have better opinions. But one thing is for sure, please don't count on the non-cash portion of TC at a non-public company (you'll only end up disappointed)

AI/ML Eng @ Series C startup

Elliot Kang

Low. Kaggle ranking is just a number. Open-source and building in public generates far more inbound than Kaggle. You can generate dozens of inbound interviews this way. Just do cool stuff, then write a little about it. Rinse and repeat.

The reason for this is **people want to see cool shit**. A ranking number is boring.

To answer all your immediate questions:
Papers are a good way, but they take lots of time and your work is unlikely to be rewarded. There is no certainty that you'll publish a decent paper, if at all. Generally ML people don't care about applied ML papers as much. Worthwhile top tier papers take 12-18 months from idea inception to publication acceptance/release **at a minimum**. Second tier conferences like AAAI and KD are still good, but less prestigious. Workshop papers are in much lower regard to real papers.

Some general points:
- ROI on papers is low, given how much time/effort you're putting in. If you want to do purely model research though, this might be the only way
- Very few ML engineers are purely doing model work. The majority are doing systems for ML, SWE for ML, or infra for ML.
- open-source is pretty good ROI if you know what you're doing, there's a Taro course on this
- Switching from engineering work to science work has it's own risks. It's hard to measure research productivity and you might find yourself at a C-tier research shop with some bums

The main point is to always line something up as you never want to be in that OPT phase. You can do this! 💪

Alex's advice is spot on. Being proactive/working well with others is a good defense in itself. There are ways to be proactive about your fate without playing full-on offense, such as covering all your bases like Alex mentioned

You're definitely not alone in disliking this manager person. And you're not the crazy one (in case anyone tries to gaslight you)

Given your visa situation, I think it'd be good to stick it out for some time at Amazon. Your number one goal should be to buy time as someone on a work visa. It's like playing poker or trading stocks: never get completely wiped out. If your visa expires, it'll be way harder to find another job in the states.

IMO visa >>>> compensation right now. If you find another company willing to sponsor you though,  then yes the visa situation is taken care of and then you can get greedy on compensation.

**In case others have further input, how bad is the compensation difference? I think it's okay if your comp is lower than the "average" people on Levels.fyi

Hm. I graduated at the same time too. With all the data points you've given, I don't think this is even a tech stack issue. You're **using bootcamps/degrees as an intellectual crutch**.

Like,

- more bootcamps/degrees won't help you feel smarter
- switching tech stacks won't help you build cooler things

You still need the core SWE job search things like writing a great resume and passing the interview rounds. But doing the same thing everyone else has been doing... phoning in for a 9-5 isn't going to cut it anymore.

If I were you, I would

- Find a meaningful [open-source](https://www.jointaro.com/course/become-an-open-source-master/) project that you'd be willing to commit to every single day for \~2 months
- Write a killer resume. If you're not getting any callbacks after 15-20 applications, it's a dud. **Every line should be a banger**.
- Practice interviewing, once you start landing at least 2-3 a week. Your resume isn't an effective hook until then.

You can do it. If you need some help, we can set up a much more granular action plan to get this done. You're in a much better situation than I was in mid 2023 (MS dropout, no CS degree). Ping me on Slack or Linkedin if you need to

### Personal Anecdote

You're in a bit of a hole, but that's fine. I've been in a similar situation before. It's never too late to turn it around. My brutally-honest resume is:

- Graduated 2019, bombed maybe 30-40 interviews (including Confluent when they were $1B valuation)
- 2020, got wrecked by pandemic + worked some odd jobs
- 2021 - 2022, played mobile games on my iPad + did CS courses
- 2021-2023, went through the motions doing a Master's in CS
- 2023, dropped out and did open-source
- 2024, finally got an AI job after I got tired of working in a restaurant (tips were good though)

Not the optimal path. But hey, at least I have fun building things now. And I washed dishes really fast after Thanksgiving dinner.

lol. So one of my friends had a similar interview experience when he did his onsite at Amazon. It was two questions and they just chatted the rest of the time. He got an offer and ended up being a really high performer at Amazon.

But back to your situation. The question behind your initial question is whether your super short onsite is a sign you failed the interview.

You're overthinking after the interview. You already did everything you possibly could do. They could have put you through a grueling interview loop if they wanted to. **If they wanted to, they would**.

TLDR; you're overthinking, just wait it out.

I don't think you should have any guilt regarding "I'm getting paid more now, therefore I should work more hours".

#### Getting Things Done on Time

That being said, your projects need to get (mostly) done on time. Maybe you could discuss with your manager why your projects are running behind. A couple common issues are:

1. Scope creep. A 3-day issue turned into a 7-day issue because you or someone else added to it. **Fix**: Make a follow-up ticket/diff for the new additions.
2. Getting rug-pulled. The team agreed to the scope of a ticket/project but they say they wanted way more features at the finish line. **Fix**: Get people to agree to written requirements before implementation.
3. Code review takes too long. Your code is too annoying to review, so nobody does it. **Fix**: Alex discusses splitting diffs in the [Level Up Your Code Quality](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/) course

Don't be afraid to call people out on (1) and (2), as it's now your reputation on the line.

#### Gracefully Handling Lateness

Regarding being late for projects, things always come up in a startup. By default, some projects are going to be late. It's how you handle the lateness I think, that really matters. Some key things to ask yourself are:

- Are you communicating with the team that solving issue A will delay project B by # days? How well is news like this received?
- Is your dev pace matching/exceeding current members of the team?
- Who is doing your performance review?

#### Performance Shouldn't Be a Surprise

Finally, your performance review is basically at the mercy of whoever is in charge of that. I think that given you're not even 90 days in, it's impossible to give a definitive or close-to-precise answer. If someone got let go in 90 days, that means they legitimately did nothing, so I wouldn't worry too much about that. (if that's only a single data point)

To answer your question, **there is never a guarantee that your team will let you know that you're underperforming**. If I were in your shoes, I'd bring up your concerns with your manager (who I'm guessing will do your performance review) and see where you guys can iron things out. If possible, it's good to gather your thoughts and do this asap.

Hi, seems like you're on the right path! I understand your urgency, as it's a 6-month contract and you're trying to secure a full-time gig.

I found these courses really helpful at my last job where I had to deal with some serious leadership drama, switch teams, and turn around my performance as a "Research Engineer"-turned "SWE with a sprinkle of AI".

### Courses

#### Junior to Mid Level Engineer

#### <https://www.jointaro.com/course/grow-from-junior-to-mid-level-engineer-l3-to-l4/>

Helps with code quality, communication, and distilling requirements for projects.

#### Leveling up Code Quality

#### <https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/>

Really helps you get into the feedback loop of improving code quality with the more senior engineers, as they'll get "setting the bar" for what gets pushed into the codebase and what's rejected.

#### Performance Optimizations, for work

#### <https://www.jointaro.com/course/maximize-your-productivity-as-a-software-engineer/>

If you feel like you could be way more productive at work, you're not wrong. It's an iterative process, but there's some good pointers here. Alex also politely tells you not to be a lazy bum.

\*\*Doing these courses in sequence yielded really good results. It takes a few days to go through all of these, and maybe 2-3 months to really internalize.

### Masterclasses

#### Shipping Real Features

#### <https://www.jointaro.com/course/frontend-system-design-masterclass-building-playlists/>

I borrowed the design doc format for this masterclass and got amazing feedback from my team. There's three ways to use this IMO:

If you're at a larger company, hopefully they already have a uniform design doc format and you can just take away some nuggets of wisdom from this class. If you're at a startup, chances are you aren't getting much guidance, so you'll have to bootstrap a format on your own and iterate on it. You can also just practice by **writing design docs for your side projects**. Here's a somewhat incomplete design doc I wrote for making a [Figma AI copilot](https://docs.google.com/document/d/16hKvPpoF2Q8fyJd1qnvhHtuRPMJKkfiYIiWvmBcTC4s/edit?usp=sharing)

These can be fun to write in your free time + you get to really think through your ideas.

Anyway, hope this helps.

Wow you write well! I really like your point about being proactive finding work to do. This definitely makes life easier, as you're no longer at the mercy of your Jira board

In my enthusiasm, it looks like I missed a few points 😅 Some things I notice about really, really good engineers is that

#### Breaking Down Work
They're just so good at breaking things into atomic tasks. If there's a whole new workflow, they break it down into as many trivial tasks as possible and knock them out.

Some of Alex's videos on "how real system design/feature planning is done" are super helpful. There's like 3-5 of these at least somewhere.

#### Getting the right people involved
If there's a feature that involves approval from 3+ people, I've seen them just get ahead of the work and gather requirements super efficiently.

TLDR; good engineers are really good at **doing the preparation before coding** so they have to write 70% less code when the implementation actually begins. WLB does exist, but I think you'll have to fight hard for it.(being efficient, constantly improving, picking the right companies/teams)

Oh man. So. I said yes to everything when I first started being a SWE 6 months ago. It was a huge mistake. I was trying to do too many things at once. Ultimately, I took a huge reputation hit and it took months to recover.

So after reading your post several times, I'm getting the impression that you're putting too much pressure on yourself. The expectation of any new employee is to **get the most important work done first**. That's pretty much it. Then you add stuff like code review, refactoring, etc.

I wish I knew a few of these non-ENG related (but even more important) things before I got into tech... 😴

#### Having Boundaries
If your teammates ask you for help and you're swamped with work, just say no. They'll understand, almost any reasonable person will. This is really important because if you never say no, people may just keep asking you to do things.

#### Stretching Deadlines (in moderation)
You're never going to have 100% days all the time. So if there's a seemingly small project but there's a lengthy review process, it's good to give yourself 20-30% breathing room to put less pressure on yourself.

#### Not trying to learn everything at once
If you try to learn everything at once, you'll learn nothing. How are you supposed to know what the code reviewers on your team look for, before you've even landed any code? 

It takes time to meld your coding style with the team's. It takes time to give consistent and thoughtful code reviews to your coworkers. It takes time to add value via ad-hoc tasks.

^side note: I think it's actually harder to add value with ad-hoc tasks than your main work. They are prone to be poorly scoped and not prioritized properly, so it could be a huge time sink to work on these if you're new.

#### Final Thoughts
Enjoy the grind! Make sure to have some fun. Touch some grass. Blow some money on concert tickets or something. As a highly paid SWE, it's your turn to stimulate the economy 💸

Entry-Level Software Engineer at Seed Startup

There should be resources online on the expected equity percentage. That being said, I'd give the "equity" at least a 70% haircut when you tack it onto base as "TC".

Talking to the engineers would definitely help.

Oh yeah, final thing. If it's a Series A startup, ask what the milestones are to hit Series B and where the team is at in regards to that. If the startup is at $0.1 million ARR and it needs to hit $20 million, that's just an uphill battle.

Your concerns are valid. There is only so much you can find out about a startup during the interview process. And it's unlikely they'll tell you about any of the real problems, so you have a ton of guess work to do. If they do tell you about real struggles, that's a pretty good green flag.

Founders tend to say whatever they need to in order to get early employees to join. Sadly, you don't have Glassdoor at this stage to do some due diligence.

### Common Red Flags

#### Shiny Demo

Never, ever believe any demo that they give you (especially if it's an AI demo). It's most likely fake, unless they let you use the tool yourself.

#### Equity-Heavy offer

Early stage startup valuations are rather fuzzy. And if they have stacked SAFE contracts, your equity can get diluted really fast. Don't let startup founders give you this "but your equity is worth $5 million right now according to my personal valuation...", that's just a lie.

#### High Turnover

Look up both current and former employees on Linkedin. If the turnover is really high, chances are you're looking at some unstable personalities steering the ship.

#### Nobody Leveling Up at the Startup

Ask how people get promoted or significant increases in comp. If nobody has gotten increased responsibilities/comp in the past 6 months/year, that means nobody is given the opportunity to grow.

#### Low-No revenue/High Churn

Money talks. If a startup isn't getting traction, it's not getting traction.

### TLDR;

Sadly, I can't name all the red flags. There are many unscrupulous founders who will bullshit you to the moon and back. But by asking hard questions during the interview process, hopefully you'll be able to filter out most of the grifters.

## Addressing Resume Gaps
You're not alone, I have a gap on my resume too. Did a Master's in CS and then dropped out to pursue this GenAI thing. So yeah, I get it.

### The Market and Resume Gaps
I got an offer in April this year, so I've experienced some of this firsthand. Given how hard the tech market has been since last year, I doubt too many recruiters will throw out your CV because of a resume gap. And if they do, they don't deserve you anyways (as long as you've been doing something to progress your goals)

### Attitude During Hard Times
I think the more foundational thing is that you don't give up. Everyone gets stuck at some point, whether it's not getting into a top tier school, hating their first job, or not getting promoted at their first job for several years. I even had friends get into medical school after 4 years of trying. 

If you *really* want to do this and don't see yourself doing anything else (at least in the 3-5 year timeframe)... just stick with it. 



It seems like you're wondering what creating a startup will be like. 

Here's a quick way to see what it's like, without quitting your job and making your partner angry:

Just go live a day in the life with a startup founder (preferably several to get a representative view).

If you work remote 1-2 days a week, you can go to an AI event or hackathon and look for startup founders to cowork with. Then you can pick their brain over lunch/dinner after coworking at a cafe or something. (they might even invite you to a founder hotbed like SHACK15, which has even more founders)

Early stage founders tend to have much more insight into things like:
- what the funding climate is actually like in your region
- how to deal with the stress of being an early stage founder
- hiring the first few people, etc

This is important because in 2024, the ground truth and what mainstream news reports about tech diverges significantly at times.

Anyway, hope this helps. I haven't started a startup yet, but it gives me peace to at least know what I'd be signing up for if I did.



I think most of those startups are definitely later stage, which are much safer. It's just that there is the constant risk of being no longer seen as that "breakout startup". For example, OpenAI releasing a killer search engine would hurt Perplexity.

Mistral this time last year would have been considered a breakout startup :/

I'd just be wary of any of the generative AI startups on that list, some of them have serious customer churn (so they wouldn't be considered breakout startups) and are having trouble raising a next funding round.


Well. To give you some hope, I was jamming Cursor AI with a bunch of questions for 20 minutes about how the opentelemetry library worked. What I really needed was a 3-line change, which I would have known had I worked with the library before.

Cursor definitely helps. But I've noticed that the larger the codebase, the worse Cursor does. For max accuracy, I've noticed that it does best on knowable work that has lots of documentation.

Things Cursor is bad at:
- refactoring code where the bugs/edge cases are unknown
- writing code that based on other internal code

btw I'm not sure if o1 actually helps, it's a little too expensive for my taste. I just stick to o1-mini for now. But hey, I'll take the free productivity boost for $20/month

Well if you can get into OpenAI or Anthropic, absolutely. But if you're part of the 99.99% that can't get in, it's okay. I knew someone who got into Midjourney and he had to be so so proactive to even get noticed.

Taro can give you all the resources in the world, but the harsh reality is that there is very little outside information on private companies. So if I were in your shoes, I'd try for big tech simply because there is much less unnecessary risk.

You never know if your startup
- is about to hit a major down round
- doesn't have product-market fit
- has 2 weeks of payroll left
- even has a good engineering culture

Especially if you're looking for a quick cashout, founders will totally sell you that dream to get you to join.

Some harsh truths:
- Work-life balance is worse for sure, unlike FAANG there are tighter deadlines because you should have shipped yesterday
- TC doesn't mean anything for you, it's only for your employer to rationalize paying you less
- Chances are, nobody has heard of your startup. And 99% of the time they never will.

If you think this would never happen to a break-out startup, it can at any moment. Meta is absolutely killing every other open-source LLM startup, including Mistral (which had the world's best cost/performance LLM for a few months).

Now, reasons to work at a startup despite all the instability:
- you get to ship fast, features take 1 week instead of 4 months
- you can impact the startup's success
- you get to work on a variety of things (infra, features, maybe even some ML)
- your coworkers are likely to enjoy their job
- unlike big tech, they won't sunset your project after you've sweat blood finishing it

Ultimately, nothing from the startup will likely remain. The equity can be worth pennies, nobody will remember how many all-nighters you pulled, and people don't care about the startups that never made it. What remains is your skills and experiences.

Well, at least that's what I tell myself so I can sleep at night

I was in your same position exactly a year ago, so this hits really close to home. It was so hard to get interviews that even with spam applying, I only got 2 callbacks in a month. Then I started contributing to open-source, and things started looking up. Here's some pointers:

\*\*For those who are later in their career, I think these principles still apply. The impact of doing this earlier in your career has more of a 0-1 effect than the 1-5 effect someone later in their career would see IMO

### **Pick A Niche**

So there's a deluge of MSCS graduates who want to work in AI. You need to focus on a single direction. There's several routes you can take:

- Model Serving
- Classic ML model development (collaborative filtering, etc)
- Large ML models (LLMs, stable diffusion, etc)
- Fine-tuning
- Generative AI tools
- ML infra tools like Flyte/Airflow
- Classic ML model dev and Large Model work typically require top conference papers to be in the top 1%

Before you dive into any route, make sure you do some due diligence so that you know roughly what it takes to be the top 1% in anything. Then decide if you're willing to put in the work.

### **Pick The Project Size**

Then there's size of the open source project. Small libraries/frameworks are too unknown to get you any real attention with recruiters. Large libraries/frameworks will take 1-2 years to get on the PMC.

Small projects are things like util libraries. Large projects are established frameworks like PyTorch or Kubernetes.

The "goldilocks zone" IMO is medium-size projects that are rapidly gaining traction. They have enough things on their roadmap that'll add immediate value and they should be the most welcoming of new contributors.

### **Making Core Contributions**

Start with something small. No sane person would ever let a stranger add changes to their core codebase. Start with something small like a cherry-pick commit or an integration.

Then it's time to align your contributions to the actual product roadmap. Attend contributor meetings. Talk to other contributors on Slack/Discord. Get involved.

As you contribute, you'll see yourself go up the "top contributors" list. You'll see yourself writing better PRs, writing cleaner code, and working on more impactful features.

### **Spinning Open-source Into Opportunities**

Getting to the top 10 or top 5 contributors for a medium-size library doesn't take that long. Even in the span of 1-2 months, you can get to Top 5 if you put in full-time effort.

Now you have some awesome résumé bullet points:

- Built core features: X, Y, Z, etc
- Top 5 contributor for Github project with 20k stars and 500K downloads/month

Now go! Find a project and contribute. You'll learn a lot + be helping out the community. I think that you can only re-write your resume so many times before you need to make a fundamental change. Making open-source contributions can help you make that fundamental change to your profile.