5 ms·

According to `man ps` on my Mac, there are nearly seventy of them - how many did he want you to know?!

wpietri 10y ago
It's been a long time since I interviewed an ops person. But when I did something like this, I'd ask, "Name as many arguments to ps as you can." (Or ls, also good.) I didn't really care about which flags they knew. What I was looking for was a pattern. Anybody good knows some arguments cold. Often they know them so well as part of a phrase that they have to think about what the individual ones mean, which tells me that they've done something enough that it's become a habit. Then they'll know a few others that they use occasionally. And then they'll stretch to name a few more that are obscure for them. But the real magic comes when they run out. What do they do then? Good people say that they don't know. Often, they will take guesses at a few more based on general principles. E.g., "I'm sure there are arguments for sorting, but I only use top for that." Or, "There must be more ways to filter, but I only do it by user or command." They'll usually look a bit uncomfortable, because they are the sort of person who likes knowing things. But what they won't do is bluff or make things up. And honestly, that's my biggest tip for hiring: find people who like understanding things and know a good amount for their level, but are willing to say when they don't know. People who can't do that are dangerous.
- employee8000 10y ago
  This is a stupid trivia question. I use ps -ef and leave it at that. In my entire career I've rarely needed anything else and if I did I would look it up but never enough to remember. To base an interview question off of that speaks volumes about you.
  - mjevans 10y ago
    I agree, and it's interesting that you know -e, while I've memorized -axuf ; I guess it's more portable? Again, this is one of those, "Here's what I've got cached, and here's where I'd look up what I don't know offhand" questions.
    - jwilk 10y ago
      No, "-axuf" is a weird mixture of BSD and POSIX syntax. From the ps manpage: Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning. This behavior is intended to aid in transitioning old scripts and habits. It is fragile, subject to change, and thus should not be relied upon.
  - wpietri 10y ago
    Well, yes and no. If somebody just scored it as written, giving points for each argument known, it would be a dumb trivia question. But as I said, that's not what I do. Try it next time you're mingling with ops people. Say in a bar at a conference. Don't look at what they answer. Look at how they answer. Some people are comfortable not knowing. Some people are excited to discover the ones they forgot they knew. some people get curious and eager to fill the hole they've just noticed in their knowledge. And some people get defensive and peevish.
    - a-priori 10y ago
      Some people focus their curiosity on more important things than arguments for a command line utility.
- tptacek 10y ago
  I feel pretty comfortable with my Unix abilities, and have held ops roles in the past, and I would have bombed this question.
  - wpietri 10y ago
    I doubt that. The only way to bomb it is to make shit up, and I don't think you're the sort to do that. I don't score it by how many option-letters people know. I score it by how well they demonstrate familiarity with a basic ops activity, which is finding out what's running. Even if somebody said they never used ps, or like below, only use one incantation, that isn't a problem, because my follow-up there would be to ask how you'd find out what's using all the RAM or what's using a lot of CPU. Maybe they're just used to using different tools, in which case I can ask for details for those tools. (And then check manually later to make sure I'm not getting snowed.) But if they've done a bunch of ops stuff, they'll demonstrate the sort of know-from-doing level of familiarity with something. In theory I could just ask the broader question to start. But some people are good talkers, and I'm looking for evidence that people are good doers. All that said, I've shifted mainly to more experiential interview processes, as actually doing is the best way to see if somebody's a doer.
- kafkaesq 10y ago
  They'll usually look a bit uncomfortable, because they are the sort of person who likes knowing things. So the process is, in fact, designed to make people feel uncomfortable, for a little bit (or at least you're definitely aware that this is a frequently occurring side effect). Does that not suggest to you that there may be a negative tradeoff at play here? (To wit: yes you do manage do efficiently extract a few bits of information from them... but at cost of having them feel like they're being, well... interrogated. And are already "losing points" by that point in the conversation with you).
  - nostrademons 10y ago
    I think part of the point may be to select for people who don't consider "being interrogated" to be a contest. There are plenty of folks who are just like "Here's what I know, here's what I don't know, you decide whether you would want me on your team. If you don't, that's fine, I'll find another team to join." Then there are other folks who, when they're asked a question and don't know the answer, feel like their self-worth is under attack. The latter group can be really hard to work with, and can do a lot of damage to a team. I had a PM friend who would try to push the bounds of a candidate's knowledge until they gave up and said "I don't know". The actual knowledge wasn't the point of the question: it was that they could say "I don't know", because PMs who can't tend to make life miserable for the engineers & other teammates who work with them.
    - wpietri 10y ago
      Yes, exactly. I think to be a good developer, you have to be willing to keep learning. And to be a good developer in a team context, you have to be willing to learn from your teammates, ask for help, and share knowledge in a way that's supportive, not prideful. And I agree with your PM friend; I think willingness to admit ignorance is even more valuable there.
  - wpietri 10y ago
    If somebody goes into an interview expecting never to be asked a question they might struggle with, I'm not sure they're somebody I want to hire. But no, I don't think they walk away feeling interrogated. My style is pretty conversational, and when people don't have all the answers, I definitely work to make them feel comfortable with that. E.g., for this question I'd close with something like, "Of course nobody knows all the arguments to ls. I sure don't. So you did fine."
- sjg007 10y ago
  dangerous because they prefix things with sudo?
  - wpietri 10y ago
    I imagine there's a correlation there. But for me it's the danger that instead of admitting when they don't know they'll just bluff, going off and building things that look good but aren't. If somebody knows their limits and can admit them, you have to supervise them much less closely than a bluffer.
- kasey_junk 10y ago
  I would almost assuredly stop the interview at this point and try to figure out what your malfunction is. To me any question where the obvious answer is "I can trivially look all that up in the man pages" is a gigantic red flag that I don't want to work at that place. If I'm feeling curious that day, I might begin a conversation about what you think you are testing for with that question, as I've spent a fair bit of my career studying hiring pipelines. But if I hadn't had my coffee yet or were irritated or something I'd probably just ask to talk to someone else.
  - wpietri 10y ago
    That's fine. If you go into something assuming that anything you don't understand is a malfunction, and you excuse your rude behavior with your mood and/or caffeine level, you're probably not the kind of person I'd want to spend a lot of time working with. That said, as I've explained elsewhere in the thread, the point isn't to see how many they know. It's to see that a) they know some portion of it that people doing the work would know, and b) have reactions to the rest that indicate useful work habits and attitudes. A perfectly find first answer to is "I only use ps -aux. I'd just look in the man page if I needed anything else." Because then we could have a good discussion of how they use that output to figure out things, what sort of things they'd expect to see in the man page, and what other tools they use to see what's going on.
    - tptacek 10y ago
      I'm pretty confident both of you are people I'd be happy to work with in the future and so I want to use this as an opportunity to point out that your reaction to what Kasey said his reaction would have been to your interview question practically guarantees that you would fail to acquire Kasey for your team. I know Kasey a little bit better than I know you (he's a Chicago person) so I'll just sum this up as "that's not a point in the win column for this interviewing strategy". I know you're not asking people recite "ps" flags from memory. The problem is, you're looking for a subjective "X-factor" in how someone answers a trivia question. I used to really like this approach too. I'd think of things that you'd only know if you'd actually done the kind of work I'd done. I had some favorite interview questions: "what are some of the functions you carry around with you from project to project in your 'libyou.a' library", and "where would you start looking if you had to debug a program that segfaulted in malloc"? I think the logic I was using is the same as the logic you're using here. Ultimately, I think it's a bad approach. Equivalently strong candidates look at their work through different lenses, and find different things memorable. Far more important to me, though, is that some people really suck at interviewing --- and, what motivates me more, having succumbed to this repeatedly as a hiring manager and also being myself I think an example of the phenomenon --- some people just interview way better than they should.
- cr0sh 10y ago
  I'd probably be snarky and say "I don't know - but I can google it!" /actually I'd probably hit up the man page first...
tutufan 10y ago
He probably had at least five or ten in mind. I prefer other methods of extracting this information. Usually 'ps -efly' piped into tools like awk/etc to gather what I want, or on occasion, extracting directly from the /proc filesystem. He did not consider these to be proper alternatives. Since the 'ps -o' flags are only useful in that one command, I just look them up in the (rare) situation where they seem the best alternative. Having been at this for decades, I try to reserve my limited memory capacity for factoids that will pay off, and being able to process columnar data generically at an instant seems more useful than knowing a special way to do it with that one command.

It's been a long time since I interviewed an ops person. But when I did something like this, I'd ask, "Name as many arguments to ps as you can." (Or ls, also good.) I didn't really care about which flags they knew. What I was looking for was a pattern. Anybody good knows some arguments cold. Often they know them so well as part of a phrase that they have to think about what the individual ones mean, which tells me that they've done something enough that it's become a habit. Then they'll know a few others that they use occasionally. And then they'll stretch to name a few more that are obscure for them. But the real magic comes when they run out. What do they do then? Good people say that they don't know. Often, they will take guesses at a few more based on general principles. E.g., "I'm sure there are arguments for sorting, but I only use top for that." Or, "There must be more ways to filter, but I only do it by user or command." They'll usually look a bit uncomfortable, because they are the sort of person who likes knowing things. But what they won't do is bluff or make things up. And honestly, that's my biggest tip for hiring: find people who like understanding things and know a good amount for their level, but are willing to say when they don't know. People who can't do that are dangerous.

employee8000 10y ago
This is a stupid trivia question. I use ps -ef and leave it at that. In my entire career I've rarely needed anything else and if I did I would look it up but never enough to remember. To base an interview question off of that speaks volumes about you.
- mjevans 10y ago
  I agree, and it's interesting that you know -e, while I've memorized -axuf ; I guess it's more portable? Again, this is one of those, "Here's what I've got cached, and here's where I'd look up what I don't know offhand" questions.
  - jwilk 10y ago
    No, "-axuf" is a weird mixture of BSD and POSIX syntax. From the ps manpage: Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning. This behavior is intended to aid in transitioning old scripts and habits. It is fragile, subject to change, and thus should not be relied upon.
- wpietri 10y ago
  Well, yes and no. If somebody just scored it as written, giving points for each argument known, it would be a dumb trivia question. But as I said, that's not what I do. Try it next time you're mingling with ops people. Say in a bar at a conference. Don't look at what they answer. Look at how they answer. Some people are comfortable not knowing. Some people are excited to discover the ones they forgot they knew. some people get curious and eager to fill the hole they've just noticed in their knowledge. And some people get defensive and peevish.
  - a-priori 10y ago
    Some people focus their curiosity on more important things than arguments for a command line utility.
tptacek 10y ago
I feel pretty comfortable with my Unix abilities, and have held ops roles in the past, and I would have bombed this question.
- wpietri 10y ago
  I doubt that. The only way to bomb it is to make shit up, and I don't think you're the sort to do that. I don't score it by how many option-letters people know. I score it by how well they demonstrate familiarity with a basic ops activity, which is finding out what's running. Even if somebody said they never used ps, or like below, only use one incantation, that isn't a problem, because my follow-up there would be to ask how you'd find out what's using all the RAM or what's using a lot of CPU. Maybe they're just used to using different tools, in which case I can ask for details for those tools. (And then check manually later to make sure I'm not getting snowed.) But if they've done a bunch of ops stuff, they'll demonstrate the sort of know-from-doing level of familiarity with something. In theory I could just ask the broader question to start. But some people are good talkers, and I'm looking for evidence that people are good doers. All that said, I've shifted mainly to more experiential interview processes, as actually doing is the best way to see if somebody's a doer.
kafkaesq 10y ago
They'll usually look a bit uncomfortable, because they are the sort of person who likes knowing things. So the process is, in fact, designed to make people feel uncomfortable, for a little bit (or at least you're definitely aware that this is a frequently occurring side effect). Does that not suggest to you that there may be a negative tradeoff at play here? (To wit: yes you do manage do efficiently extract a few bits of information from them... but at cost of having them feel like they're being, well... interrogated. And are already "losing points" by that point in the conversation with you).
- nostrademons 10y ago
  I think part of the point may be to select for people who don't consider "being interrogated" to be a contest. There are plenty of folks who are just like "Here's what I know, here's what I don't know, you decide whether you would want me on your team. If you don't, that's fine, I'll find another team to join." Then there are other folks who, when they're asked a question and don't know the answer, feel like their self-worth is under attack. The latter group can be really hard to work with, and can do a lot of damage to a team. I had a PM friend who would try to push the bounds of a candidate's knowledge until they gave up and said "I don't know". The actual knowledge wasn't the point of the question: it was that they could say "I don't know", because PMs who can't tend to make life miserable for the engineers & other teammates who work with them.
  - wpietri 10y ago
    Yes, exactly. I think to be a good developer, you have to be willing to keep learning. And to be a good developer in a team context, you have to be willing to learn from your teammates, ask for help, and share knowledge in a way that's supportive, not prideful. And I agree with your PM friend; I think willingness to admit ignorance is even more valuable there.
- wpietri 10y ago
  If somebody goes into an interview expecting never to be asked a question they might struggle with, I'm not sure they're somebody I want to hire. But no, I don't think they walk away feeling interrogated. My style is pretty conversational, and when people don't have all the answers, I definitely work to make them feel comfortable with that. E.g., for this question I'd close with something like, "Of course nobody knows all the arguments to ls. I sure don't. So you did fine."
sjg007 10y ago
dangerous because they prefix things with sudo?
- wpietri 10y ago
  I imagine there's a correlation there. But for me it's the danger that instead of admitting when they don't know they'll just bluff, going off and building things that look good but aren't. If somebody knows their limits and can admit them, you have to supervise them much less closely than a bluffer.
kasey_junk 10y ago
I would almost assuredly stop the interview at this point and try to figure out what your malfunction is. To me any question where the obvious answer is "I can trivially look all that up in the man pages" is a gigantic red flag that I don't want to work at that place. If I'm feeling curious that day, I might begin a conversation about what you think you are testing for with that question, as I've spent a fair bit of my career studying hiring pipelines. But if I hadn't had my coffee yet or were irritated or something I'd probably just ask to talk to someone else.
- wpietri 10y ago
  That's fine. If you go into something assuming that anything you don't understand is a malfunction, and you excuse your rude behavior with your mood and/or caffeine level, you're probably not the kind of person I'd want to spend a lot of time working with. That said, as I've explained elsewhere in the thread, the point isn't to see how many they know. It's to see that a) they know some portion of it that people doing the work would know, and b) have reactions to the rest that indicate useful work habits and attitudes. A perfectly find first answer to is "I only use ps -aux. I'd just look in the man page if I needed anything else." Because then we could have a good discussion of how they use that output to figure out things, what sort of things they'd expect to see in the man page, and what other tools they use to see what's going on.
  - tptacek 10y ago
    I'm pretty confident both of you are people I'd be happy to work with in the future and so I want to use this as an opportunity to point out that your reaction to what Kasey said his reaction would have been to your interview question practically guarantees that you would fail to acquire Kasey for your team. I know Kasey a little bit better than I know you (he's a Chicago person) so I'll just sum this up as "that's not a point in the win column for this interviewing strategy". I know you're not asking people recite "ps" flags from memory. The problem is, you're looking for a subjective "X-factor" in how someone answers a trivia question. I used to really like this approach too. I'd think of things that you'd only know if you'd actually done the kind of work I'd done. I had some favorite interview questions: "what are some of the functions you carry around with you from project to project in your 'libyou.a' library", and "where would you start looking if you had to debug a program that segfaulted in malloc"? I think the logic I was using is the same as the logic you're using here. Ultimately, I think it's a bad approach. Equivalently strong candidates look at their work through different lenses, and find different things memorable. Far more important to me, though, is that some people really suck at interviewing --- and, what motivates me more, having succumbed to this repeatedly as a hiring manager and also being myself I think an example of the phenomenon --- some people just interview way better than they should.
cr0sh 10y ago
I'd probably be snarky and say "I don't know - but I can google it!" /actually I'd probably hit up the man page first...

tutufan 10y ago

He probably had at least five or ten in mind. I prefer other methods of extracting this information. Usually 'ps -efly' piped into tools like awk/etc to gather what I want, or on occasion, extracting directly from the /proc filesystem. He did not consider these to be proper alternatives. Since the 'ps -o' flags are only useful in that one command, I just look them up in the (rare) situation where they seem the best alternative. Having been at this for decades, I try to reserve my limited memory capacity for factoids that will pay off, and being able to process columnar data generically at an instant seems more useful than knowing a special way to do it with that one command.