From Late-Night Learner to Systems Engineer: How Sakeena Sajid Built Consistency Into a Career

sakeena sajid — Fri, 18 Sep 2026 17:54:17 +0000

Three years ago, [Your Name] was running basic terminal commands past midnight, squeezing DevOps practice into whatever hours remained after a full day of other responsibilities. Today, that same discipline has turned into a career built on shipped work, not credentials.

The turning point started during the DevOps Micro Internship (Self-Paced Engineer Track), where the biggest lesson wasn't a tool or a framework — it was realizing that consistency mattered more than motivation. Sessions didn't depend on feeling ready or inspired; they happened because they were scheduled, every night, distractions removed, phone on silent, one task at a time.

That habit compounded. What started as short nightly sessions turned into a documented body of work — networking fundamentals, Linux, Git, containers, and cloud infrastructure, each week written up and published publicly instead of left as private notes. That public documentation later became the proof recruiters actually looked at, more than any resume line.

The first professional role came as a Junior DevOps Engineer, automating deployment pipelines and reducing manual release overhead. From there, the path moved toward infrastructure and cloud systems work, built on the same principle that started it all: doing things hands-on, messily at first, rather than waiting to fully understand everything before starting.

Along the way, certifications came — but they were never the point. The real evidence was always the shipped projects, the documented weeks, and the systems that worked in production, not just in theory.

Outside of the day job, the habit of writing stayed. Technical write-ups, breakdowns of concepts once found confusing, and mentoring newer engineers just starting their own DevOps journey — the same way a structured system once helped make sense of the chaos of "where do I even start."

When asked what actually made the difference, the answer was never talent or timing. It was showing up on the nights that felt inconvenient, building an environment with fewer distractions, and refusing to wait for motivation before doing the work.

This work is part of the DevOps Micro Internship — Self-Paced Engineer Track.

**P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — campus
— by Pravin Mishra. My graded progress is public: https://lnkd.in/eg8MhnM3 · Start your DevOps journey: https://lnkd.in/eDE7ydGW

Week 00" The Journey of a Click" Understanding What's Behind Every Website Load— DevOps Micro Internship

sakeena sajid — Fri, 18 Sep 2026 17:30:29 +0000

Imagine writing a letter and dropping it in a mailbox. You don't personally carry it across the country — postal workers, sorting centers, and delivery routes handle that for you, using a shared system of rules: addresses, zip codes, and stamps. Open any website, and something remarkably similar happens — except it takes milliseconds instead of days.

In Week 0 of the DevOps Micro Internship (Self-Paced Engineer Track), I used a simple example to understand this system: a bookstore called EpicReads, hosted on a server in Finland, being visited by someone in the US.

*Finding the Right Address First
*
Before any "letter" can be sent, you need an address. That's the role of DNS. When someone types epicreads.com, computers can't actually understand that text — they only work with numbers. DNS acts as a directory service, looking up the domain and returning the correct IP address, like 52.172.142.222.

This lookup happens through what's called an A Record — a DNS entry that maps a domain name straight to an IPv4 address, so the request knows exactly where to go next.

Every Device Has Its Own Address

Just like every house has a unique postal address, every device connected to the internet has an IP address. The EpicReads server in Finland is no exception — its IP is what allows data from across the globe to find it, no matter how many networks it has to pass through along the way.

The Letter Doesn't Travel in One Piece

Here's where it gets different from mailing a physical letter: the webpage doesn't travel as a single unit. It gets split into small units called packets, in a process called packet switching. Each packet carries its own destination tag and can take a completely different route to get there — whatever path happens to be open and fastest at that instant — before being put back together at the other end.
**
Making Sure Nothing Is Missing
**
Splitting data into pieces creates an obvious risk: what if a piece goes missing? This is handled by TCP/IP. IP is responsible for the addressing and routing, while TCP double-checks that every packet actually shows up, reorders them if needed, and asks for a resend if something didn't make it. Nothing gets marked "delivered" until it's confirmed complete.

Sealing the Envelope — HTTPS

A regular letter can technically be opened by anyone who intercepts it. Website traffic avoids that problem through HTTPS, which encrypts the connection between the browser and the server. Whatever information is being exchanged — a search query, a login, a payment — stays private in transit.

What Happens After the Request Arrives

Once the request lands at the Finnish server, it isn't handled by one single piece of code. Most real applications, EpicReads included, are organized using a three-tier architecture:

Frontend — the part the user actually interacts with, often built with React.js or plain HTML5/CSS3
Backend — the logic layer that processes the request, commonly built with Node.js (Express) or Python (FastAPI)
Database — where the actual book listings, prices, and orders are stored, using something like PostgreSQL or MongoDB

Keeping these three separate means the database isn't directly exposed to the internet, and each layer can be scaled up independently as more people start visiting the site — something a simpler two-tier setup (frontend connecting straight to the database) struggles with once traffic grows.

Delivery Confirmed

By the time the browser renders the EpicReads homepage, DNS has resolved the address, packets have crossed multiple networks and reassembled correctly, TCP/IP has verified nothing was lost, and the backend has pulled the right data from the database — all within a fraction of a second.

*Getting My Own Workspace Ready
*
Alongside working through these concepts, I also set up Visual Studio Code as my development environment — configuring the terminal, picking a theme, and running a few basic commands to make sure everything was working correctly for the weeks ahead.

Closing Thoughts

What looks like an instant, almost invisible action — opening a website — is actually a coordinated relay involving DNS, IP addressing, packet switching, TCP/IP, encryption, and backend architecture. Understanding this sequence has made the idea of "infrastructure" feel a lot less abstract, and a lot more like something I can actually reason through.
This work is part of the DevOps Micro Internship — Self-Paced Engineer Track.
**P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — campus
— by Pravin Mishra. My graded progress is public: https://lnkd.in/eg8MhnM3 · Start your DevOps journey: https://lnkd.in/eDE7ydGW

DEV Community: sakeena sajid

From Late-Night Learner to Systems Engineer: How Sakeena Sajid Built Consistency Into a Career

Week 00" The Journey of a Click" Understanding What's Behind Every Website Load— DevOps Micro Internship