3 ms·

I sometimes ask candidates to talk about these exact things during interviews. Describe what happens when you type a command into a shell. Then how about if it'

by donio 4y ago

I sometimes ask candidates to talk about these exact things during interviews. Describe what happens when you type a command into a shell. Then how about if it's in an ssh session. It's a good way to dive into all kinds of stuff from syscalls to networking. I look for an overall understanding and curiosity about how stuff works. These are SRE type positions where strong systems knowledge and debugging skills are a requirement or at least a big plus.

TillE 4y ago
Makes sense. It's something where even if you don't know the true details, you can engage in intelligent speculation about how it could be implemented.
jsd1982 4y ago
That's fine to ask but a non-answer gives you almost no information other than perhaps that the candidate never bothered to learn in great detail exactly how it all works because it's never been important enough to spend time on. If you're looking for strong diagnostic skills, then ask those questions geared to give you direct information as opposed to trying to weed it out from the answer to a vague high-level process description question. If the candidate has no idea why you're asking then any answer at all should be satisfactory.
- zamadatix 4y ago
  Weeding out how to approach well when the ask isn't clear or you don't have full understanding of the problem space is a great skill to select for and doesn't require any technical knowledge at all about what the question is asking. A true non-answer (not just a lack of deep technical understanding on what really happens) should hint to further investigate how strong a candidate is in that area not hint they aren't technically savvy.
- theamk 4y ago
  It's hard for me to imagine any strong Unix systems engineer that knows nothing about that topic. The whole tty subsystem is one of the core parts of *nix systems, and basic knowledge of it is required for many complex debugging questions. And the open ended question is great because it allows candidate to showcase what they know. Have no idea how PTYs are allocated by kernel? No problem, you can talk how shells work.
- deleted 4y ago
  [deleted]
Cockbrand 4y ago
While I've been using Unix/Linux shells for seemingly ever, remotely at first with telnet, then with SSH, I have a fairly consumer point of view towards the entire stack: I know their components well enough to be able to use them in my every day work, and to debug them with the few problems I encounter. The nitty-gritty doesn't concern me, and I frankly don't care much. I rather learn other stuff in more depth. That said, I do muchly appreciate that I can afford this point of view, because everything's stable and user friendly enough that I don't have to care. Disclosure: I'm not an SRE
- mixmastamyk 4y ago
  Also as someone who was always multi-platform I didn't know the nitty-gritty until recently myself, and honestly knowing it is just for fun for most folks. TTY/terminal-centric problems just don't happen any longer, and if they did you can boot into recovery mode or "nuke the OS from orbit" with a live drive. Things that do happen with some regularity like disk corruption should probably get focused on first.

by donio 4y ago

TillE 4y ago

Makes sense. It's something where even if you don't know the true details, you can engage in intelligent speculation about how it could be implemented.

jsd1982 4y ago

That's fine to ask but a non-answer gives you almost no information other than perhaps that the candidate never bothered to learn in great detail exactly how it all works because it's never been important enough to spend time on. If you're looking for strong diagnostic skills, then ask those questions geared to give you direct information as opposed to trying to weed it out from the answer to a vague high-level process description question. If the candidate has no idea why you're asking then any answer at all should be satisfactory.

zamadatix 4y ago
Weeding out how to approach well when the ask isn't clear or you don't have full understanding of the problem space is a great skill to select for and doesn't require any technical knowledge at all about what the question is asking. A true non-answer (not just a lack of deep technical understanding on what really happens) should hint to further investigate how strong a candidate is in that area not hint they aren't technically savvy.
theamk 4y ago
It's hard for me to imagine any strong Unix systems engineer that knows nothing about that topic. The whole tty subsystem is one of the core parts of *nix systems, and basic knowledge of it is required for many complex debugging questions. And the open ended question is great because it allows candidate to showcase what they know. Have no idea how PTYs are allocated by kernel? No problem, you can talk how shells work.
deleted 4y ago
[deleted]

Cockbrand 4y ago

While I've been using Unix/Linux shells for seemingly ever, remotely at first with telnet, then with SSH, I have a fairly consumer point of view towards the entire stack: I know their components well enough to be able to use them in my every day work, and to debug them with the few problems I encounter. The nitty-gritty doesn't concern me, and I frankly don't care much. I rather learn other stuff in more depth. That said, I do muchly appreciate that I can afford this point of view, because everything's stable and user friendly enough that I don't have to care. Disclosure: I'm not an SRE

mixmastamyk 4y ago
Also as someone who was always multi-platform I didn't know the nitty-gritty until recently myself, and honestly knowing it is just for fun for most folks. TTY/terminal-centric problems just don't happen any longer, and if they did you can boot into recovery mode or "nuke the OS from orbit" with a live drive. Things that do happen with some regularity like disk corruption should probably get focused on first.