IT Infrastructure
Storage Engineer
Capacity, durability, and the restore nobody has tested. A specialism where the failure mode is total and rare, which is what makes it hard to fund.
Storage engineering owns where data physically lives and whether it survives. The discipline spans block, file and object, on-premises arrays and cloud services, and the increasingly important question of how to feed a GPU cluster fast enough that expensive accelerators are not waiting on reads.
| Time | What you are actually doing |
|---|---|
| 09:00 | Capacity forecast. Growth rate against contracted capacity and lead time, because storage that arrives after you need it is not capacity. |
| 10:30 | A performance complaint. Latency on a volume, and the work is separating array-side contention from a noisy neighbour from an application doing small random writes it should be batching. |
| 13:00 | Restore test. Not a backup check — an actual restore of a real dataset to a real environment, timed. This is the job. |
| 15:00 | Tiering and cost. What can move to cheaper storage without breaking a recovery objective. |
| 16:30 | Replication health after a link event, and whether the secondary is genuinely consistent or merely present. |
The decisive round
“How do you know your backups work?”
Interviewer: “How confident are you that you could recover from a serious data loss?”
A weak answer. “We run daily backups with monitoring and alerting on failures, retain them per policy, and replicate offsite.” Describes backup, not recovery. Every organisation that has lost data had backups running successfully.
A strong answer. “A backup that has never been restored is a hypothesis, so I would answer with restore evidence rather than backup evidence.
What I would want: a timed restore of a real dataset, done recently, to an environment that resembles production. Not a file — the actual system. And the number that matters is not whether it worked but how long it took, because a restore that succeeds in forty hours does not meet a four-hour recovery objective and that gap is where organisations discover the truth during an outage.
Then the failure modes I would specifically test for. Consistency — a database backed up without quiescing may restore into a corrupt state, and file-level success tells you nothing about that. Dependency order — can we restore the application if identity is also gone, because if the directory is a prerequisite and it is in scope of the incident, the plan does not work. Immutability — if ransomware reached production, can it reach the backups? Anything the production credential can delete is not a backup, and this is the modern failure that traditional plans miss entirely. The runbook — can somebody who is not me perform it, at 3am, without the person who built it.
So my honest answer to ‘how confident’ is: as confident as the date of the last full restore test, and I would tell you that date. If it is more than six months old, the correct answer is that I do not know.”
Answering with restore evidence, naming immutability against ransomware, and being willing to say 'I do not know' with a reason. That last one reads as senior rather than as weak.
- Do a real restore of something you care about and time it. Then write the runbook.
- Know the arithmetic: RPO, RTO, and what replication lag means for each.
- Understand the ransomware model — immutable and air-gapped copies, and why anything reachable with production credentials does not count.
- If targeting AI infrastructure, learn parallel filesystems and why feeding a GPU cluster is a throughput problem unlike anything in enterprise storage.
Compensation
| Market | Band | Notes |
|---|---|---|
| United States | $110k – $200k | AI-adjacent storage — parallel filesystems, high-throughput — pays above |
| India | ₹10L – ₹35L total | Steady enterprise and GCC demand |
The book for this field
Infrastructure & Reliability
Reliability and error budgets, capacity arithmetic, networks, storage and the restore you have not tested, the physical layer, a debugging method that transfers, running production, and an honest look at Kubernetes. Plus a Middleware section — web and application servers, messaging (IBM MQ, Kafka) and managed file transfer, from basics to licensing and cost.
Also read for this role
Networks, Automation, Connectivity & Data Centres
Twelve chapters from a single packet to a submarine cable. Subnetting worked by hand, BGP and why hijacks succeed, DNS and the two outages worth knowing by name, TLS and the expiry that still takes down companies, cloud networking with the arithmetic, transit and peering, colocation and what an AI rack did to the industry, and four debugging scenarios worked end to end.
All 18 chapters in Networks, Automation, Connectivity & Data Centres →
Cross-cutting
Skills every archetype tests
These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.
Practice the 8 IT Infra questions → · Back to IT Infrastructure →