Hello friends!
Welcome to another Sloth Bytes. You like the new animated logo?
This will be our first interview!
I hope you all enjoy it. If you’re an engineer and want to share career advice, what you’re working on, or your workflow, let me know!
Latest Posts
If you’re new, or not yet a subscriber, or just plain missed it, here are some of our recent editions:
The AI notetaker that gets the hard words right
Your AI is only as good as what you feed it. Feed it a transcript with your product names, acronyms, and numbers spelled wrong, and you spend the afternoon hand-fixing the output.
Wispr Flow Notetaker uses your dictionary and calendar, so product names, acronyms, numbers, and uncommon names come out spelled right. It pops up when your meeting starts and captures Zoom, Google Meet, Teams, and Slack huddles with one click, no bot joining the call.
Then your meetings show up inside Claude or ChatGPT through the built-in connector. No copy paste. Try Notetaker free on Mac and Windows.
Learn AI in 5 minutes a day
You don't have to scroll every AI thread, track every new tool, or watch every demo.
The Rundown AI breaks it all down for you — the latest AI news, tools, and tutorials in one free 5-minute email every morning.
Trusted by 2M+ professionals at Apple, Google, and NASA.
Who is Dara?
Be sure to follow him!
Dara Adedeji is a CS student at UMBC who’s built a lot of cool stuff and yaps about it online.
Here are some of his personal projects:
Icarus: a local-first, open-source Valorant strategy planner with 1,000+ users. He started it in his senior year of high school after losing a strategy he hadn't saved, and he credits it with making him a better developer.
WhichAI.dev: a side-by-side comparison of which AI models can actually design, with around 16,000 monthly active users.
Weaver: a desktop widget platform where you build widgets by prompting your agent, then share and remix them.
Before all that: a grade calculator app for students in his school district and a notes app shipped on both the App Store and Play Store.
Now he’s interned at Amazon and has a return offer for next summer.
How he got into Amazon (It’s not the usual way)
This was a surprise to me.
The normal route for an Amazon SDE internship looks like this:
Apply
Take an online assessment
Do those torturous interviews
Get that delicious offer (or don't)
Preparing for these internships usually involves 300 LeetCode problems and a lot of praying.
But Dara didn’t do that… he didn’t even do a technical interview.
Dara's Amazon internship came through the Amazon Future Engineer scholarship.
It’s a program for U.S. high school seniors going into CS with financial need, where you can get up to $10,000 a year for college plus a paid Amazon internship, usually after your first year.
The 2025-2026 cycle is closed, but you can sign up for the next one.
A lot of people don’t know these programs exist. There’s also a program for first- and second-year college students:
Amazon Propel (first- and second-year college students): a roughly 12-week paid software internship focused on first-gen and underrepresented students, starting with a short SDE bootcamp.
Applications usually open around August to October. (Might be closed now)
You’ll have to find it within Amazon’s internship postings.
Useful AI prompt: Read this newsletter post 🦥 He got into Amazon without an interview. I want you to interview me and search for more of these types of special programs where I qualify. Give me every route, its deadline, and what I should do to prepare.
Wait, so I can skip LeetCode?
Haha. No.
Even Dara shut it down immediately:
"No, no, you should definitely do LeetCode."
Opportunities like Future Engineer are rare, competitive, and only open at certain points in your life. Almost every other route (regular internships, full-time roles, switching companies later) still runs through an online assessment and technical interviews.
So he still practices it just in case, but he also takes it a step further.
Build your project while you practice for interviews
He used to feel like he had to choose between practicing interview problems and working on a project he cared about.
Which is 100% true. I remember I would have to pick between working on a project or preparing for interviews, but now that’s no longer the case.
Now he gives an AI coding agent a project task while he solves a LeetCode problem.
This lets him make progress on both ends.
Of course, Dara doesn’t just let the AI do everything. He makes sure he understands the project well enough to debug it, change it, and talk about it in an interview.
If you can’t explain your project or the architecture, that’s a problem.
Here's a small version you can try:
Hand off one clear task. Give your agent a small bug fix or feature, the relevant context, and a definition of done.
Practice while it works. In the meantime, solve an interview problem yourself. Explain your approach and work through an example. If you’re stuck, ask AI for a hint before asking for the solution.
Come back and check the result. Review the changes, run the relevant tests, and try the feature. Then ask AI to explain how it works and why it was built that way.
Additional strategies to help you prepare for interviews
1. If you’re learning a topic, have AI build you something to learn it faster.
Ex: If you’re studying graphs, have an agent help build a visualizer that steps through BFS and DFS on your own inputs.
Now you have a starting point for a project and a way to help you learn better.
2. Learn system design by building it.
Pick an architecture you keep seeing in interviews (a queue, a cache, a load balancer in front of a few services) and build a small project in that shape with AI.
You'll understand why each piece exists way faster than reading about it.
3. Act like the manager.
You write the tickets, define what "done" looks like, and review the work. The agent does the coding.
That's closer to the real job than you'd think. Engineers don't just write code all day. The goal is to solve a problem, and code is just one part of that.
Doing it this way trains the skills that actually matter: breaking a problem into tasks, figuring out the right solution, and judging whether the result works. That's way more practical experience than grinding syntax.
How an Amazon internship actually works
Amazon's SDE internships are 12 weeks, full-time, and in office.
You're matched with a manager and a mentor, and you're expected to own a project from start to finish on a real team.
At the end, you present the project, and a strong performance can turn into a return internship or a full-time offer.
Your team also decides a lot
Your experience at a company usually depends heavily on your team, and you usually don’t get to pick. You could work at the same company on a different team and have a completely different experience:
Strictness: some teams treat intern code very seriously, while others are more relaxed, especially on internal tools.
Tasks: one intern project could involve building a new tool from scratch. Another could involve learning a huge, old service to make one small change safely.
Support: some teams have mentors who are available every day. On other teams, mentors may simply be too busy.
Freedom: which tools you can use (AI included) depends on your team and how critical the system is.
Dara saw this firsthand. Some interns he knew had to deal with very strict CRs (Amazon’s version of PRs), where getting code merged was a whole process.
So if you land on a strict team, that doesn’t define the entire company.
If I’m being honest, though, most big tech intern projects aren't world-changing.
They’re usually scoped small on purpose so you can gain experience and not break anything critical. This usually means you’ll work on an internal tool, a dashboard, or a script that automates something annoying.
Dara's project was an internal tool, and what he did with it is the interesting part.
Dara's internship experience
Dara interned on a team working on a large-scale retail routing system at Amazon.
His intern project was optimizing a log-analysis tool.
You see, when something breaks in production, engineers dig through logs to figure out what happened. At Amazon's scale (remember, we’re talking worldwide), that's a lot of logs and information.
Dara said the logs were a few terabytes and processing them used to take a day.
Which means every time you need answers from the logs, you wait a day.
If you mess up and get the wrong logs, you’ve got to wait another day.
You can see how that’s a problem.
Dara optimized the log analysis to run in parallel using AWS Glue, Parquet, and Athena. According to him, processing went from about a day to about seven minutes.
Already insane results from an intern project, but he didn't stop there.
Teammates still had to open a query editor and figure out how to pull what they needed. Even though it was now a fast tool, it was still annoying to use.
Average internal tool experience, am I right?
So Dara watched the tickets his team was working on, wondered if AI could make the process easier, and started testing an idea:
He gave AI the issue and the necessary log information to see if it could solve it.
Once the AI finished, Dara showed the output to the teammates working on the issue so they could confirm whether it was right.
The output was useful, and because Dara shared it directly with his teammates, they became more willing to trust the workflow.
You might be surprised by this, but even at big tech companies, not every engineer knows what AI tools can do right now.
Once Dara had his teammates’ trust, he started to create reusable skills and MCP connections to give the agent access to the logs and context.
The final result was an agent-first CLI tool called Parthenon.
This tool simplified the workflow a lot:
Paste a ticket link
Let an agent gather the relevant evidence
Get a report you can share
Teammates no longer had to write queries or even open the log analysis tool themselves.
He brought the CLI into Slack, where the team already worked, and the results speak for themselves (from his résumé):
Investigations went from 10 days to 15 minutes.
The new workflow helped resolve 150+ production incidents in one month.
So not only did Dara make the tool faster, but he also took a workflow everyone was suffering through on one of Amazon’s most critical systems and made it easy enough that the whole team used it.
His advice for finding what problems to solve was this:
"Try to make the right things the easy things and really understand the people you're building things for."
That’s the kind of impact that turns into a return offer.
Advice you can use this week
1. Build for a problem you actually have.
"Don't build anything that doesn't solve a problem in your life or solve a problem of somebody very close to you in your life."
You should think about this before you start: who has the problem, how they deal with it today, and what better looks like.
2. Get one real user before you add features.
Most side projects die without anyone else ever touching them.
Hand your project to one person. Don't explain anything.
Watch where they get stuck, and fix that before you build anything new.
3. Make it easy, not just fast.
Dara's tool got way faster and people still didn't use it until it fit into how they already worked.
4. Write the checks before the code.
Dara uses code review tools, tests, screenshots, and computer-use checks.
In his words: "as we write more code with AI, you need to build systems and invest in systems to help verify that your changes are actually the things that you're going to do."
5. Turn a repeated process into a skill.
Dara has a skill for preparing pull requests that explains how the information should be presented, which checks to run, and when to include images.
As he put it, “the point of the skill is to encode behavior.”
Pick the task you explain to your agent most often, write down the steps and what “done” looks like, save it as a skill, and test it on something tiny.
6. If you land an internship, look for pain points (and show what's possible).
Your assigned project is, of course, important, but it’s also important to notice the areas where people are struggling.
Try to notice patterns or common pain points.
If your team is allowed to use AI, see if it can help solve real problems and be sure to show the results like Dara did. Remember that not everyone knows how powerful AI is.
Track your impact with real numbers as you go (time saved, people using it, performance improvements, etc.). You’ll want them for your performance reviews.
A useful AI prompt you can use
Read this newsletter 🦥 He got into Amazon without an interview and interview me relentlessly until you have enough information to help me apply its advice to my goal.
Ask one question at a time and wait for my answer. Start with what I want to achieve and by when. Explore my current skills, projects, available time, resources, obstacles, and what I've already tried. Follow up when my answers are vague. Skip questions I've already answered.
Ask only questions that could change your recommendations. Once you have enough information for a useful plan, stop interviewing. Help me narrow the goal if it doesn't fit my constraints.
Then give me:
The advice from this newsletter that fits my situation, and why.
Three prioritized actions, each with an estimated effort and a clear definition of done.
Where AI can help and what I should practice, understand, or verify myself.
One step I can finish in the next 30 minutes and a way to check my progress after a week.
Separate the newsletter's advice from your own suggestions. Flag assumptions. If you recommend programs or tools, verify current details using official sources and link them.
Did you like the format?
I hope you all found this interview helpful. If you did like it and want more:
What would you like me to ask in interviews?
If none of these are what you want, reply and tell me one question you want me to ask the next guest.
That’s all from me!
Have a great week, be safe, make good choices, and have fun coding.
If I made a mistake or you have any questions, feel free to comment below or reply to the email!
See you all next week.
What'd you think of today's email?
Want to advertise in Sloth Bytes?
If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.
