Just found out my troubleshooting sucks

Went to an interview today and was asked a ton of questions. First they asked technical questions which i aced such as how you would setup STP, what ports would be in blocking mode, user is complaing about slow network, what subnet mask would you use for this network, etc ... Then comes the "brain teaser" questions which i bombed miserably such as "if a block is 'x' size how many cars can you fit in it without knowing the size of the cars". "If you had 8 blocks and you input a 1 on one end and a zero comes out on the other end, how would you troubleshoot.

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

apr911

Dont get too down. Personally, when I interview people I avoid most brainteaser questions like the plague. They are horrible ways to test someone's ability to troubleshoot since usually there is some sort of gotcha and you either know it or you dont. If they didnt ask any "real" troubleshooting questions, chances are they dont do a lot of "real" troubleshooting and if they discount your application based on your ability to answer those brainteasers than you are probably better off not working for them anyway.

Just because you can solve the cannibals on an island question doesnt mean you have troubleshooting skills, creativity or would be a good fit for the job. It just means you could answer some completely useless unrelated to the actual job question. I can solve a rubik's cube and the 4x4 rubik's revenge cube and by logic of the brainteaser question that should make me infinitely qualified to work any job but Im not, it just means I know the trick (algorithm) for solving the cube.

RouteMyPacket

I wouldn't take any potential employer serious if they asked such idiotic questions. Keep it technical..that's what i'm there for not to solve riddles.

The Technomancer

You see these kinds of teasers when the interviewer wants to see how you logic out a situation. In a lot of troubleshooting scenarios, especially when you're dealing with in-house custom code with poor documentation, you need to be able to track down the information you need, then use that info to diagnose the problem in an indirect manner.

It'll also show the interview the base assumptions you make, as when you're designing a new system, you need to make base assumptions to build a prototype to send over to load testing and QA, and the closer you get to the actual numbers this system will save, the more time (and therefore, money) you've saved the company during the design process.

Annytime you're being asked one of these questions, the interviewer's not looking for an answer, they're looking to see how you approach the problem. Never be afraid to ask the interviewer how they would approach it once you have a prototype answer, either. This type of troubleshooting is the equivalent of differential diagnostics in medicine.

One that Google likes to use is "How can I determine the number of sheep in Canada?"

Well, there's some assumptions you can make from this:

There's no sheep census...that would be a baaaaaahd idea anyway. Plus, they never ask questions like this with easy answers.

There probably is labor statistics about how many shepherds there are, and statistics on the average head of sheep managed by one shepherd, since Canada takes a census and gathers labor statistics.

Alternately, there's likely a count of how much pasture land is being used in acreage, what percentage of it is used by sheep as compared to other grazers, and you can find out how many head of sheep you can graze in an acre of land.

Both of those approaches will get you a rough estimate of the number of sheep in Canada.

---

Like I said above, however, they care less about the answer, and more about the logical steps you'd take to indirectly determine the answer. Remember that, and approach those questions that way, and you'll nail it every time if your logic is sound.

instant000

sizeon wrote: »

Then comes the "brain teaser" questions which i bombed miserably such as "if a block is 'x' size how many cars can you fit in it without knowing the size of the cars".

Divide X by the size of the car, to tell you how many cars you can fit in the box. That looks like an algebra question.

"If you had 8 blocks and you input a 1 on one end and a zero comes out on the other end, how would you troubleshoot.

The mystery of the blocks is that I can't tell if I'm just pushing in one side and getting a result out of the other that was the last thing there (imagine hydraulics), or if there is a function performed in the middle, that modifies the result.

I'd send a string of 1s, to "clear the buffer" and test the hydraulic hypothesis.

If that just yielded the same result regardless, I'd change inputs to 2, 0, -1, and -2, and see what my results were, in an attempt to reverse engineer the algorithm.

But, what is weird is that you made this sound like a network engineer interview (at least, in the beginning). These types of questions might be good to give a developer or something, but I'm not sure how they apply to being a network engineer.

EDIT: Technomancer posted how these types of questions are applicable.

The Technomancer

@instant000:

Data pipelining. If you have an application that absolutely requires a low-latency response (real-time ad bidding, high-frequency trading, etc), you want to fit the maximum amount of information into each packet possible to keep your overall TCP or UDP overhead at a minimum. A good network engineer is essential in determining where to split the information within the application, or if jumbo frames, alternate MTUs, etc. should be used, or even if TCP or UDP is the correct protocol (is this a lazy pipeline where missing data can be gotten later, or every packet must me tracked/trasactionally sound).

instant000

Technomancer:

Thanks for relating it back to the topic. at hand.

The Technomancer

@instant000:

No problem. One of my flaws is that I can talk in very abstract terms, and I may not be clear on how it related to the topic at hand. Please feel free to call me out on this if you notice it in my responses -- that's the only way I'm gonna get better at it. One of the downsides of being an Aspie. =/

DevilWAH

I actually prefer troubleshooting interviews that straight technical ones.

To many times I have seen people employed because they can list every protocol number and port assignment under the sun. Ask them how to configure something and they will give you a text book answer with every command formatted and indented to perfection.

But when it goes wrong, our you want a new Idea/solution, unless it was in an exam they took or a book they have read they are stumped. These are the kind of people who look at a working system and will tell you, "you can't do that" simple because it doesn't meet best practice.

These kinds of people are very good level 2 implementation engineers, give them a config or the out lines of a solution designed by a IT consultant and they will get it sorted. But as them to come up with it them selves and they will struggle to fit the solution to the customers needs and instead will want the customer to change to fit there "best practice" solution.

My view is that when i interview some one, that chances are that with the speed technology moves, they stuff they know as they sit in front of me will be out of date 6-12 months down the line, So I don't care so much about what they know as to how they approach work. And one thing I do want to know is how they approach pressured situation that take them out of there comfort zone. I would rather see some one freeze up in an interview when asked a silly trouble shooting question, that them do it for the first time as the network crashes around them.

But I do explain that the interview has two parts. One where I want to see there technical understanding, and second where I want to explore how they approach issues and problems. And explain that I am not interested in the answer to the problem, but I want them to discuss how and why the approach it like they do.

I like people who are pushing to find new and better ways of doing things, and asking them what protocol runs on port 22, or how to configure a GRE tunnel just doesn't tell me any thing about that.

As I tell every one I might employ,

1st line = develop trouble shooting skills.
2nd line = developing in-depth technical skills.
3rd line = means you can use them together.

for staff who have trouble trouble shooting i suggest they learn the scientific method as a good place to start, and if you have no idea where to start, start in the middle and keep halving till you reach the cause.

apr911

DevilWAH wrote: »

And one thing I do want to know is how they approach pressured situation that take them out of there comfort zone. I would rather see some one freeze up in an interview when asked a silly trouble shooting question, that them do it for the first time as the network crashes around them.

Give me a real world troubleshooting problem any day of the week and I can remain calm, collected and usually work my way though it without too much difficulty. Throw a silly "problemsolving" question at me and I freeze.

Sorry but most of the problem solving questions that Ive seen come up in an interview dont demonstrate your ability to actually problem solve.

I prefer a real world issue... I.e. Im the client/customer and I just called you because my main production website is down and I want you to troubleshoot. Whats the first thing you do?

I may not scream at them or do even a hundredth of the things customers generally do in the actual situation, in fact, Im usually downright helpful (especially compared to actual customers)... running commands without issue and relaying the output and/or having an actual understanding of how my site is setup. Even so, the end result is I can gauge not only the person's technical abilities and what areas they might need help on but I can also test their troubleshooting abilities based on how they approached a real world scenario and how they responded when asked why they went in one direction or another.

The Technomancer

If I had 4-5 hours to interview someone, I'd love to only throw real-world scenarios at them. But, here's a sampling of technologies in my infrastructure -- I have no way to cover all of these in an hour to 90 minutes, and this, again, is just a sampling of techs in my stack, with no custom in-house code included:

Redis
Cassandra
MySQL
Varnish
statsd
collectd
Graphite
Apache
Tomcat
Nginx
Python virtualenvs
Puppet

What I do know is that strong logic, curiosity, and an understanding of the scientific method will lead someone to the answer, even if it ends up being a roundabout way of doing it. I don't want to see someone freeze when they don't know something. I want them to come up with a plan, ask questions about the plan, and execute on the plan, because when PagerDuty goes off at @#$%-me o'clock in the morning on something you haven't touched yet, I want you to give it the old college try before waking my ass up.

DevilWAH

I agree to a point, questions should remain based around the technology they know and the job involved. But the question "the main server is down what do you do?" generally get the same response across the board. Along the lines of a structured approach that you will find in any text book or IT course.

While these do happen, a lot of problems that come up in the real world can be frustrating and elusive. And I like to see how some one will react in a situation that their tried and tested approach might not work. Do they get frustrated, do the freeze up, do they get angry. Customers as you mention are never straight forward and the manor they report issues can be "silly".

I would not expect a junior member of staff to answer such questions in an interview, but if I am interviewing some one who will have responsibilities and be accountable / a face of the business, then how they respond to "silly" questions is valid. And if they don't like the question then I expect them to say so. Some of the best candidates are the ones who have turned round and there first response has been to ask me why. I think the worst possible thing you can do is freeze up, and experienced IT engineer should be able to respond in some way to any question they are asked. In an interview with me people quickly find that I am not so concerned about there technical skills, I want to know what gets them up in the morning , how motivated they are and if things get tough will they winge and moan, or will the knuckle down and help get things sorted out.

VAHokie56

RouteMyPacket wrote: »

I wouldn't take any potential employer serious if they asked such idiotic questions. Keep it technical..that's what i'm there for not to solve riddles.

I second this, that would really annoy me

VAHokie56

ehh yikes sorry I could not leave my total post count number at 666...that is just medicine

tpatt100

I think if the employer uses a riddle to see how you react is fine as long as the employer isn't using the riddle as some sort of intelligence test and judge you too harshly on it. I think if a person reacts with hostility or gets upset easily then that person might not be a good fit if the crap hits the fan at work. If they reply with good humor then that person might be a good fit on the team.

Actually never mind I think riddles are stupid.....

eansdad

I guess this is better then how I was told. I took about an hour to find a loop in one of my buildings. After finding it I was working on what the problem was (either bad switch or misconfigured/bad stacking cable). So as I am testing our Network Admin and the Assistant Super (who thinks he's Gods gift to IT - Mac Lover) walk in and the Assistant super starts pulling power cables to reboot the stack. After few everything comes back up and is working. He states "I don't know why it took you so long to do this", mind you this was AFTER I removed the stacking cable to test the switch without it. Funny part was another building a few weeks later has a network slowdown issue, turned out to be a loop, took them 3hrs to find it. Another day in yet another building it took 2 weeks and bringing in an Engineer after a bad mini switch took out 3 buildings. But my troubleshooting skills are bad.....

For the brain teaser questions I got how would you find out how many gas stations are in LA without using the internet or phone book for the direct answer. It was later explained that they wanted to see how I approached a problem and what avenues I would take to solve it.

CompuTron99

tpatt100 wrote: »

I think if the employer uses a riddle to see how you react is fine as long as the employer isn't using the riddle as some sort of intelligence test and judge you too harshly on it. I think if a person reacts with hostility or gets upset easily then that person might not be a good fit if the crap hits the fan at work. If they reply with good humor then that person might be a good fit on the team.

Actually never mind I think riddles are stupid.....

I would hope that an interviewer would also take into account that the person being interview is most likely very nervous. I always consider that while interviewing someone. I went to an interview once to an IT position, and was handed a math test (fractions, converting metric to standard and visa-versa). I was so thrown off after that. When I handed the exam to the IT Manager, he laughed and said I was given a test for a different position in the company.

ccnxjr

There, there.

Don't let it get you down.
Well aside from the fact that you didn't get the job.
(ok, so you have a legit reason to feel bummed)

It's one of those things that you can learn from.
The point of the exercise is to demonstrate problem solving ability in new scenarios.
Granted, it can be weighted in favor of people who play around with brain teasers a lot.
It opens open an opportunity to one group of people while, unfortunately dismissing others.
The same arguments for or against this type of testing can also apply to IQ testing.

Some people are groomed for interviews, which put those of us who aren't at somewhat of a disadvantage.
There are all these classes and books and seminars for it.
Keep in mind that people who don't have perfect technique also get jobs.

However, having said that, while someone who succeeds at these types of test probably won't be guaranteed the job either.
So, there is some hope.

If a potential employer puts you in a position that requires you think creatively, do so.
The right answers may not involve solving the puzzle, but, as said before, your approach.
Start somewhere and maybe ask for a hint or two.

Best of luck!!

blargoe

I'm sorry, but I don't understand the value in these silly riddles in an interview. I have found that asking questions related actual, real-world technical troubleshooting scenarios are plenty effective in both gauging reasoning ability AND technical knowledge.

krjay

I think there is value in the 'silly riddles'. IT people are probably comfortable in most real world technical troubleshooting scenarios, or they can BS their way through them well enough to get by or impress you.

Looking back at my college career I think this was the most valuable thing I got out of my bachelors. At the time I thought 'why would they make me take these irrelevant courses that I have no interest in'. Now I'm glad I got put in all those unfamiliar situations in different courses where they made me critically think or problem solve in realms I was very uncomfortable (basically every non-IT related course).

undomiel

Well, as an interesting side note, Google who made famous the brain teaser interviewing process has determined to abandon it as they discovered no correlation between performance and how well the worker did in answering the riddles. I would definitely agree with that. I find it is much better to put in difficult scenario based interview questions to get a better idea of how someone would think through the troubleshooting or design processes. If you can find something they are uncomfortable with you'll get a glimpse of what they are like under pressure as well.