Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
There is less than 24 hours left to vote in the 2015 LinuxQuestions.org Members Choice Awards. Click here to go to the polls. Vote now and make sure your voice is heard!
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Also, are you looking for user-level, developer, or sysadmin type questions? Linux is a rather big topic.
The best way to "crack" an interview is to know the requirements of the job you're applying for and having actual, demonstrable experience in meeting those requirements. This is what most employers I know are actually looking for. Unfortunately, there are no short cuts to this sort of knowledge; it takes years of study, practice, and professional experience to acquire. Certs help and can certainly open doors that might not necessarily be opened otherwise, but there's no substitute for hard experience (even in a home lab). If you take the short cut and manage to cram using some cheat-sheet and still manage to get hired, chances are your lack of knowledge will show up quickly once you're on the job. You'll probably lose the job very quickly unless you either (a) can learn VERY fast or (b) have an incredibly sympathetic boss.
As an aside, when interviewing for admins I find non-technical "soft" skills to be as important if not more so than technical chops. Admins will need to deal with users, management, vendors, changing technology, etc. in order to keep the operation going. These skills aren't on any certification exam, but they are, IMO, what separates a good-to-great admin from an average one. This was one of the first things I had to wrap my head around when I entered the field around a decade ago.
I guess that I can speak from experience on this one, as someone who has, and does, hire programmers. My short-answer to this one is very short: "don't even try." This isn't school. You're not trying to "ace," nor to "cheat," a test. And to me (your mileage may vary™ ...), your certifications don't mean squat. You're making a sales presentation. And, if you even dare to try to bluff, I can look at your eyes and tell.
But I can also detect honesty. No one knows everything. No one knows one-third of the things they think they know. But, give me someone who will honestly tell me, "I don't know that answer, sir," and I immediately start to build up the impression that: "I can work with this person on my team."
You should carefully familiarize yourself with whatever is spelled-out on the job requisition, which is what (after HR/Legal gives the nod ...) actually winds up on all those job boards. Read this very carefully, so that you get an understanding of what the job is and of what the hiring manager's expectations are likely to be. Do you really think that you are qualified for this position? Even if you're not a 100%-fit, do you think that you're close enough that "you would hire you?" If the answer once again is "yes," then consider where you think your weaknesses are, and how you might go about selling the product (i.e. "you") in full recognition of ... and honest admission of ... where those weaknesses are. (Everyone has weaknesses as well as strengths, relative to any job.)
Try to "bluff" me? Try to "crack it?" You're finished, and you should be. On the other hand, sell me on why it really is a good business decision for me to tell HR to hire you, and we could be at the start of something that will turn out to be really good for both of us.
Tip: Buy or check out a copy of "The Little Red Book On Selling," and read it cover-to-cover. Like programming, selling is an art. (But it's fun, too.) Any and every time you go for an interview, "you're selling." Therefore, "Learn How."
I'd totally agree with sundialsvcs except that I do put some value on certification, it indicates that someone is willing to spend time (and in some cases money) learning about a subject. However I treat it as just that and not a case of "knowing" the skill set. I certainly wouldn't trust some of my own certified skills as I've not used them in years.
As has been previously mentioned the main thing is to actually KNOW your subject, and be prepared to admit your weakness. Having recently interviewed and hired Linux admins and Desktop (Windows) support our standard procedure is a two stage process, a "personality" interview and a mixed "technical" interview. For the technical we have a pool of questions and no, I'm not going to post them and between those two it usually comes clear whether or not someone knows what they are doing or is trying to BS their way in. For example an answer we had for the Windows role was "Is Windows 8 out yet?". For the Linux Admin role (Internet Infrastructure) we've had people unable to explain the basics of ping, traceroute, DNS, "what are the various stages between typing www.mydomain.com in a browser and the page displaying". The occasional "I don't know, but I'd use X/Y/Z to find out" is an acceptable answer, but not for every question
Please suggest me some questions to prepare to crack an interview of Linux
The first one I'd ask would be "Are you able to use search functions on websites?"...because this has been asked (and answered) MANY times before.
An interviewer can ask ANYTHING they want, and accept ANY answer as 'correct'. And instead of wanting to 'crack' and interview, you should be focused on actually having the skills to do the job, rather than trying to 'crack' your way into it. If you don't have the skills, it will be VERY obvious, VERY quickly that you're not qualified...and you will be fired just as quickly.
Yes, schneidz, and I personally think that all three of those questions are bogus. No one would memorize the answers to those questions when in real life they could use man and/or a very quick search to find out.
I taught COBOL for many years, and one thing that I would do on every test is that I'd let the students bring a one-page "cheat sheet" to the test with them. You could fill both sides of an 8-1/2" x 11" sheet of paper with content any way you want, as long as yours was original. One memorable student used a reducing photocopier to put 8 pages of text onto the sheet and brought a magnifying glass with him. (The magnifying glass caught my eye, as did the fact that he never once picked it up during the test and barely glanced at the sheet of paper. He aced it handily.) At the end of the class, I'd explain that this was my all-time favorite study technique, along with trying to anticipate what sort of questions a teacher might ask. (I was usually much harder on myself than she turned out to be.)
Before going for a job, you should know what the on-the-job requirements for the position actually are, only applying for those for which you feel that you might be persuaded to hire yourself if you were the buyer instead of the seller. During the interview, you need to be asking detailed questions about the workgroup you'll be joining, what its responsibilities are, how it organizes itself, and so on. These questions, too, get noticed.
You're not boning-up for a test that you have to pass and that you can then forget about. You're selling your professional services to what you hope will be an engagement lasting several years.
It's a priceless educational experience to actually be a person who is tasked with making such decisions. I hope you get the chance someday.
Yeah, that's kind of vague. The poignant question was whether you're giving an interview or being interviewed; however a good guess given your description of "crack" implies that you wish to do good as an interviewee.
Well ... read the job description. It's either Greek or not to you. If you have a good deal of the skills they're looking for, then submit your name. Odds are since you're talking about an interview already, your name has been submitted. My advice there is don't waste your time on speculation. Why bother attending an interview if you have zero idea what the job is about? Which is to say, if some job recruiter is selling you on a job aggressively and pushing you to interview without the benefit of a job description, or pushing you to interview even if your skills are a poor match; then don't take that treatment from them. Because that's a waste of time.
Bottom line is, if you have to study for an interview; you have no business being in that job. Practicing interview skills is fine; that's all about your presentation capabilities and how you convey your ideas, as well as how good of a listener you are.
If someone's going to ask you technical questions on an interview; then they are. Depends whether or not they're open-minded or if they canned up some questions years ago that they always ask; thinking that it makes a real difference. The smart interviewer will qualify the candidate by asking them first what strengths they have. Like, "Have you compiled programs for Linux before?" If they answer yes, then maybe ask them to describe how they've done that so you can get an idea what experience they have, and then ask an appropriate question within the scope of that task. If a person has no experience close to what you're looking for, then asking them technical questions is a waste of time. You start out by determining if they know about the main subject area and ask them to describe their experience with it. If they poorly understate what they know, that's sort of strike 1, ask them some particulars. If you can't get past that point, both parties have wasted their time.