Hi

For Linux interviews are there is there any good sources to study in question-answer format to scenario based questions. Like SSH related, performance related etc.
I am finding it really hard to crack the interviews though i know the concepts.
I would appreciate to know if there are any books or materials that help in preparing from interview standpoint.

Thanks in advance!

Well, here's how I interview people for such positions: most of all, I talk to them and try to get them to talk to me. For instance, I might pick a sanitized and simplified version of an actual problem that the team faced recently, describe it to the candidate, and ask what (s)he would do next. Every now and then I might get a pause and then be told that the candidate really doesn't know. "Okay," I'd say, "let's try something else instead." (Nobody knows everything, hey. Soon enough, I'll hit on a question that the candidate can "run with," and I'll watch to see how they run.)

I like it when candidates ask for clarification, if necessary, and when they offer several alternative possibilities and describe how they might tackle the task of figuring out exactly what the problem is. I'm very happy to offer information – one candidate asked to look at a man page – because in the real world we do have information at our fingertips. Do they seem to understand the scenario? Do they speak of asking others on the team to help them understand and to resolve the problem? Do they seem to be generally familiar with what I'm talking about? Do they by their demeanor seem to be the sort of person who would easily and productively fit into a team that is tasked with these responsibilities?

I will never try to "stump the candidate," and I'll quickly offer information if the candidate seems to be drawing a blank. I'm not so much trying to plumb the scope of the candidate's built-in knowledge bank, but to see what they do with it.

1 members found this post helpful.

I like the goal, but the answer may be: every bit of detail that any interviewer knows, which is basically infinite!!!
(Web-search will find a few hundred links: linux intitle:interview questions answers) Non-Specifically-Linux too.
But fortunately there is a solution: experience, which can be acquired by doing/trying things, many things, covering the areas of expertiese needed/desired by the employer with whom you will interview.

Expand beyond cert objectives, to fully understand how&why it works; think about (&experiment with) things that could go wrong.

For each specific topic detail you need to know, search for web postings about that, and see if you can think of what comes next, before reading what comes next. Try 'everything', 'live'. VMs.

One specific idea is: LQ ZRT that are *more than* a few days old, that you could answer usefully, even if substantial research/study needed. You might even end up showing your successful solutions (+on other sites too) to your interviewer! 'Soft skills' (how to best handle things in life) are important to practice. Great employer insight in #2 here. Welcome to posting!!! Best wishes; looking forward to seeing your successes

Thank you for your valuable replies. Just humbled and happy to see how the folks here are so helpful to see you succeed.

For me most of the times, interviews come in a jiffy. Prolly with a lead time of 2-3 days. Happens with me all the time. I might be cloud engineer or working on virtualization support, then suddenly a good opportunity for a Linux role lands up, for which there is no ample or enough time to brush up. Therefore was wondering something like a quick troubleshooting refresher which can be used as a pointer to recollect the old experiences and help to get in rhythm. For example: ssh related section which might say how to troubleshooting authentication when ssh connectivity in place or ssh related config file etc. I mean giuide with topics chunked up to quickly go through.

Hi,

Troubleshooting is an art. Your knowledge is important in order to break the problem down in terms that you can define so as to lead to potential solutions in order to solve or correct the problem. Bring things to simple terms can help to diagnose in order to come to a solution for hardware or software. By breaking things down so you understand at the level of the problem and come to a conclusion requires knowledge within that subject/realm.
Hope this helps.
Have fun & enjoy!

When you cite that it is hard to crack these interviews, perhaps after the fact, you ought to keep a journal of these questions or problems and look more deeply into why they are a problem for you. Sometimes you may also have the opportunity to ask of the interviewer what their thoughts are, once you've surpassed the point where you either got it, or didn't. Sometimes people may be generous enough to share their thoughts in spite of you not measuring up.

Immersion is #1 regarding being capable of dynamically troubleshooting. But to add to that would be sufficient knowledge gathering about the problem to understand what the problem is, as well as the desired solution. If you find that people tend to ask you lots of questions about a particular topic, i.e. SSH related, or performance related, then immerse yourself into studying this on an appropriate platform to learn firsthand about how to debug those types of problems better.

Registered: Aug 2010
Posts: 2

What do you mean

@Habitual
Please follow the LQ Rules!
Your posts was not constructive and relevant to the thread.