A View from the Other Side of the Table

I have a confession. When it comes to necessary evils in the workplace, the one thing I hate more than interviewing for a job is to interview someone for a job.

How can that be? You ask.

It's true that as an interviewer I am not on the hook to answer random and esoteric technical questions for four to five hours straight. It's true that my next job is not on the line, and after an hour of interview I can go back to my regular tasks and put it all behind me. And it's true that during an interview I am in the driver's seat, on this side of the table and thus in a position of power--I get to say yay or nay, hire/no-hire, thumbs-up/thumbs-down. Still, it is something I dread all the time.

Being the only woman on my team and one of only a handful of senior female engineers in my organization, I get called on more often than I'd like for interview duties. I think it has something to do with the company's inclusive hiring policies and gender representation guidelines. That means I, the token female, get to be the honorary 25% for HR's statistics. Little do they know that while the 75% might consist of a rotating mix of guys, the 25% is always me. Just me. Ever dutiful and conscientious. Glad to shoulder the responsibility of representing the minority. Groan.

To begin with, I am an introvert. I hate being stuck with a stranger in a room and having to be the one initiating conversations. Being an interviewer means you have to furnish the topics of discussion and control the pace and tone of the interview for an intense sixty minutes. Go too fast, you run out of things to say or ask. It makes you look amateur and ill-prepared. Go too slow, you don't get to assess everything you need and you risk running over-time and handing him* over to the next interviewer haphazardly. While listening to his response to your question, you are mulling over what the next question should be, crossing out one question mentally and opting for another depending on his response. Meanwhile, you've missed out a big chunk of what he said, and you're wondering if it's time to change topic and how long a pause in conversation is endurable in a setting like this? And the mantra is running through your head: "Be positive!" "Remember, you are representing your company!" Even if he ends up being a "no-hire", he'll go back and tell his friends about what happened here, or worse yet, write something nasty about his experience on glassdoor.com. Either way, it's a stressful situation, and I hate making people uncomfortable, which is sort of the purpose of an interview, asking them tough questions, probing what they do or do not know.

As if trying to keep an hour of exchange going isn't stressful enough, there's the need to come up with technical questions for "white-boarding." For those not in the software development field, white-boarding is where you give the interviewee one or more technical problems, and make him solve them on the dry-erase board in front of you, talk through his thought process, and write code to demonstrate that he really can do the job of a software developer. The problem is that we rarely develop software this way. When I code, I plug in my earbuds and shut everyone out of my world. I don't look at the clock to see how much time has elapsed. Creative problem-solving happens when you're not under pressure. Unfortunately,  I have no choice but to inflict this trial on another human being, making him squirm and sweat to prove himself. Then there's the challenge of coming up with original problems that someone can solve within thirty minutes or less. I don't like to use the standard questions that everyone knows. What's the point when you can memorize the solutions and regurgitate them? Yet, it's hard to come up with that perfect problem. You need something that doesn't overwhelm with too much complexity and at the same time isn't too fluffy or pathetically trivial. You want to show that it's a relevant, real-world problem, not something you got straight out of a CS201 textbook. I've pored over interview books, googled interview problems, and I still fret over these before each interview.

The day of the interview arrives. I've had a rough night preparing my script for the one-hour ordeal. I've read his resume. The guy has a master's degree in computer science and has more than triple the years of software experience that I have. His list of expertise goes on and on, many of which I have never heard of. I eat a light breakfast but my stomach is none too happy. I check the time and there's still five minutes on the clock. I check my email, but I can't concentrate. Finally, the receptionist tells me the guy is here. I go down to the lobby to look for someone I have never met. By the look of his resume, I'm guessing he is in his thirties. Will he be pleasant of demeanor and eager to please, or will he be haughty and reluctant to play ball? (I once interviewed a guy who refused to get up and code no matter how I prodded him.) This guy is nice. I make small talk while escorting him to a small conference room. An hour later, I will emerge from the dungeon into the sunshine, glad to have survived another interview, hoping the next one won't be coming any time soon.


*I use "him" as the pronoun of choice because throughout my career, which has spanned multiple decades, I have only had the opportunity to interview one woman, and it was not for a software developer job. So this is simply a realistic reflection of the state of things.

Comments

Popular posts from this blog

Let's Talk About the Elephant

Why I Am Still an Engineer