Pinned Tweet
hey everyone! i'm yoshik
- SRE, currently working remotely for a US startup
- prev @PhonePe
- working remotely for a US startup
- graduated with a beautiful 6.7 GPA
- no fancy college or insane hackathon rankings
- spent most of college inside linux instead of classrooms
- built random internet side projects that somehow made a few thousand dollars
- owns unhealthy number of domains
- love homelab setups; unfortunately can't build one
- tweets about AI bubbles while paying monthly subscriptions to 4 AI tools himself
- currently in my bed thinking about how can i become a billionaire
hmu if interested
LeetCode was always more relevant to the interview than the job.
Even before AI, when did your actual work require you to invert a binary tree?
Prove me wrong.
Yoshik retweeted
Be like Sunil Pai.
> Started as a developer in India.
> Became a tech lead at Yahoo.
> Helped scale Myntra's engineering team from 50 to 300.
> Joined Oculus and built VR experiences.
> Became a React Core team member at Meta.
> Made builds 10x faster at JPMorgan.
> Joined Cloudflare and doubled platform usage.
> Founded PartyKit.
> Got acquired by Cloudflare.
> Became a Principal Systems Engineer.
> Left Cloudflare after nearly 5 years.
> Now building interactive art installations for fun.
18 years of building software. And now he's just building whatever he wants.
Remote work is a blessing.
My city reached an AQI of 150-190, and I'm glad I don't have to step out for work.
Saving commute time is nice. Not having to commute through that air is a much better benefit
Be like Sunil Pai.
> Started as a developer in India.
> Became a tech lead at Yahoo.
> Helped scale Myntra's engineering team from 50 to 300.
> Joined Oculus and built VR experiences.
> Became a React Core team member at Meta.
> Made builds 10x faster at JPMorgan.
> Joined Cloudflare and doubled platform usage.
> Founded PartyKit.
> Got acquired by Cloudflare.
> Became a Principal Systems Engineer.
> Left Cloudflare after nearly 5 years.
> Now building interactive art installations for fun.
18 years of building software. And now he's just building whatever he wants.
Become a better infrastructure engineer in the AI era
uptime.engineer
perfect example of why adding more app instances can make a database problem worse
your app is slow, so you scale it up. but every instance has its own database connection pool.
so now you have:
> more app instances
> more database connections
> more queries competing for the same database
the app has more capacity to send work. the database hasn't gained any capacity to finish it.
if the database was already struggling, you've given it more work and more clients waiting for an answer.
check active queries, connection usage and where requests spend their time before adding more replicas. autoscaling can make the queue longer too.
Yoshik retweeted
Saw a guy telling Claude Code to consider disk space, backups, and cloud costs.
This dude is not getting replaced by AI.
Yoshik retweeted
Hot take: knowing AWS, GCP or Azure won't be enough to stand out.
What becomes less valuable:
- Memorising cloud service names
- Writing Terraform from scratch
- Copying reference architectures
- Knowing where to click in the console
What becomes more valuable:
- Knowing when one server is enough
- Choosing what happens when a database goes down
- Understanding when caching creates more problems than it solves
- Explaining why a more reliable design might cost more than the business needs
You need to know whether it's the right architecture, where it can fail, and how you'll recover when it does.
BREAKING: Amazon CEO Andy Jassy says AWS capacity is largely sold out through 2027.
A good chunk of 2028 is already booked too.
Amazon plans to spend $220 BILLION this year, and Jassy says it could spend even more to meet demand. They're keeping some capacity for on-demand customers, but the big chunks are getting booked years ahead.
This is why I'm bullish on infra.
Everyone sees the new model. Someone has to figure out where it runs, how to keep it up, and why the cloud bill doubled.
Knowing Linux, networking, and how to run systems gives you a way to work on AI beyond building another app around an API.
I prefer Claude Opus 5.5, but I'm using my ChatGPT subscription with Hermes because Claude won't let me use my subscription with a third-party harness
Saw a guy telling Claude Code to consider disk space, backups, and cloud costs.
This dude is not getting replaced by AI.
LiteLLM shipped malware. Anthropic moved off Git.
In this week’s Uptime Sync:
- What happened with LiteLLM and eMudhra
- Why Anthropic built its own source control
- How DigitalOcean pauses and resumes VMs in milliseconds
- Karpenter on EKS, Azure cost cuts, and Prometheus probes
- Six projects for monitoring networks, accessing servers, and running AI agents
Read the full digest👇
Yoshik retweeted
Interviewer:
Your Linux server says the disk is almost full.
You delete a large application log. The file disappears, but the available disk space barely changes.
The application is still running. New writes keep failing.
How would you check what's holding the space, and recover it without rebooting the server?
Yoshik retweeted
If you're a junior looking at infrastructure roles, here's what to learn:
1. Linux - Processes, memory, disks, permissions, systemd
2. Networking - TCP/IP, DNS, HTTP, TLS, routing
3. Scripting - Bash, Python
4. Version control - Git, GitHub
5. Databases - PostgreSQL, MySQL, indexes, replication
6. Caching - Redis, TTLs, eviction
7. Containers - Docker, images, volumes, networking
8. Cloud - AWS: EC2, VPC, IAM, S3, RDS
8. Infrastructure as Code - Terraform
9. CI/CD - GitHub Actions, Jenkins
10. Kubernetes - Pods, Deployments, Services, Helm
11. GitOps - Argo CD
12. Monitoring - Prometheus, Grafana
13. Logging - Loki, OpenSearch
14. Tracing - OpenTelemetry, Jaeger
15. Debugging - curl, dig, ss, strace, tcpdump
16. Incident response - PagerDuty, runbooks, escalation, postmortems
17. Reliability - SLIs, SLOs, error budgets
18. Security - Secrets, least privilege, patching
19. Recovery - Backups, restore testing, failover
Hot take: knowing AWS, GCP or Azure won't be enough to stand out.
What becomes less valuable:
- Memorising cloud service names
- Writing Terraform from scratch
- Copying reference architectures
- Knowing where to click in the console
What becomes more valuable:
- Knowing when one server is enough
- Choosing what happens when a database goes down
- Understanding when caching creates more problems than it solves
- Explaining why a more reliable design might cost more than the business needs
You need to know whether it's the right architecture, where it can fail, and how you'll recover when it does.
Interviewer:
Your Linux server says the disk is almost full.
You delete a large application log. The file disappears, but the available disk space barely changes.
The application is still running. New writes keep failing.
How would you check what's holding the space, and recover it without rebooting the server?
Become an infra engineer in thsi AI era
xitter.cf/AskYoshik/status/21136…
If you're a junior looking at infrastructure roles, here's what to learn:
1. Linux - Processes, memory, disks, permissions, systemd
2. Networking - TCP/IP, DNS, HTTP, TLS, routing
3. Scripting - Bash, Python
4. Version control - Git, GitHub
5. Databases - PostgreSQL, MySQL, indexes, replication
6. Caching - Redis, TTLs, eviction
7. Containers - Docker, images, volumes, networking
8. Cloud - AWS: EC2, VPC, IAM, S3, RDS
8. Infrastructure as Code - Terraform
9. CI/CD - GitHub Actions, Jenkins
10. Kubernetes - Pods, Deployments, Services, Helm
11. GitOps - Argo CD
12. Monitoring - Prometheus, Grafana
13. Logging - Loki, OpenSearch
14. Tracing - OpenTelemetry, Jaeger
15. Debugging - curl, dig, ss, strace, tcpdump
16. Incident response - PagerDuty, runbooks, escalation, postmortems
17. Reliability - SLIs, SLOs, error budgets
18. Security - Secrets, least privilege, patching
19. Recovery - Backups, restore testing, failover













