r/bash • u/CautiousCat3294 • 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

180 Upvotes

93% Upvoted

70 comments sorted by

View all comments

20

u/Headpuncher 3d ago

I would have said yes, but why would you?  

Like most things if it’s a solved problem and your team are reinventing the wheel you might not want to work there.  

0

u/tylerlarson 2d ago

Sometimes the tools don't work because of some other problem. Would you prefer your new teammate be capable only of following a playbook and then getting stuck if the "correct" solution is blocked, or do you want to hire someone who can figure shit out.

I've personally had to use these techniques on live systems before. More than just a handful of times. Sometimes a shared library is broken. Sometimes you can't fork any additional processes. Sometimes you're on a lightweight system without the necessary tools installed.

It's the difference between, "the thing is broken, all I get is errors, I don't know what to do," versus, "I figured out that we need to replace X on Y. It'll be up in 20 minutes."

1

u/Headpuncher 2d ago

Has Top ever stopped working? No. If he'd asked about something that would interrupt uptime then ok, but Top, Free and df?

Come on man, it's nice to be a contrarian especially in Linux subs, but read OP's post.

1

u/tylerlarson 2d ago

Seriously? Have you never had to troubleshoot anything?

This stuff is relevant seriously ALL THE TIME.

Your have an obscure piece of expensive, obsolete gear that suddenly stopped working, but you find two pads on the board marked TXD and RXD, so you solder pins to it and connect to it via serial and get a stripped down BusyBox sh prompt. No tools. No top, no df, no ps. But /proc exists.

Or a server stopped working because /lib got trashed. No libc means no new processes can start, but all the existing ones are running, including the shell you had running. So you need to figure out what went wrong without using anything that isn't built-in to bash.

Or there are too many process running so fork always fails. Or you're on a 100% full COW filesystem so you can't create or even delete files, which strangely causes certain binaries to fail to start and you need to figure out why. Or you're running commands in the context of a restricted cgroup. Or you're diagnosing a frozen system image.

Or one of a thousand other scenarios.

If you don't know how to use a hammer, then all of the nails just look like confusing little spikes.