- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Actually in slightly older times the word had a slightly different meaning concerning something said quickly and suddenly. So yes, potentially, you could ejaculate something to dismiss a potential candidate rather effectively and do so completely cleanly.
Admin
Yes, I just got caught up and fell down the proverbial stairs.
Admin
"Did it hurt?" he ejaculated.
Admin
Must be a masochist.
Admin
The first thing I would have checked is that the monitor had power, was plugged into the computer, and was turned on.
Admin
If I hear three beeps, I'm definitely not worried about a monitor.
Admin
Surely checking for smoke before 'is it plugged in and is it turned on'?
Admin
I've seen monitors smoke and catch fire before. Plug pull of course stops that in its tracks.
Best story I heard was an admin who had remoted into one user's machine and was working away when the monitor started smoking. The user promptly told the admin she smelled smoke and asked, "is there a fire by you?"
Admin
Does it mean I don't get the Job?
Admin
I've seen things like this spread out all over Arthur Conan Doyle's Sherlock Holmes novels. Gives you a whole new take on the story of two young gentlemen living together...
No, the expected first point of attack is to consult your motherboard's error code list.
Besides, do PCs still beep for errors? My case doesn't even have the speaker, as far as I'm aware... it just cycles through error codes on boot and if something screws up, it gets frozen on the screen.
Admin
Most boards still have the speaker connector, even if there's no speaker attached. I have a few salvaged ones stored for such occasions.
I liked my old EpoX board, it had a two-digit LED display that showed last reached POST code. You could just crack open the manual and read off the code to see where it got stuck. Well, step before, it usually got stuck on some
Idlecode following the failed one.So if it got stuck on
0Cfor example, you'd look it up, and if it wasIdlework your way back. If0Bwas GPU failure you knew that's what failed.Admin
Amazing things. MSI has a D-Bracket, serving a pretty similar purpose, but with some LED diodes instead of a display. Too bad it's not typically included.
Hell, those motherboards even expose a programming header for when you fucked up badly. All you need is an USB programmer and a 3,5-to-2,5 HDD passthrough to account for the smaller raster.
Admin
Nowadays it's often soldered directly to motherboard. And while cases usually don't have a fixed speaker, a beeper like this is often still included: [image]
Admin
He still is. Occasionally...
Last time was a couple of days ago.
Admin
Yes. I happen to know that the beeps are codes, ands since I don't know any of that by heart, I'd go to another PC and look it up.
Yes.Admin
Admin
I think part of the issue was the pretence of knowing some information. I'd say there is no excuse for that.
Admin
Normally you are correct. But I left out some context.
For the purposes of this interview question, no manual was available - or Google either (back in 1998, when I originally came up with this, there was no Google as we know it today). The point was to see the thought process of their troubleshooting. It still amazes me how many people are utterly lost when they can't consult "Dr. Google," as one person termed it.
Let me put it to you this way: would you hire a programmer who's answer was always, "I'd look that up on Google?" and/or "Let me crack open the how-to manual?" Can they write a Do/Loop without cracking open the C# book?
Admin
Yes, but back then he was actively inflicting himself upon the community. These days he's only passively part of the community. I prefer this New Jeff. Less twuntiness.
Admin
It can be found in the Harry Potter books as well, with hilarious results. (NSFW)
Admin
I just demonstrated proof positive here that I AM TRWTF™ -_-
Admin
Not all managers are terrible. The best ones avoid WTFs while encouraging developers to strut their stuff to build awesomeness.
Admin
The best managers filter out the shit from above, protecting their workers and allowing them to get on and do what they're supposed to (and what they usually want to, too). Too many managers just add to the shit torrent instead.
Admin
The question as you phrased it ("beeps three times") suggest that you need to know what three beeps signify. And that requires either memorizing all motherboards' error code lists, or well, looking it up.
Basically, you set up a (pretty crucial) piece of information and then outright said "you can't use it". That's not a good question.
And given a guy whose answer is "I take a random component and test it, then take another random component and test it, and keep throwing stuff until something sticks" and a guy whose answer is "I consult a goddamn reference", I'd hire the second one. "Looking stuff up on Google" is not wrong per se - I often consult Uncle G for syntax which I simply forget, but I know what I'm trying to do. And that's the crucial programming skill.
Admin
My answer would probably be something like:
Yes, I'd be looking up the beep codes on Google. I don't have every motherboard's codes memorized. But I'd then outline a procedure that could make USE of the information; knowing what to do with the information on Google is like 80% of being "good with computers" nowadays.
Admin
You also know that it's worthwhile trying to look it up (or, vice versa, that it's impossible and so not worth the search); that the answer is out there. (Along with the X-Files.) Syntax is for reference manuals.
You'd be remembering that the codes mean something though. Lusers would just report that “it's beeping at me”. Where they manage to make it beyond “it doesn't work”.
Admin
To an extent, of course. If you google
forloops for ten years as a senior programmer, you might not deserve the position.And of course, working with this is also an important skill in tech support. If I were recruiting, I would ask a question of that sort - "an user comes to you and reports 'my shit ain't working, make it work'. What do you do?".
Obviously, the correct answer involves asking questions. Not starting with replacing RAM, just like you don't start your diagnostic procedure with a lung transplant.
Filed under: unless you're doctor House, but you're not
Admin
I've had some really good managers like that. Unfortunately, the companies where I've encountered them made that kind of filtration necessary.
Admin
You missed the point. I'm testing the person's skill with their fundamentals, not their ability to be like a code monkey and follow directions. Anyone who is literate can do that.
Nothing random about it. Troubleshooting is knowing how something works on a fundamental level (computer parts each have a function, i.e. hard drive for storage, RAM for working on the immediate task, etc. etc.) and approaching a non-working system with that basic knowledge, a person can determine what's wrong, regardless of what the error code means. The beeps themselves are a red herring if you can't look them up, and meant to distract you from the fundamentals. Good techs know this and don't get stuck on that point. When the question is asked, "no manual is available and no Google is available" is disclosed up front with the question because it's the troubleshooting skill that is specifically being probed.
If a person can't apply fundamentals, I don't want them working for or with me; they need to go back and learn how to apply their knowledge.
The best, but not by any means the only right answer, is to strip the system down to "bare bones" (CPU, motherboard, RAM, video card) and try to boot that. If that doesn't work, you've got 4 components to check. If the bare bones system works, add components one at a time until it fails, and you've found the malfunctioning component.
Alternatively, starting with a logical component that can be easily swapped (RAM) and working from there is also very much acceptable. Guessing the component that all others depend on & would require the most time up front to check (i.e., the motherboard) tells me the person is not approaching the problem logically or can't think with relative importance - especially when they mull for five minutes to come up with that answer. Contrast that with the competent people I interviewed who almost immediately started with RAM, or video card, or hard drive, etc.
The entire point is I want the interviewee to demonstrate to me that they are NOT doing this randomly but with a purpose of eliminating good components until the bad one is found, quickly, logically.
Perhaps my coding example was not the best illustration of the point. Now that I've outlined the above, perhaps one of the experts coders here could come up with a better example for that discipline.
Admin
Also knowing what to look for. If you're solid on your fundamentals on how something is supposed to work in general, then you know what to look for and will recognize it when you find it.
The point of my question is to separate the "look up Google/manual/some other reference" part of it from the fundamentals skill part of it. I would welcome other ideas on how to approach that challenge.
Admin
Obviously one shouldn't get stuck there - but you shouldn't have given the information in the first place. The first instinct when troubleshooting is to narrow the problem down without taking a screwdriver to the chassis just yet - by means of error codes and other clues.
Yep, a knowledgeable person should be able to determine the problem just by being told "it ain't working" and starting from here. But it would take a lot of time, effort, and open up the potential of breaking something else. What you seem to want people to do is to mechanically follow a troubleshooting routine, disregarding the information they have. And that doesn't make for a good tech, it makes for a monkey who memorized a troubleshooting guide.
Again - a good interview question would be "a client comes to you and says his computer isn't working - what do you do?". And if somebody didn't start with diagnostics and asking questions, but immediately grabbed a screwdriver, I wouldn't hire them..
Admin
All larger companies (say, over 150 employees) have such management, and so need such filtration. It's driven by human dynamics (basically, humans are about 3 times more efficient than chimps at “social networking” so the maximum size of self-organising social group is 3 times larger) and not by IT.
Admin
Admin
My test question was a case I ran into myself in 2000 at a manufacturing facility. Exactly that scenario. It was shortly after that incident that I had to interview someone for a tech position under me that I decided to use that scenario as my test for the aforementioned reasons. I base my approach on real world scenarios which can happen even today - internet access can be down, Google can be offline (even if only for a little while), and manuals are lost all the time. I'm sorry, but although we're in agreement on most points, I can't agree with you on that one.
Edit: historical data: I was originally asked a similar question that you suggested (as quoted below) back in '96 when I interviewed for a job at Computer City. In '98 I developed it further for my own use by throwing out the manual in the process so I can force analysis of the issue. In 2000 I ran into this issue in real life with the manufacturing client asking me to look at a PC that 'wasn't working'. That was the PC that, upon power-up, beeped three times and nothing came up on the screen, which turned out to have a video card malfunction. This example is what I now use in my questions going forward to vet all technical applicants. I considered it perfect as anyone who now tries to say: "That doesn't happen in real life," I know doesn't know what they're talking about.
I would agree with you here & will consider this approach going forward.
Admin
I've worked at Really Big tech companies that were full of management BS, but (apart from how do we screw our competitors without technically violating any laws) it was sane BS, and required minimal filtration. I've also worked at smaller companies where the CEO must have mistyped MBO as MBI, figured out that "intimidation" fit the new
acronyminitialism, and decided to run with that, that were jump-on-the-table-scream-and-throw-feces insane. Having good filtration in this situation was essential.Admin
Try IT support at a big university. Lots of
tinpot dictatorsprofessors controlling all the money sources, and IT line management thinking that the right approach is to swallow every damn Gartner report that ever existed whole. Things can struggle on in a dysfunctional way for years, and theTower of Babeltorrent of BS just grows as there's more and more pointless reports and memos and less and less real action. When that's going on, a good manager is a great thing to have.And then the real problem leaves for other pastures, the new broom turns out to be less WTFy, some of the poorer middle managers get sidelined, and the WTF level goes down. It's not really an inevitable state, but it feels that way when you're inside it.
Admin
Stabbing the client repeatedly with a screwdriver is a proactive step to reducing the support workload going forwards.
Admin
Admin
Only if the client is a troll or a PHB. We wouldn't want our work load to disappear completely. ;-)
Admin
Just saw Star Trek TNG episode "Rascals". Somebody needs to be acquanted with the Ferengi, who can't tell the difference between made up BS and real starship teminology.