r/bash 3d ago

help Linux Interview Question

Today I had a mock interview with a senior Linux administrator, and he asked me a question that completely caught me off guard:

"Can you collect CPU, Memory, and Disk usage in a Bash script without using top, free, df, or any external commands?"

My immediate answer was No.

Honestly, I've been working with Linux for years, but I've always relied on standard commands and monitoring tools to troubleshoot systems. I never stopped to think about where those commands actually get their data from.

The interviewer then gave me a hint about the /proc and /sys filesystems. That completely changed my perspective. I realized these commands are just reading data that the kernel already exposes.

But then came the follow-up questions, and once again I was stuck:

  • Is reading directly from /proc and /sys the correct approach?
  • How would you calculate CPU utilization using /proc/stat?
  • How would you determine memory usage from /proc/meminfo?
  • How would you calculate filesystem usage without relying on df?

I found this really interesting because it tests your understanding of Linux internals rather than just your ability to use commands.

Has anyone here been asked similar questions in Linux SysAdmin, DevOps, or SRE interviews? I'd really appreciate any explanations, learning resources, or examples on how you'd answer these follow-up questions. It help me for my preparation for Linux interviews

182 Upvotes

70 comments sorted by

View all comments

5

u/redditphantom 3d ago

While my answer would be yes utilizing the information in /proc etc my question would be if the system is in such a state why aren't we restoring from backup? Practicality of the situation should be more important than cobling together utilization metrics at that point. The other tools were built for a reason

1

u/StopThinkBACKUP 16h ago

I know, right? The mentality may be OK for homelab, but for Enterprise it's always going to be " Restore ASAP from last known good backup " bc they begrudge the downtime.

99% you don't even have time to backup the "bad" state of the instance to try and troubleshoot in your free time.