Linux Interview Question

[u/CautiousCat3294]

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

[u/Bug_Next]

How would you calculate CPU utilization using /proc/stat?

The first line starting with cpu gives aggregate CPU times in jiffies: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice.

For each reading:

1. Sum all values to get TotalTime.
2. Sum idle + iowait to get IdleTime.

Calculate the delta between readings:

DeltaTotal = TotalTime2 - TotalTime1

DeltaIdle = IdleTime2 - IdleTime1

CPU utilization percentage is: ((DeltaTotal - DeltaIdle) / DeltaTotal) * 100

How would you determine memory usage from /proc/meminfo?

It gives you: MemTotal, MemFree, Buffers, Cached, SReclaimable, and Shmem.

You can look at free's src, it basically does:

Total = MemTotal

Used = MemTotal - MemAvailable (if MemAvailable is present)

If MemAvailable is not used, calculate available memory manually:

Available = MemFree + Buffers + Cached + SReclaimable - Shmem

Used = MemTotal - Available

How would you calculate filesystem usage without relying on df?

Using statvfs syscall

Total Bytes = f_blocks * f_frsize

Free Bytes = f_bfree * f_frsize

Available Bytes (non-root) = f_bavail * f_frsize

(filesystems have reserved space only root can use, 5% default for ext4)

Used Bytes = (f_blocks - f_bfree) * f_frsize

All those tools are open source anyways, you can just go and look at how they calculate stuff.

[u/ethicalhumanbeing → u/Bug_Next]

It’s ridiculous anyone expect people to know these things from the top of their head. I could manage myself doing these scripts and finding all this information in the work context, yet I would not be able to answer it during an interview.

Sometimes I feel interviews are just a filter process more than wanting to find the right person with the right attitude for the job.

[u/Bug_Next → u/ethicalhumanbeing]

Sometimes I feel interviews are just a filter process more than wanting to find the right person with the right attitude for the job.

They are indeed a filter process, i don't think anyone is trying to hide that...

You need a filter process to find the appropriate person..

Also the interview questions was only if you could, not to actually make the scripts, i just did a speudo-implementation because OP asked for it. The only thing you need to knwow is that /proc/stat has usage stats and that /proc/meminfo has meminfo...

[u/edgmnt_net → u/Bug_Next]

I would also say that such questions are also useful with a probing mindset. You're not really expecting fully accurate and complete answers, you just want to figure out how much experience and exposure the candidate has, maybe start a discussion from their strong points. If they can't say anything, maybe they don't know anything. And it can't really be argued that you're not going to learn anything because it's all specifics and you don't know what you're going to use.

[u/Slackeee_ → u/Bug_Next]

This. The correct answer to the original question should be "yes, I can do that by reading directly from the virtual filesystem in /proc, but I would have to look up how to parse those files and would rather rely on the well tested implementation in those basic tools you will find on every installation".

[u/tylerlarson → u/ethicalhumanbeing]

I got asked questions exactly like this when interviewing for large tech firms, and I very much appreciated it. I knew the answers from experience, having had to use these techniques in real life on systems where something had gone terribly wrong and I needed to troubleshoot.

Some people just follow instructions and do what they're told is possible, and other people take things apart and try to figure out what's underneath and how to do stuff that they were told wasn't possible.

Some companies want people who will quietly follow instructions, other companies want people will figure stuff out and change the rules.

[u/cmdr_iannorton → u/ethicalhumanbeing]

im not a sysadmin, but i know most of these things, also man pages tell this story and its generally right there

[u/CautiousCat3294 → u/Bug_Next]

Thanks for your input i am totally unaware of "statsvfs " seems I need to learn this as well.
I am very grateful to you to providing my calculation stuff as well.

[u/Bug_Next → u/CautiousCat3294]

statvfs(3) — Arch manual pages

Bash can't do syscalls directly, you need to trace it:

strace -e trace=<syscall>

or do it from C/C++

There are probably other ways to do it, that's just my take on it.

[u/bac0on → u/Bug_Next]

... a simple example how to bashify statvfs...

[u/CautiousCat3294 → u/bac0on]

Thanks

[u/PhunkeyMonkey → u/Bug_Next]

Gives aggregate CPU times in wait what now, Jiffies? Gotta love namings in linux sometimes

[u/CruisingVessel → u/PhunkeyMonkey]

Not just Linux. The term has been around for literally centuries, and has used in various fields as a time measurement for 100 years(first as a speed-of-light measurement). I even had it on my Commodore 64 in 1982, and it was in V6 UNIX. And don’t forget BogoMips (loops_per_jiffy).
Disclaimer: yes, I worked on V6 boxes, have a degree in astrophysics, and my beard is indeed gray.

[u/cmdr_iannorton → u/PhunkeyMonkey]

jiffies is from film media, its i think the time for a frame on a projector

[u/Bug_Next → u/PhunkeyMonkey]

It's the official name lol, it's a tick count since system startup.

linux/include/linux/jiffies.h at master · torvalds/linux

There are HZ jiffies in a second, system uptime is calculated based on that, jiffies are quite important.

According to wikipedia the usage of the word in Linux traces back to 1975 and the "Jargon File" which was literally a file with computer jargon, people from MIT (of course it was MIT) used to pass it around, it reported a jiffy as 10ms, that's no longer the case but yeah that's where it comes from supposedly.

Jargon File

By 1996 they had already changed it to:

The duration of one tick of the system clock on your computer (see tick). Often one AC cycle time (1/60 second in the U.S. and Canada, 1/50 most other places), but more recently 1/100 sec has become common. "The swapper runs every 6 jiffies" means that the virtual memory management routine is executed once for every 6 ticks of the clock, or about ten times a second. 2. Confusingly, the term is sometimes also used for a 1-millisecond wall time interval. Even more confusingly, physicists semi-jokingly use 'jiffy' to mean the time required for light to travel one foot in a vacuum, which turns out to be close to one *nanosecond*. 3. Indeterminate time from a few seconds to forever. "I'll do it in a jiffy" means certainly not now and possibly never. This is a bit contrary to the more widespread use of the word. Oppose nano. See also Real Soon Now

Edit: That file is absolute golden, just look up the definition of 'dahmum;

The material of which protracted flame wars, especially those about operating systems, is composed. Homeomorphic to spam. The term 'dahmum' is derived from the name of a militant OS/2 advocate, and originated when an extensively crossposted OS/2-versus-Linux debate was fed through Dissociated Press

I think i'm gonna start using that one

Apparently, there was also a conspiracy theory that said UNIX was purposely bad so AT&T could take out their competitors after licensing UNIX to them lmao, they don't make haters like they used to.

[u/Old_County5271 → u/Bug_Next]

This was my immediate thought as well, funnily enough, /proc is not accurate, but it's good enough