Thank you for that write-up! Understanding Linux more deeply isn’t a barrier to me. I’m now quite certain DBA is my next goal - it really does sound like an evolution of what I’ve been doing so far. I’ll look around on Coursera for some certs that might convince my current employer I’m serious about helping manage the database.
Also, since it was offered I’ll take it as a bit of practice:
fsck
reserved space (e.g. system files, backups, hidden partition)
hidden or deleted files that are in use
incorrect mount
simultaneous access from multiple mounts (?)
Permissions (?)
Question mark against things that seem like possible causes, but I’m not sure if they are. Most of these would probably show the space as used rather than free, but did I miss checking anything major that I wouldn’t find with a bit of searching?
You are bringing up good approaches and you would have been hired if you could explain how you would start to troubleshoot some of those issues.
The answer to the problem that this team ran into was that you can actually run out of inodes in a filesystem if you have a very large number of relatively small files, and that might show up as failed writes that can make a program like a DBMS say “the disk is full”.
Regarding getting hired though, I have no idea about the market and pay nowadays especially wherever you are. I hope it’s good for you, it was certainly good for me in the 2010s in Eastern Europe, but I’ve heard it’s shit everywhere these days.
Thank you! One more question: “explain” has always tripped me up. How much detail is necessary, vs too much, for a technical interview? Because in my mind “fsck” is self-explanatory, as would be “check the inode count”. Should I cover everything like I’m explaining it to a new user, or is there a baseline skill level I’m expected to address?
Usually what I would do is start with a baseline summary, and then either dive into a step-by-step on how you would go about solving the problem, or just ask if they want a deeper explanation.
The big secret of tech interviews I found was that if the interviewer should actually be on your side. From their perspective, the point is to fill the vacancy as soon as feasible and if you can’t cut it, they will have to sit in the same chair yet again. If you are not sure what kind of answer they need, like “Should I cover everything like I’m explaining it to a new user”, you can just go and ask them, they should be happy to help. To me, it would even present professionalism, that you are trying to tailor your response to your audience.
Of course, there are always going to be weirdos who when they get the thinnest veneer of power, will either mess with you for the sake of it, or “show off their 1337 h4x0r skillz”, but my advice to that is that just stay unfazed, and do your best.
And all in all, it’s going to be a numbers game, in every interview round. Rejections don’t mean shit when HR departments insist on collecting hundreds of CVs before calling in and hiring the person who applied first anyway. Even if you get in, and don’t get selected, it doesn’t even mean that the other candidates were better, it’s just someone jumped the bar earlier. Keep trying and good luck! BTW feel free to bother me with stuff relating to this, I’m happy to answer if I can.
Thank you for that write-up! Understanding Linux more deeply isn’t a barrier to me. I’m now quite certain DBA is my next goal - it really does sound like an evolution of what I’ve been doing so far. I’ll look around on Coursera for some certs that might convince my current employer I’m serious about helping manage the database.
Also, since it was offered I’ll take it as a bit of practice:
Question mark against things that seem like possible causes, but I’m not sure if they are. Most of these would probably show the space as used rather than free, but did I miss checking anything major that I wouldn’t find with a bit of searching?
You are bringing up good approaches and you would have been hired if you could explain how you would start to troubleshoot some of those issues.
The answer to the problem that this team ran into was that you can actually run out of inodes in a filesystem if you have a very large number of relatively small files, and that might show up as failed writes that can make a program like a DBMS say “the disk is full”.
Regarding getting hired though, I have no idea about the market and pay nowadays especially wherever you are. I hope it’s good for you, it was certainly good for me in the 2010s in Eastern Europe, but I’ve heard it’s shit everywhere these days.
Thank you! One more question: “explain” has always tripped me up. How much detail is necessary, vs too much, for a technical interview? Because in my mind “fsck” is self-explanatory, as would be “check the inode count”. Should I cover everything like I’m explaining it to a new user, or is there a baseline skill level I’m expected to address?
Usually what I would do is start with a baseline summary, and then either dive into a step-by-step on how you would go about solving the problem, or just ask if they want a deeper explanation.
The big secret of tech interviews I found was that if the interviewer should actually be on your side. From their perspective, the point is to fill the vacancy as soon as feasible and if you can’t cut it, they will have to sit in the same chair yet again. If you are not sure what kind of answer they need, like “Should I cover everything like I’m explaining it to a new user”, you can just go and ask them, they should be happy to help. To me, it would even present professionalism, that you are trying to tailor your response to your audience.
Of course, there are always going to be weirdos who when they get the thinnest veneer of power, will either mess with you for the sake of it, or “show off their 1337 h4x0r skillz”, but my advice to that is that just stay unfazed, and do your best.
And all in all, it’s going to be a numbers game, in every interview round. Rejections don’t mean shit when HR departments insist on collecting hundreds of CVs before calling in and hiring the person who applied first anyway. Even if you get in, and don’t get selected, it doesn’t even mean that the other candidates were better, it’s just someone jumped the bar earlier. Keep trying and good luck! BTW feel free to bother me with stuff relating to this, I’m happy to answer if I can.