How to verbalize something that is second nature to you?

December 29, 2005 10:00 AM

How do you verbalize things that you just -do-? Specifically with regard to computers (or anything else for that matter).

I am a high level unix admin. I've got 15 years of experience under my belt. Every position I have had, I've been lauded for my technical abilities as well as my ability to mentor my coworkers.

I just bombed a phone interview for my dream job. Big time blew it. The person asked me some deep nitty gritty technical questions, and I found myself going completely blank. If I had been at a terminal actually doing what needed to be done, I would immediately have all of the answers in my head, but when asked cold and out of context, I go blank. I'm a problem solver. Give me a problem and boom..I fix it. But I couldn't really tell you step by step how unless it was right in front of me.

I really am quite good at what I do, but I need to learn to verbalize the things I do that are second nature, otherwise my impressive resume means zilch. I'm feeling really dumb right now. Does anyone understand what I mean? Any advice?

note - this is the first time in many years that I've had to go in to interviews cold - no feet already in the door

posted by zerokey to Work & Money (19 answers total)

"Give me a problem and boom..I fix it. But I couldn't really tell you step by step how unless it was right in front of me."
...and I'm certainly more than willing to come in and demonstrate just that.


and that's probably what you should have said. I suffer from the same thing and it's hurt me on a few job interviews too. I have actually offered to go into the place I am interviewing and bang out a project for them, just to show them I know what I'm doing.

We had this guy work at our place. He was mr. linguistics. Sounded great, talked a great game but didn't know shit. I suggest you focus on trying to demonstrate your skills rather than speaking about it. I don't know if that helps but man do I feel your pain.
posted by j.p. Hung at 10:05 AM on December 29, 2005

Interviewing is a skill unto itself, sorry. You'll likely not get too far for a position with other candidates by explaining that you need a terminal to do it, because they already know that.

Read Programming Interviews Exposed. Practice with a whiteboard starting now.
posted by kcm at 10:08 AM on December 29, 2005

You know, perhaps it really wasn't the dream job you thought it was?

Consider that their interview process may reflect the requirements of the job - that you be able to, on demand, articulate exactly how to do what needs to be done. If you couldn't do so in the interview, think about a job with that sort of thing constantly in your face (as unlikely as I think that would be, considering what I perceive to be the basic nature of the work).

Imagine yourself working in a place that put more value on talking about how to get things done, rather than getting things done.

My first rule of interviews: you are interviewing the company as much as they are interviewing you. What they ask, how they ask it, how they treat you, etc... is a very good indicator of how the company, or at least your potential supervisors and peers, operate and what they value.
posted by C.Batt at 10:20 AM on December 29, 2005

If you're actively looking for a job "in the wild" for the first time in your life, maybe you need to see/hire some sort of job-hunting consulting firm. Some of them will run you through specific sessions to help enhance your interview skills and lower the anxiety.
posted by nkyad at 10:34 AM on December 29, 2005

CBatt nails it out of the park, but you should probably consider this a wake-up call to work on your communications skills. The computer business is getting more competitive and a lot of the better opportunities are going to go to the people with diverse skills. Communication is likely going to head that list, and perhaps rightly so - Our People do not have a great reputation for communicating well outside of the tribe.

Perhaps you could look into seminars and classes on interviewing and/or public speaking and branch out from there. I often think that the time I spent doing sales to put myself through college was some of the best work experience I ever had, despite it being completely out of my preferred field and disliking it.
posted by phearlez at 10:39 AM on December 29, 2005

Okay, this is my area of expertise: I'm a technical writer/trainer. I'm the exact opposite of you. I'm a so-so technician, but I'm really good at communicating ABOUT technical topics. The interesting thing is that I look at such communication as problem solving: receiver doesn't understand X, because he lacks the background. So how can I get him to understand X. Oh, I have to explain the background first! I actually lie awake at night, trying to work out good ways to explain things.

To a certain extent, I was born with the ability to explain complex ideas/procedures -- which doesn't help you at all. But I've definitely gotten better at it by working at it. And so can you. But to do so, you'll have to treat communicating as a subject worthy of study and effort. You'll have to think of communicating as a complex application or new OS or programming language. You'll have to invest many hours -- and not just look at it as a quick sideline.

Naturally, you may choose not to do this (life is short). You may choose, instead, to take other people's (good) advice and honestly say, "Hey, I'm a techie. I DO; I don't explain." Some people will understand that; others won't. And those people will be bad matches for you.

Assuming you DO want to improve your explaining skills, here are some general tips:

-- Avoid pronouns and general words. Don't say, "You move the thing into the thing and then press the button on the side." Instead, say, "You click on the red rectangle with your mouse and then drag it into the green, octagonal area. After that, you click the OK button."

-- Think deeply about your audience. What is their background re computers? Ask questions if you don't know: "Have you used Linux before?" Some people who consider themselves computer savvy have gaping holes in their knowledge base. I once met a fairly good programmer who had never fully mastered Save vs. Save As... So if I rattled off a procedure that began with Save As... and then went on to twelve other steps, he'd be stuck on step one.

-- OS-metaphors are problematic: folders, buttons, windows, etc. are great, but they're TOO literal for some people. I once worked with a woman who got totally confused by the concept of a subfolder. In real life, you rarely put a folder (in an actual filing cabinet) inside another folder, so she couldn't get why anyone would want to do this on a computer. Even if you're dealing with a command-line interface, there will still be metaphors (i.e. navigating to a directory).

There's a harmful idea in computer training that people learn better when you hide the details from them. When you put a metaphorical layer on top of the under-the-hood details. I find that this saves time at first, but in the end it bites people in the ass. I know designers who can NEVER master high-lever Photoshop opperations, because they don't understand Channels.

So while I don't spend hours on this stuff, I am prepared to take people right to the "atomic" level of computers. I will explain bits and bytes if I have to and then build them up to the OS/application level from there. The under-the-hood stuff is actually not that hard to understand or explain, but you have to explain it thoroughly and clearly.

-- Computers are unimportant. Okay, I know they're important to US. But really, why should a lawyer or CEO spend years learning the ins and outs of Linux? You can either approach such people with a superior attitude (i.e. "The Computer Guy" on SNL) or you can provide a service and let them get on with the important things in their lives.

But if you live with computers -- even if you're a nice person -- it's SO easy to get exasperated with someone who, say, doesn't know how to doubleclick. Just take a deep breath and remember that they are not necessarily dumb. It's just that they were busy going to the prom and wining trials or whatever while you and I were geeking out.

-- Computers are stupid. And they don't have feelings. Blame them when things go wrong. It's okay. They won't cry. When, say, a PC person has to work on a Mac and they're complaining to me about how horrible Macs are, I NEVER DISAGREE WITH THEM. Sometimes, I'll say, "Yeah, it sucks that you have to work on this dumb machine!" I may then show them some cool things they can do on a Mac, and maybe I'll win them over. But initially, I don't contradict them. I suspect, when they bring up how dumb an OS or application is, they're trying to see whose side I'm on. They're used to techies siding with the machine, and it's refreshing to them to think I'm one of them.

-- Spend time coming up with metaphors of your own. As we know, computers are just bits being operated on. Everything else is layers and layers of abstraction. As noted above, these metaphors don't always work well. Maybe you can do better. I cracked the subfodler issue by likening directories to trees with branches. It worked for that one woman.

-- A picture is worth 1000 words.

-- Talk to yourself while you work. "Now I'm clicking the red button; now I'm switching to another directory; etc." Imagine there's a blind person sitting next to you, and you have to describe each step so that he can visualize it. Gradually, you'll get better and better at doing this. Eventually, you'll be able to do it away from the computer. You'll be training yourself to translate your steps into words.

None of these tips will help you instantly. If you want to absorb them, you'll have to spend time cultivating them. The negative is the big time investment. The positive is -- aside from doing better in job interviews -- becoming that guy who can create a bridge the world of technology and make it understandable. People love that guy.
posted by grumblebee at 10:58 AM on December 29, 2005

sometimes you just blow interviews. sometimes they are a walk. so i'm not sure you should blame yourself too much.

if you want to improve, i'd suggest both practicing (it's easy to think up questions) and also reviewing what you do each day. maybe start a private wiki or something where you note down problems and solutions. that way you review what you did beforehand, so it should be easy to recall as a "text".
posted by andrew cooke at 11:07 AM on December 29, 2005

This isn't what you asked, but... Write the interviewer, explaining this. Offer to visit to show them that you can, in fact, do the task, and many others, even if you didn't articulate it swiftly. Might not work, or they might like the initiative. Either way, I suspect you'd be happier.
posted by theora55 at 11:11 AM on December 29, 2005

Another thought: "How do you verbalize something that is second nature to you?" Make it alien to you. This is the philosophy behind "Drawing on the Right Side of the Brain." One of the reasons figure drawing so so hard is that to draw a person (or whatever), you need to see her as a collection of curves, lines, shadows and highlights. But we generally see her as a person. We miss the parts and see only the whole. So the author suggests tricks like turning a photo of a person upside-down -- and then trying to draw a copy of the photo. The upside-down person will look less like a person.

It may be that when you work with computers, they're so second-nature to you, that five steps seem like one step to you. Is there some way you could slow yourself down? Can you cripple your machine (or yourself! I.e. force yourself to work one-handed -- or via a voice-interface) so that you have to interact with it in a new way? If you stop it from being second nature, you'll HAVE to interact with it via a series of discreet steps.
posted by grumblebee at 11:15 AM on December 29, 2005

I'm not sure if this applies to you, but the ability to present your case in terms the audience will understand is a pretty basic skill in expository writing. Your post is clear, but if this is a frequent problem for you, it merits some attention.

And that's what it boils down to in this case: presenting your case in terms the audience will understand.

You need to slow down (as others have said). Watch yourself while you work and take mental notes. Call your computer-unsavvy brother over and use him as a stand-in for the interviewer. When trying to describe how you solve these problems, take a step back before you dive in, and brainstorm and explain your general hunches as to how the problem might be solved, and the principles behind why these hunches should work. This may help prime your brain's pump to help you visualize the specific actions you'd take for each one.

I know that problem-solving tasks on a computer can be more interactive than some other tasks—it's not following a recipe, it's trying one thing and seeing what happens; if you don't get what you want, you try something else. It's difficult/impossible to internalize both sides of this interactive process (you and the computer), but perhaps you'll have to try for this kind of thing.
posted by adamrice at 12:14 PM on December 29, 2005

It sounds to me from the question that this might not primarily be a communication or language problem.

It sounds like it might be the case that you simply don't know the technical information they were quizzing you on -- at least not in the abstract.

In my experience, most of the technically-minded people I've worked with seem to be on some level faking it. Or to put it more generously, they're smart enough to figure most things out without having to actually know everything. It's a good skill to have (it means you can adapt quickly as technologies change), but it doesn't meet everyone's definition or expectations of "expertise."

And I'm sure you've met tech people who fall into this category but who aren't quite smart or experienced enough to figure important things out quickly with, say, a supervisor looking over their shoulder. (I'm making this up -- are there supervisors who look over shoulders?) So assuming that this is a concern, and knowing that the interviewer hadn't heard of your prowess from a trusted colleague, how else was s/he to distinguish which category you fall in? It's much easier to distinguish between "knows everything" and "doesn't know everything" than between "Can figure anything out" and "Can't figure everything out."

If you were on a job and someone asked you the same "deep nitty gritty technical questions," what would you do or say? Probably the correct thing to do in the phone interview would be exactly that, without making it seem like a failing on your part.

One last thing that might help you get more helpful advice: The answers so far seem to assume that the interviewer was asking you about an imaginary problem that needs to be solved, and so that you could succeed at this by slowing down your mental process to the point at which you could teach your craft. Is that the case, or was the interviewer throwing you factual questions?
posted by nobody at 1:11 PM on December 29, 2005

I speak from experience: I always bomb the first interview. Because I have no idea what the questions would be like. As you say, I can solve any kind of problem with a computer in front of me, but cannot verbalize.

Don't sweat.

Here is what I did, very successfully:

a) Make a list of all the questions you remember from the interview.
b) Make a list of all possible questions you can find in forums and the internet on your specific field.
c) Try and find questions that are specifically asked by that company.

Then, just find the answers, and memorize them! I sometimes feel guilty memorizing answers, but that's the best way to verbalize.
posted by vjz at 1:23 PM on December 29, 2005

How do you verbalize things that you just -do-?

As an expressive, liberal-arts type guy who works in technology, I identify with the people who decided not to hire you. And I say this, not to be antagonistic, but to attempt to help: there is nothing that you 'just do.' If it's something that you do, especially in computers, then there is another verb for 'doing' it. If you don't know what those words are, then you should learn them.
posted by bingo at 5:50 PM on December 29, 2005

I just started the interview process, and I've found that having paper and pen with me really helps to calm me and also helps me to communicate.

When I'm asked puzzle questions, I can sketch to help myself think. When I'm asked to explain something I've done, ditto.

My mind goes blank when I'm nervous, but if I can manage to get something out it often helps to get things flowing again. Being able to sketch helps that. I had a phone interview last week and sketched during the call. I also talked through my thought process while solving the problem.

Someone told me that they don't necessarily want to see a solution immediately, that it is more important to see the thought process leading to the solution. I don't know if that's true.

good luck!

p.s. just remembered this thread from a while back, You know... Fred. In it someone posted a link to "The Writing Problems of Visual Thinkers". Maybe that will help provide some insight for you? Don't know if you are like that at all. It helped me.
posted by furvyn at 5:50 PM on December 29, 2005

Don't you guys think that one component of what's going on here is the personality distinction between programmers and sysadmins? I waver depending upon the day of the week, but for the most part I suspect I'm more of a sysadmin type than a programmer type. And what I mean by that distinction is close to the hacker vs. coder distinction. Sysadmin types like immediate, often messy, practical problems they can solve. They solve these problems not methodically, but intuitively. By the seat of their pants. Haphazardly. In this sense, I strongly suspect that part of why zerokey couldn't answer the question is because he doesn't know the answer in the way that the questioner presupposes. He iterates his way to the correct answer. Sometimes in a more focused way, sometimes in a drunkard's walk, and usually relying on intuition to guide him. It's a really, really, really crappy way to code (and I blame all those ubiquitous BASIC interpreters in our youths). It's not necessarily the best way to be a sysadmin, but it's not the worst...and in some environments this sort of fly-by-the-seat-of-your-pants is exactly the skill most valuable.

It's also not an accident that this decsribes the divide between those with a bona-fide education in computing technology and those who are self-taught. Ideally, the best sort of technologist is the one who has this instinct and this well-honed skill from years of practical experience but who also has education and a mastery of the technology in the most formal sense.

Obviously, I think I lean in the more formal direction. But I don't want to lean too heavily because IT work as an intuitive craft is very powerful and high skill with it worth a lot of money. But I think that the philosophy of the shop, whether it leans one way or the other, is likely going to be visible in the interviewing process and it's probably the case that you found out that this employer leans in the direction away from your strengths.
posted by Ethereal Bligh at 6:44 PM on December 29, 2005

I think it's entirely possible that we work faster and make different kinds of (more?) creative connections when we _aren't_ thinking verbally. That it would be difficult to describe what you do in words is not necessarily indicative of any lack; words use a different part of the brain, perhaps, than the type of problem solving you do in your best work.

It may be that in putting your work into words, you would not only slow down (expected, perhaps temporary), but alter the way you solve problems. Kind of a Heisenberg uncertainty principle of human problem solving.

This alteration would be good for some situations (relating to other people, no doubt), but could ground you in a way that's not best for "just getting it done". Still, one can usually accomplish more when working with others.

If you choose to stay non-verbal, it might be a happier thing to work with people who understand this concept.
posted by amtho at 6:57 PM on December 29, 2005

I'm going to make the assumption that you're talking about explaining things that you really don't know (i.e. a problem you know you can solve, but whose solution you don't know) and not simply your inability to articulate a known solution.

In the past, when presented with these situations, I've generally just started talking about the things I would attempt and the information I expect to learn from each iterative failure. I can't guarantee interview success with this technique, but it generally tends to work out fairly well.

Ethereal Bligh: I originally intended to disagree with you with regards to the sysadmin/programmer split. However, I've decided only that your terminology bothers me. I don't think that there is a methodological divide between sysadmins and programmers as you imply. Rather, I think that smart people tend to work in two ways: through application of training/experience or through intuition. However, a person, at any given moment, may work in one way more than another.

For instance, I certainly take a fairly formal approach to my high-level program design. Why? Because the cost of each iterative failure is high (eXtreme Programming notwithstanding). However, when I'm actually sitting there defining int getMagic(int**), I'm certainly following an intuitive approach to my work. Why? Because my forty-line algorithm only took me an hour and a half, and if it fails testing, I can fix it again easily.

When asked why I chose a particular implementation, I couldn't possibly tell you. "Umm... it just seemed like the correct way to solve it," is generally about as good as I can get.

(It should be noted that I am capable of proving correctness after the fact. I just can't show how I derived the solution. I had the same problem in many of my math classes.)
posted by Netzapper at 10:05 PM on December 29, 2005

You have "the Knack"? [mp3]

I tend to work intuitively with computers, too, and blazingly fast when I do, going on and on and on until I'm stumped, which I then take as the perfect time to take a break. (A frequent occurrence!) Then I have to either leave and think about it from elsewhere, or work on something different. In any case, when either working on the problem or mulling it over, I do so visually. I need to see visual representations either on screen or on paper -- pictures or words or diagrams or symbols, it doesn't matter, as long as I can "see" it, and then something just clicks in my brain and I work it out. I would not be able to explain the cognition process to anyone, why it works or how.

It happens with plain old communication, too. I am a much better communicator through the written word than otherwise because when I put them down on screen or paper, I can see my thoughts, detach myself from them, and scrutinize and rearrange them any which way I can, with ample time to boot. Verbally, I fumble and bumble and start and stop. Though I've grown more articulate over the years, the part of me that's supposed to parse what I need to communicate still has trouble plucking out the right things from the fast-whirling pool of thoughts in my brain and arranging them in proper fashion to be understood by others, without actually "seeing" those thoughts.

On the other hand, you might simply be experiencing performance anxiety/stage fright in your interviews. Don't put pressure on yourself by thinking "dream job, dream job! omg I can't blow this", think of it as just another problem to be solved, which you're excellent in doing. Own your skills, and be confident that no one is more qualified for that job than you.

I can think of two solutions for your interviews:

1) Get a friend, preferably a very verbal extrovert, to watch you work. Your role will be to explain to them every step of your work, from identifying the problem all the way to its resolution, and justify all your decisions (i.e. why you chose one particular way over all others). Their role will be to slow you down, ask questions, clarify, ask you to paraphrase from technical to layman's terms. In this way you'll learn about yourself and how you think: the unconscious will become conscious. Note them, translate your mental operations to human language, and practice expressing your working self in this way.

2) Explain to your interviewer straight-up beforehand how you operate. Depending on how much they value technical prowess over verbal prowess, you might be able to get through if you indicate that you prefer to show, not tell - solving the actual problem as opposed to merely explaining how you would solve it. It might go over better than you think.

Good luck, zerokey. I feel for you!
posted by Lush at 4:40 AM on December 30, 2005

Try explaining what you do to your mother, without once using the phrase "and then magic happens."

If you can do this, you can explain anything.

Surprisingly, I found that my mother asked very insightful questions, the answers to which I ended up incorporating into my standard spiel when helping users with problems.
posted by SuperSquirrel at 10:03 AM on December 30, 2005