To be honest i am always having mixed feelings when i read a thread like this: threadstarter wants to get a better job - so far so ok with me - but seeks help to appear someone else than he really is.

Save for the fact that i have a moral problem with deceit, i have been two times been in a position where i had to work with people who where successful in what threadstarter is attempting. Both occasions are not part the memories i am particularly fond of. Having to explain to a supposed fellow senior SysAdmin how to add a line in vi is nothing you want to do if the task is "set up a new NIM server". You instantly know that you are completely on your own. Call me vindictive, i let the management know in no unclear terms about this colleagues competences.

Having said this, here is my advice to NycUnxer:

- don't try to look better in the interview than you really are. Even if you are successful and get away with it it will, more sooner than later, come out anyways. Do you really want to explain that to your colleagues? Do you want your new colleagues share your part of the load because you are not qualified to do it yourself? You are, what you are and if they don't like it - their bad.

There will be jobs where you will be accepted as a newcomer and this will be taken into consideration when handing out the tasks. You can gain experience there and an then move to a better job when you have the credentials to fill it.

- Unix is, for one part, things you can learn: commands, facilities, structures, ... Unix is, for an even greater part, experience: you have to have worked with the tools over a longer time to really appreciate them and understand their inner harmony to the full. Experience is something you cannot emulate - even less so than knowledge. Real-Life-problems are not simple tasks like in textbooks. RL-problems are complex, interdependent tasks where every decision affects a lot of - sometimes only remotely connected - other things. Being aware of these interdependencies is part of this experience. You don't get this out of any book, you have to be exposed to the jobs tasks to build it.

You have to have attempted to write a 2000-line-shellscript and you have to have failed miserably in the last part of it to appreciate things like encapsulation, variable declaration, strict typing, naming conventions, etc. In a textbook you might find all these things explained along with a 5-line-example. On this the procedure looks usually superficial and finical. You will now "know" something, but you will not "feel" it. Again, write some 100k+-scripts and you will get the feeling pretty fast. This is experience.

Bottom line: if you are looking for some test questions like

Q: how to increase a filesystem?
A: use the "chfs -a size=+ ..." command

then you are wrong already. Not, because the answer is wrong, but because the question is wrong.

I hope this helps.

bakunin