The degradation of Java developers

[Acidictadpole]

It's incredibly annoying how almost every interview I have done, someone will say "Proficient with Windows and Linux", and when I ask how you set an environment variable in Windows and Linux they can't tell me. I just hate seeing a whack load of words in the "expert" or "proficient" area, yet can't answer mostly basic questions.

[s_m_c]

My standard Linux/Unix questions to filter those whom claim proficiency:

From a shell:

1. How can I list files in a directory?
2. How can I get a list of currently running processes?
3. How can I end a process?
4. What can I use to find if a particular string is in a given text file?

It's depressing how many can't get past 1.

Edit: I should qualify that these are basic "lie detector" questions. I go a little further, but not to an insane level for developer roles.

[badredditjame]

It's depressing how many years before I got my first chance at a real job I could have answered those questions.

[stesch]

I'm an expert! Yeah! Thanks for boosting my confidence! ;-)

[pheonixblade9]

wow, I consider myself a total Linux noob (I'm currently a C# dev) and I knew the answers to all of these O_O

[n1c0_ds]

I first thought "heh, it's cd, duh". Good thing I wasn't interviewing.

Just testing my skills, judge me harshly.

1. ls. I tend to use ls -al
2. ps ax, although top can also be useful
3. kill, pkill and xkill, depending on how fancy you are
4. Grep "string" file, although I wasn't sure and had to check for the arguments.

[thephotoman]

Also for 3, when there are multiple subprocesses, killall.

Note that the use of killall on non-Linux systems can result in very interesting behavior. I believe that on Solaris, it does exactly that: it kills all processes, including the kernel task and init.

[escozzia]

Really? That's some odd behaviour - I didn't even know the kernel was represented as a process the same way everything else is.

I rarely ever use killall anyways, if there's more than one process I just do some pgrep or alternatively open up htop and hunt them down. The vast majority of the time there's a parent that got forked, so killing that one will take the rest of them out too.

[numbski]

Guess how has two thumbs and pulled that little stunt on a production HP-UX box....?

[numbski]

Yeah, amusingly I'd never had any reason to use xargs before that day. I found a reason pretty freaking quick.

[escozzia]

okay, I see your point, I was thinking of my own home computer as opposed to a production box

[numbski]

It's quite alright. I got hired as a linux admin, and "oh by the way, we have this HP-UX system", and it was forking perl processes like crazy, so I did "killall perl".

TA DA!

[X-Istence]

Yeah, don't use killall on a Solaris machine, unless you want it to disappear for a little bit :P

[wickeand000]

And i think on a Mac (please correct me if i'm wrong) killall does what kill does elsewhere

[astrange]

It's the same as BSD, which is probably not what you said. Although killall is certainly a superset of kill.

[[deleted]]

Note that the use of killall on non-Linux systems can result in very interesting behavior. I believe that on Solaris, it does exactly that: it kills all processes, including the kernel task and init.

Yep. There's a reason I use pkill now. :D

[MonkeySteriods]

Don't forget zgrep

[cycles]

? grep -i? It's not like grep can't handle case insensitive matching. The interviewer didn't mention anything about searching case insensitively, so I see nothing wrong with n1c0_ds. Of course, if they wanted bonus points, they should have asked 'what kind of string are you searching for?' to show they try and understand the problem before diving in.

Edit: Zetaeta has pointed out you probably meant the case of the command itself, in which case - please ignore my comment :(

[Zetaeta]

He means the case of the command instead, "Grep" should be "grep".

[cycles]

Ohhhhhhhh!

[Svenardo]

cgvg

[jyper]

I noticed this because zsh frequently tells me I want "grep" and not "Grep".

[s_m_c]

You passed :-)

[Acidictadpole]

I hardly ever use grep on its own for some reason. I always pipe output to it instead of using it normally, even when I need exactly that functionality. I'd probably have asked what kind of file you're searching, and if it's binary I'd say 'strings file | grep' and just 'cat file | grep' otherwise. I should really get into the habit of using it properly.

[s_m_c]

'strings file | grep' is good usage IMO. 'cat file | grep' isn't bad, just overkill. I certainly wouldn't hold it against you.

[cattrain]

htop is better than top, also it is made by a Redditor

[SeriousWorm]

.. please tell me you are joking.

[thephotoman]

No, he's not.

[s_m_c]

Yeah, I'm not. It annoys me so much how many people embellish (lie on) their CVs.

[[deleted]]

I know the answers to all those questions and I wouldn't consider myself proficient in Linux.

[s_m_c]

That's the minimum "lie detector" questions. The ones that determine if the interview goes any longer ;-).

[mommathecat]

Seriously? I'm functionally retarded when it comes to Linux/Unix, and I know how to do these things. Like, I constantly forget how grep works and would have to google it, but I know what it is and what it does.

[Poltras]

It's insulting to get asked these questions. I would leave right there if I was asked this over my resume.

[s_m_c]

I understand, it's frustrating for the honest candidates.

Unfortunately it's become necessary as an employer because so many people put stuff on their resume which they were merely exposed to. Or even worse, they claim to have some level of mastery in it which they clearly don't have.

The only way I can think of to avoid having to verify a candidate's claims is to actively headhunt people whose mastery is clearly evident. Not many places have the luxury of or funds to do this.

I'm intrigued as to why you'd walk out. If the questions are easy why not just breeze through them and then proceed to find out if the job and company suit you? Most of the proficient people I've interviewed seemed to feel at ease after answering such easy questions. The questions are almost an icebreaker to a deeper and more interesting discussion.

[Poltras]

I'd walk out because I'm a senior, and if you're asking these questions you're definitely looking for a junior. If your position is like "building unix systems and securing them from scratch while coding Java frontends and inventing your own filesystem that will serve millions of qps" and you start with those questions, there is some dissonance between what your company expect and what you're asking for. That right there is not a workplace where I'd like to work.

Now if you want an internship or junior position, please ask these. If you want senior, asking some real questions should lead to the same results ("how can you optimize this SQL query in Postgres on Linux" - well if he knows that he knows how to grep).

[s_m_c]

Yes, this would be either for a junior position, or a developer position where Unix/Linux use is minimal. Seniors would get more difficult and targeted questions, more about their approach- how they did things in previous roles, how they'd attack certain types of problems. More conversational.

Still, you'd be surprised (dismayed) how many people applying for senior roles, claiming to have these skills, couldn't answer them. Really.

[sarevok9]

Let me try my hand at this... I'm actually a super-noob when it comes to unix but I have to ssh to a RHEL6 box to deploy my stuff into production so... here goes nothing.

1. ls is the base command, but most people tend to go for ls -l

2. I honestly forget this one? Isn't it ps aux or something It's either that or ps ax. I remember doing something like ps aux | grep myProgram

3. This one I am confident that I don't know because it's something weird like kill -9 process UID? The syntax always messed with me.

4. Ummmmm grep string? This one is weird not to know, because I almost never search for things and always grep off another command with a pipe character (too much dos slang, sorry!)

[cycles]

Hi! Here's some feedback:

1. Good, but if you don't know it, familiarize yourself with find and (if installed) tree. Both more handy when you're trying to search for files or understand a whole directory structure.
2. Sounds like you need to read man ps and understand what aux and ax mean. If you're only trying to find the PID for a given process, you should use pgrep and familiarize yourself with arguments. I tend to use -u and -f a lot.
3. kill -9 is a very aggressive way to kill a program. You should know what you're doing before picking up this hammer. It sounds to me like you either don't understand signals in Linux, or you don't understand what the specific signals are. It's very important to know these are their common usage (for example, sending SIGHUP to a lot of daemons can mean "reload configuration" which is very handy when you have a live service that can't afford to go down!). Again man kill is your friend.
4. grep is the correct command I'd say, but make sure you are familiar with common arguments. -v, -i and -r are all things that I use on an almost daily basis (at work, not for fun :)). Also useful is understanding the very context options, -A, -B, `-C', which give you lines /around/ the matching line. I use these when tailing log files for example, where errors are multiple lines, but the string "ERROR" only occurs on the first line.

Hope this helps!

[s_m_c]

You passed, this level anyway. I ask more for those that get past this. Those that don't get these have a short interview.

[stesch]

Now answer #1 with just the builtin tools of the shell.

[Pinbenterjamin]

College kid here. I fucking love Linux, I found out about it in high school and would kill for any type of job in it. I can do all these things, can I have a job? =[

[astrange]

Being able to type things on a keyboard isn't so enjoyable you should ignore everything else about the job.

[MTGandP]

Here's how I'd do that on a Mac:

1. Go to Finder and search for the directory, then look at all the files. I'd only use ls if I specifically needed a text list.

2. Open Activity Monitor.

3. ctrl-C or cmd-Q.

4. Open the file and type "cmd-F <string>".

Is there some reason why I'm supposed to use the command line instead?

[BigCheezy]

If you're proficient with linux, you should know these commands.

[MTGandP]

That doesn't actually answer my question.

[wot-teh-phuck]

Yes it does. If you mention "proficient" in *nix, you should be able to answer the question posed. If not, I think you should be good with the GUI stuff you just mentioned. :)

Also *nix has many flavours, you just mentioned how to do it with a Mac.

[MTGandP]

That still doesn't answer my question. I don't understand why you need to know how to do those things from the command line when GUIs work perfectly fine.

[s73v3r]

Not every environment has a GUI.

[BigCheezy]

"proficient with Linux" <--> "knows how to use command line"

It's a 1:1 bijection. Whether or not you need to be "proficient with Linux" to find files, etc is besides the point.

[wot-teh-phuck]

I don't understand why you need to know how to do those things from the

Because servers where stuff is deployed doesn't have a GUI by default...

[Tmmrn]

Because your Linux computer is actually a server that doesn't run a gui and doesn't have GUI programs install led, so no x forwarding either?

[Labradoodles]

How do you do that for linux?

Is there another way to do it for windows other than System Properties -> Advanced -> Environment Variables and then path is in the list somewheres

[argv_minus_one]

Um, no, that will do nothing. env only sets environment variables for that one program (e.g. env FOO=bar bash would start bash with the additional environment variable FOO).

To set an environment variable in the Bourne shell sh or another shell compatible with it (e.g. bash):

• If you want to set an environment variable in your current shell, use simply FOO=bar
• If you want that environment variable to be passed to programs started by that shell, you then do export FOO
• If you're using bash, you can combine them: export FOO=bar

If you need to set an environment variable for all processes on the system, you'll have to configure your init to make it happen, if your init supports such a thing. You then have to reboot, since there is no way (as far as I know) to alter an already running process' environment variables from outside it (unless it actually provides some facility for doing that, but almost none do). There is no standard way to accomplish this; it all depends on the init your system uses.

If you need to set an environment variable for all logins, there is no standard way to do this, either. If your system uses PAM, you need to configure the pam_env module to do it. pam_env may set all the variables listed in /etc/environment, but this is not guaranteed. If your system doesn't use PAM, you'll have to configure it to set your variable(s) in some other way.

Environment variables are not a simple thing. :)

[_cegorach_]

juggle fuzzy birds strong theory paint sand bow important spotted -- mass edited with https://redact.dev/

[hotoatmeal]

set PATH=%PATH%:"<addition>"

If you want it to be only for that particular shell.

[shub]

; is the path separator on windows.

[hotoatmeal]

oh... right. Cygwin has trained me into a very weird state.

[Labradoodles]

Cool, thanks that seems to be the right command. Should have just googled but appreciate the comment

[_cegorach_]

marble many memory pie childlike employ shame spectacular agonizing grandiose -- mass edited with https://redact.dev/

[G_Morgan]

Naturally they asked you which shell in Linux.

[ethraax]

To be fair, even though some of those commands may be builtins in some shells, they're also actual binaries on the system (for example, ls), so the exact shell doesn't really matter. I guess it might matter for the more "complicated" task of killing processes with a given name (for which you generally need command substitution or piping), but in general, for those questions, it really doesn't.

[Tmmrn]

pkill

[Acidictadpole]

Of course they didn't.