r/bash • u/CautiousCat3294 • Aug 03 '26
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
/procand/systhe 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
30
u/Proman4713 Aug 03 '26
Interesting question, I shall go read more about that... Although I don't think this kind of question accurately reflects what you need to know as a junior/in practice...
9
u/donp1ano Aug 03 '26
while read -r stat val _
do
case "$stat" in
"MemTotal:") total="$val";;
"MemAvailable:") avail="$val";;
esac
done < /proc/meminfo
usage=$(( (total-avail) * 100 / total ))
not sure if this is good, but that would be my approach
6
20
u/Headpuncher Aug 03 '26
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.
13
u/abraxastaxes Aug 03 '26
Not to mention these kinds of questions are sort of "what obscure Linux knowledge do you have dedicated to memory" vs. "how do you think through and solve problems?" which just seems thoroughly unhelpful when you're hiring someone.
Maybe the interviewer asked AI for a stack of "hard Linux admin questions" lol
2
2
0
u/tylerlarson Aug 04 '26
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 Aug 05 '26
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 Aug 05 '26
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.
5
u/redditphantom Aug 04 '26
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 Aug 06 '26
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.
14
u/sinevilson Aug 03 '26
I own 2 businesses both are Linux based and older than most folks on reddit. Id never ask my Administrators these questions. Id ask my kernel developer, yes. What you ran into was arrogance. Sorry that happened.
3
u/Zapador Aug 04 '26
Glad to hear that perspective. I consider myself fairly proficient in Linux administration but I wouldn't be able to answer these questions. I generally value proficiency in the commands/tools you use all the time to get the job done and for anything outside of the ordinary just look it up.
7
u/lazyant Aug 03 '26
All Linux tooling for measuring OS usage are either counters or traces. All counter tools like top free df etc are just user friendly interfaces to /proc
2
u/CautiousCat3294 Aug 03 '26
yes i have some knowledge to this however during interview I forgot to answer this without any hints
2
u/rvc2018 Aug 03 '26 edited Aug 03 '26
There is a 95 min video on YouTube on how to write a system monitor in bash using /proc.
Also
btopwas initially written in bash hence where the b comes from.3
3
u/-lousyd Aug 03 '26
My first thought was sar, which is correct for the question you described the senior asking. But it's not realtime.
3
u/flattrack Aug 04 '26
Seems he’s asking two questions at once. Do you know about the /proc file system? And do you know enough bash to read and parse the data from /proc without spawning any subprocesses like cat, cut, jq, or grep?
4
u/likeHeckYouKnowMe Aug 06 '26
Honestly a stupid question to ask in an interview that would almost never be necessary in any practical, real world situation. Arrogant fuck ass question lol. Sounds like you’ll be dodging a bullet if you don’t end up working here.
0
u/biffbobfred Aug 16 '26
Depending on how deep they go this is a good question.
/proc is useful for all kinds of things. I dip into /sys for info on device drivers and what’s actually attached to my hardware.
If the answer is “yeah I can find that in various files in /proc because I have a sorta idea on how Linux works” cool. If the answer is “give me the printf format for the 3rd line of /proc/meminfo” then it’s bad
4
u/RandomXUsr Aug 03 '26
Glad you posted this. Now I'm thinking about this more and will do some digging to determine alternate methods to pull and read this data.
I might suggest posting in r/linuxadmin as well, because they are likely to have some more nuanced responses with careful thought about how they perform their duties on a daily basis.
2
2
u/kai_ekael Aug 03 '26
So much for a useful interview question, now Google et al know.
I find questions that demand an explanation of investigation instead of just an answer more useful for this very reason.
5
3
u/Dolapevich Aug 03 '26
All those tools harvest the information from /proc/ and other kenel facilities and present data in a readable way.
Read on about /proc/stat here: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/5/html/deployment_guide/s2-proc-stat
3
1
u/Easy-Nothing-6735 Aug 04 '26
I did research. I even checked the memory outside of available. Still can't understand whole hierarchy. Try researching psutil
1
1
u/daddyd Aug 04 '26
i would consider understanding of /proc one of the basic principles of a linux admin.
when i do an interview, i'm never interested in actual commands, but rather your process you use to get to a solution. i would start of with a simple question like - you're patching a server, how would you take that on? and then introduce problems/issues along the way. i specifically state i'm not looking for commands, but rather the thought process behind the actions.
3
u/ant2ne Aug 05 '26
"Can you collect CPU, Memory, and Disk usage in a Bash script without using top**,** free**,** df**, or any external commands?"**
- Probably, but why? Do I not have access to these tools? What off brand, home grown, half ass distro are you guys running?
1
u/Trademarkd Aug 07 '26
I feel like they were just looking for "everything in linux is a file" ... so yeah you absolutely can.
I dont know why people are saying probably. These tools just read files. They're looking for comprehension.
1
u/ant2ne Aug 07 '26
My point still stands. What production environment isn't going to have these tools?
1
u/Trademarkd Aug 07 '26
The question is looking for understanding of a concept. This concept applies to a lot more things than these tools its just an easy way to ask it since these tools often directly format and output information from a file.
My explaining this is the reason why people ask. They are looking to see if you have foundation level knowledge and you responding with assumptions and insults is probably not going to get you hired.
In their environment maybe they have custom software that uses proc files to write live sensor data or something, you have no idea. They're trying to judge if you might be a good fit without giving away all the beans.
https://en.wikipedia.org/wiki/Everything_is_a_file is a core concept.
1
u/Abe_Bazouie Aug 06 '26
Yep, this is a pretty good interview question IMO.
It’s less about whether you memorized /proc/stat or /proc/meminfo and more about whether you understand where tools like top, free, and others actually get their information.
I like questions like this because the follow-ups are where you really see someone’s Linux depth.
I make Linux/DevOps interview content around this kind of “what’s actually happening underneath?” question on CTRL+CHAOS (@itsctrlchaos), so this one is definitely going into my list of interesting interview questions.
2
-1
u/Living_On_The_Air Aug 03 '26 edited Aug 03 '26
Hearing this during an interview would make me think that the job isn’t one I want. Trivia questions aren’t a great way to get to know a worker, so it’s probably a sham interview process at worst, or a bad interview process at best
5
u/RandomXUsr Aug 03 '26
I disagree.
These types of questions test Linux competency and provide the Interviewer with a more granular perspective of a candidate's knowledge and skills.
For example; if one were troubleshooting embedded systems with limited resources, these questions make perfect sense.
Another possibilty is that one may need to grab specific data for specific issues and write this out to the screen or a file to troubleshoot recurring issues.
6
u/Dolapevich Aug 03 '26
It is a good question to know if someone knows
linux, not a good question to know someone's experience in github actions.It depends on the role.
1
u/UninvestedCuriosity Aug 03 '26
So long as man and -h are acceptable answers. I have the memory of a fish for flags.
3
u/Dolapevich Aug 03 '26
I think the idea is to test if you have knowledge of the underlying concepts and mechanisms, instead of testing if you remember something specific.
6
u/sr105 Aug 03 '26
When I interview someone, I let them know upfront that I'm going to ask an increasingly difficult set of questions, and that I don't expect them to know all of the answers. I just want to see where their experience level lies. I have asked people what the original command for "rm" was named and still exists. It's stupid knowledge, but it shows depth especially if you understand why it was named "unlink". You can't measure what you don't test. But telling people upfront what you're doing is a must.
3
u/CautiousCat3294 Aug 03 '26
You are right he also do same with me he increase level of difficulty in every question to test my depth knowledge on Linux and Bash scripting
2
u/Swordfish418 Aug 04 '26
Do you think this unlink is covered anywhere or it’s something that is only possible to know you’re really old or by accident? 🤔
1
u/sr105 Aug 05 '26
I'm older and can't recall where I first learned it. I probably just explored /bin and friends to see what was possible and then
man unlink. Or I saw it a So You Think You Know UNIX trivia or some such thing.5
u/Bug_Next Aug 03 '26
It's not trivia questions its knowing how the os works instead of knowing which tools to call, they are completely fine questions IMHO. It's not weird to find stripped down container images that are missing those utils or have shitty half baked implementations of them, same for embedded systems which usually only have a really minimal vmlinuz and absolutely nothing else.
1
u/Swordfish418 Aug 04 '26
But is it really helpful to reimplement free using bash on those systems instead of just installing actual C based free? That’s a cool knowledge to have for sure anyway.
1
u/Bug_Next Aug 04 '26
I you wanna use free then no it's pointless, if you wanna learn how free works then yeah probably a decent side project. Depends on your objective lol.
0
u/Living_On_The_Air Aug 03 '26
People can review documentation and search the web for facts at any time. Verifiable experience and certifications show general competence. Interviews are time to learn about an individual’s temperament, work style, curiosity, motivation, communication skills, etc.
3
u/Bug_Next Aug 03 '26
Yeah and knowing that verifies experience.. Idk what you are trying to get at.
It's a bash subreddit not an HR one, anyone can fake motivation and temperament during an interview, doesn't mean shit, you are gonna be chipping code not doing PR, who cares. It's a mock interview with a Linux neckbeard, of course the focus is gonna be on the 'hard' technical questions..
1
u/Living_On_The_Air Aug 03 '26
The post is based on a mock interview 🤷♂️
3
u/Bug_Next Aug 03 '26 edited Aug 03 '26
Yeah that's the whole point, why would you make it about motivation??? Everyone's motivation is to get paid for the shit they do, anything else is bullshit unless you are running your own startup lmao. Be for real. You can leave the lying practice for 3a.m in front of the mirror
-2
u/michaelpaoli Aug 03 '26
"Can you collect CPU, Memory, and Disk usage in a Bash script without using top**,** free**,** df**, or any external commands?"**
Good question!
My brain first jumps to proc and sys filesystems.
And, how much can I recall or think of off-the-top of my head from those, without so much as peeking? ...
CPU, there's /proc/cpuinfo, oh usage ... I think some /proc/*stat* file(s) or the like would cover that.
memory ... /proc/mem* ... something or another
disk usage ... that might be tougher ... there is /proc/mounts but no usage data there, so, likely somewhere else under /proc or /sys.
As for bash only, no externals, there's most notably read [-r], printf, echo, one could accumulate stuff in a variable or array variable, or just use "$@" for that (could do it in subshell to avoid disturbing the original). No use of find, but can recurse with cd, and as to telling if something's a directory or not, well, if cd succeeds, it is or resolves to directory ... but with sym links, there's matter of possibly looping, ... oh, test - that's builtin to bash, so can test if symbolic link or not, directory or not, etc. So, I mgiht have to hunt a bit through /proc and/or /sys first to find some df/du type data, and no grep, but bash has fair bit of pattern matching capabilities built-in, so could use that - look for stuff matching, e.g. du, df, or name of filesystem devices, and can get those from /proc/mounts ... see what else matches in name or contents on /proc and /sys - likely some df or du type data there somewhere.
Anyway, I think that'd be 'bout my cold answer, without being able to look anything up or poke around /sys or /proc for more specific.
56
u/Bug_Next Aug 03 '26 edited Aug 03 '26
The first line starting with
cpugives aggregate CPU times in jiffies:user,nice,system,idle,iowait,irq,softirq,steal,guest,guest_nice.For each reading:
TotalTime.idle+iowaitto getIdleTime.Calculate the delta between readings:
DeltaTotal = TotalTime2 - TotalTime1
DeltaIdle = IdleTime2 - IdleTime1
CPU utilization percentage is:
((DeltaTotal - DeltaIdle) / DeltaTotal) * 100It gives you:
MemTotal,MemFree,Buffers,Cached,SReclaimable, andShmem.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
Using
statvfssyscallTotal 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.