Archive for November, 2009

What do you want?

November 6, 2009

I was asked today what I wanted in a job.

It was surprisingly difficult to answer.

I like achievable challenges. That’s obvious. But—getting some CSS to display just right on Internet Explorer 6 is an achievable challenge, but it’s not work I’ll enjoy. Crushing a hard bug is fun, but debugging code that should never have made it through review is not. Writing efficient code is fun. Dealing with low-level memory management, not-so-much. Type errors in loosely typed languages feel preventable. Not fun. Designing a good API: Fun. Dealing with legacy constraints: Not fun.

These days it’s popular to filter software engineers: Front-end or back-end? Applications or systems?

But this isn’t a key distinction for me. It doesn’t capture the essence of what I care about. I could be happy working on front-end or back-end code. I could be unhappy working on front-end or back-end code.

Now, moments after my interview ended, I’ve managed to figure out the answer…

Accidental complexity: Not fun. Intrinsic complexity: Fun.

On Mobile Phones and Driving

November 5, 2009

Worth repeating, from Jakob Nielsen’s excellent newsletter:

In an opinion poll, the New York Times asked whether Americans wanted to outlaw mobile phone use while driving:

> http://www.nytimes.com/2009/11/02/technology/02textingside.html

80% of respondents said that using a HAND-HELD cellphone while driving should be illegal.

But almost 90% said that it should be legal to talk on a HANDS-FREE cellphone.

Completely OPPOSITE INTUITIONS about the danger of these two ways of using a mobile phone. This despite the fact that all studies show that it’s EQUALLY DANGEROUS to use hands-free and hand-held mobile phones while driving.

Research has found that the danger comes from the cognitive distraction of carrying out a conversation with somebody who’s not in the car. The problem is not holding the phone with one hand while driving with the other. The problem is the conversation and the way it lays claim to limited cognitive resources.

This finding is completely counter-intuitive: how can it endanger your life to carry on a simple, everyday task like a conversation? The survey clearly demonstrates that people’s perception of danger is completely divorced from the actual danger.

When driving, you are piloting a power plant, and a single mistake will cause human beings to die. This is a task worthy of your full attention.

Job Interview Notes

November 4, 2009

A message I sent to the students of CSC 290 (Communication for Computer Scientists) following our class with practice job interviews.

Alexey said: “I wish I had not used `you know`, `er`, and `well` that often. But these words come out instinctively, as they give me time (a second or two) to think of what I am going to say next. Still, there must be other ways.

Here is a golden phrase to memorize when you need time to think about your answer for a question:

That’s a good question. Let me think for a moment so I can give you a really good answer.

You can also buy time by paraphrasing their question:

Just so I know exactly what you’re asking—Are you saying <your interpretation of their question>?

Of course, if you use one of these on a question that should be easy, you’ll seem dumb. And you probably can’t get away with using either more than once.

Yanshuai mentioned that he should have prepared a pitch for his computer vision project. In fact, you should prepare a pitch for every single item on your resume. You should also prepare pitches about your experiences in overcoming challenges or conflict, working in a team, dealing with difficult people, disagreeing with a superior or with your team, and so on.

You shouldn’t memorize your pitch, though. Instead, think about and jot notes about the importance of the project, the transferable skills you learned, and how it might relate to work at X.

Lots of interviewers also ask, “Tell me about yourself.” “Why do you want to work for X?” “Why should we hire you?” “Where do you see yourself in 5 years?” There is no excuse for stumbling on any of these questions. To answer them, remember: They are asking you to tell them about a personal quality or skill set. Lil gives an example: “I can multitask and meet difficult deadlines.  For example, when I was taking X course, I was also working on project Y, and had deadline W at work.  I was able to complete all these tasks by ___ and ___ resulting in ___.

George mentioned doing mock interviews with a friend. This is a great idea.

Leon said, “I practiced answering questions rather than exploring my experiences themselves. If I had another chance, I would have prepared differently by studying past experiences and situations carefully.”

This is an important point and applies to more than just job interviews. Once you have developed good foundational speaking skills, your best preparation is not canned answers or prepared words. Your preparation will be about becoming deeply comfortable with your material. Then the words will flow.

Reza asked, “Also knowing that the interview is short should I let him ask more questions?

While it is important to give complete answers, you should always leave the interviewer in control. In fact, you should carefully listen to the interviewer to get a sense of whether he or she wants you to take charge and talk a lot, or whether he or she would prefer to move things along.

In an interview, it may feel as if you should talk a lot, but in fact a big part of the game is listening to your interviewer (deeply listening—not just staying quiet while they talk.) You should listen actively—for example, paraphrase them and ask questions. Another one from Lil: “So you’re saying that the researcher wants you to organize data on 10,000 irradiated mice and you’re looking for a way to automate it:  Is that it? What are the resource constraints?

I should probably explain “deep listening” better. Here’s an attempt.

We learn as children that “listening” means not interrupting the other person.

“Active listening” is a skill that involves engaging the other person in a conversation to gain a clear understanding of what they are saying.

When I say “deep listening,” I mean listening with all your brainpower. It’s hard work. You’re not just trying to understand their words. You’re also analyzing: What are they saying between the lines? How does this person feel? What’s going on in the back of their mind? What are they like as a person? What’s important to them?”

Actually, if you do this, you won’t need to worry about eye contact or eager posture since it will come naturally.

Taking a step back, the best way to prepare for an interview has nothing to do with interview questions, practice, listening or public speaking skills. To prepare, you must build your resume. By that I don’t mean putting words on page. Build your resume means actively seeking out new experiences. Then you can put them on your resume. Joining and contributing to team projects boosts your leadership and teamwork credentials. Writing open-source code outside of class is one of the best ways to get new technical experiences.

And of course,

  • Smile
  • Make eye contact
  • Shake hands firmly
  • Sit up
  • Judo: Turn weakness into strength
  • Give complete answers
  • Demonstrate enthusiasm and confidence
  • Be specific

Most importantly:

  • Prepare
  • Listen to your interviewer

If you have other important comments that I’ve missed, please let me know.

Your loquacious TA,

Aran