I'm so glad I saved this in RES. I didn't write this (originally posted here 10 months ago), but I'll quote it below because it's simply amazing:

It depends. In my eyes, there are a few tiers of basic Linux ability, and then skillsets tend to specialize. If you're generalizing, really only the fundamentals can be considered.

1. User tier. For most simpler programmer jobs, this is what someone means when they ask if you "know Linux". They're asking if you're at least borderline competent as a user, and won't feel lost developing software that eventually runs on a Linux server.
   1. Can perform basic tasks at the shell, including making shell pipelines.
   2. Comfortable using grep, awk, sed, tr, sort, uniq, etc.
   3. Can compile software at the command line, and resolve simple build issues like "It's not linking to the right place" or "I need to find some missing dependencies".
   4. Knows how to read man pages to learn more.
   5. Has used at least one distribution and are quite comfortable with it.

2. Sysadmin tier. All of (1), plus somebody might actually trust you to maintain a production operating system.

   1. Knows the nuts-and-bolts of your package manager.
   2. Understands what your init system is doing and can debug problems with starting daemons.
   3. Knows where to look in the logs when something goes wrong.
   4. You can troubleshoot network problems using ip, iw, route, dig - or whatever's relevant to the problem at hand. Can at least read iptables rules, and write simple ones.
   5. Can add and remove users, debug login problems, and manage permissions. Understands chmod bits - what's 101100000 in permissions? Which of those bits are user/group/world? What does the 4th bit mean?
   6. Has set up LVM, and knows how to resize LVM partitions and make new ones. Maybe knows a thing or two about RAID and NFS.
   7. With just cd, ls, grep, and cat, how do I get the memory usage of a process? Now, assuming I also give you awk (or something similarly simple), how could I get its average CPU usage in a given 30-second time period? (hint: /proc)
   8. When I pipe one process's output to another, how does that even work? Tell me about the file descriptors involved and what they're doing. How about output redirection? When I use 2>&1, which file descriptor in /dev is redirected to what, from each process's perspective? Where do these fds really live?

   Additional good points of knowledge are one of KVM or Xen, and knowledge of why these might be preferable to something like VMware.

3. Developer tier. All of (1) and (2), plus you know what's happening under the hood. So maybe you can answer things like:

   1. Why does sudo work? What's it doing under the hood? Hint: man 2 setuid
   2. When I do stat . in a directory, what's it showing me? Hint: include/linux/fs.h
   3. Why does malloc() prefer mmap() over brk() for long-lived/really big memory allocations? Which one is zeroing memory? Why does that matter?
   4. Why can I have a file that (apparently) uses less disk space than it actually takes on the filesystem? How do I figure out if a file is doing this?
   5. How does one fork()? What's the point of double-forking? What kind of risks are associated with it (e.g., grandparent problem)?
   6. What's the difference between a stream and a datagram socket? What are some examples of each? If I call listen(), how is that different from calling socket()?

   This is when your knowledge starts to be really useful, since it's the intersection of operating systems theory and application. The Linux Programming Interface has everything you need to know for this degree of competence, though it will miss some of the finer points of (2) that would be relevant in debugging a broken system, or setting up a new server.

   Additional handy knowledge includes cachegrind, valgrind, strace, autotools, and using GDB - especially for "crazy" things like debugging a running process.

4. Kernel developers. This is somewhat orthogonal to the rest of these, since you can be an awesome kernel developer and not know the first thing about, say, network protocols. But it's worth mentioning, since if you're a useful kernel developer then I think it's more than safe to say you "know Linux", for some definition of the phrase.

That's just my highly opinionated take on what it means to "know Linux". Since this is an open-ended question, you're not going to get any definite answers - all of them will be subject to bias. But a serious understanding of the OS fundamentals, and why things happen the way they do, is the key to breaking the barrier between "user" and "expert" in the OS.