Category Archives: Uncategorized

How to Kill It on a Phone Screen

screen

Louvre-Lens Indian window screen 1605 CE. CC BY-NC 2.0, by damian entwistle (https://www.flickr.com/photos/damiavos/10805845864)

I have been doing a lot of technical (coding) phone screens lately for my employer. For those not up on the jargon, that’s an interview over the phone with a candidate, vs. in person. It’s a “screen” because its primary purpose is to sift out the great candidates from the rest up front in a way that is inexpensive (versus, say, flying them somewhere or taking up hours of many interviewers’ time).

My schedule lately has been, on average, one screen per day. This is too many, but I guess we need people. Still, I’ve done enough now that I feel I can recommend ways that you, dear reader, can do well on a phone screen, provided that you have good enough skills. If you don’t have the necessary background and skill, though, none of these tips will help, so work on that stuff first, and use this to stand out.

Be clear and crisp

A fortunate aspect of voice transmission is that people can understand each other even on low quality connections. However, telephony providers are happy to operate as far down on that quality spectrum as they can, so it’s important to make up for that by speaking clearly. When I’m talking in person with someone, there are so many non-vocal cues I can pick up to understand you, but over the phone it’s only sound.

So, expand into that as much as you can to communicate. Enunciate a little, don’t speak too quickly, speak at a good volume. It’s OK if it sounds weird to you; remember, I’ve never met you so I won’t know the difference.

Ensuring that you are easy to understand also reduces my cognitive load. Instead of having to concentrate on understanding your words, I can concentrate on all the valuable things you are talking about.

Don’t let Verizon or AT&T determine how well you come across over the phone.

Organize your thoughts

In person, we could bandy back and forth about topics and in general have a much more natural conversational flow. That’s much harder on the phone. So, instead, take the time to be orderly and organized in how you, say, describe the cool project you’re working on, or answer a technical question.

I think conversing like this is unnatural for most people. It’s totally fine to take a moment to think before replying, to consider what you’d like to highlight, or internally plan out an answer. Just say you want to organize your thoughts. Believe me, you won’t sound dumb, especially when your answers are so much better.

Remember, a phone screen is separating the wheat from the chaff, so to speak. It’s great if you can really blow me away, but it’s even more important to make sure you can deliver solid answers and prove that you know your stuff. Well thought out answers and descriptions take care of that.

Offer opinions and personality

A secondary goal of phone screens is to see what sort of person you are. Every organization has a wide spectrum of personalities, and while a phone screener is mainly interested in checking your knowledge and qualifications, another aspect is seeing where someone like you might fit. What do we do that you might be comfortable starting with? That you might like? That your attitude fits just perfectly?

The way I can answer that as a phone screener is by hearing more than just facts. If you are oddly obsessed with unit tests; if you like making fun of people who use emacs; if you really despise statically typed languages; if you like Windows no matter what other people think; these are all great opinions to share. It opens up another dimension to your technical profile, and gives me as a screener other avenues to explore to really understand what you know.

Have a conversation and relax

It’s hard and uncomfortable to do a phone screen. Some random dude (that’s me) from a company you’d like to work for is calling you out of nowhere to test your mettle, and you can’t even see me. You probably haven’t done many phone screens before, or any phone screens for that matter. You might have thought you should dress up, just in case, even though I can’t see you. You’re nervous, and excited.

I get it. I try to help candidates relax when I start a phone screen by introducing myself and setting the stage a little, and make little funny or side comments now and again. That means it’s OK for you to loosen up a little, too. This is no doubt a serious effort for you, and I appreciate that, but you can demonstrate that you know your stuff in a less than formal way. If we wanted a deposition, we’d have you submit a report in triplicate. A phone screen means we want to chat, to get to know you and what you do.

My employer is picky, like, really picky. Odds are you won’t be hired. Despite all that, I approach each screen with an open mind, hoping to find the next awesome person. You have that chance, so let yourself come through. (It’s even more important over the phone to concentrate on that, since I’ve got no other sensory data coming in about you.) If you are hired, you’ll certainly be yourself in the workplace, so go ahead and be that in the screen. You’re nice, right?

Particulars for Coding Screens

Part of my employer’s phone screens is a coding exercise. Yeah, something like those stock interview questions, although we try to invent our own. I understand that some folks may think they are a waste of time, or that they are unfair because some people can’t just whip up code on the spot. But, a big reason we do them is to see, right there in front of us, whether a candidate can code at all. I’ve seen several sources that claim that more than half of their coding candidates can’t actually code. So, we’ve gotta check.

The goal of a coding exercise isn’t to get the “right” answer (you can guess that there isn’t one right answer – this isn’t homework). It doesn’t even need to compile. It just needs to show that you can take an uncomplicated problem statement and gin up some sort of algorithm to solve it. Maybe it involves data structures, or bit manipulation, or high-school level math. I’ll even give you pointers and help you along the way, although (like schoolwork) I can’t tell you the answer.

Given all that, here are more tips for killing it on a coding exercise.

Say something

I always emphasize this: Don’t go silent for umpteen minutes while you work. Even though we are looking at a shared editor, the main communication method is still the phone, and this is still a phone screen. Think out loud, ask questions, seek clarifications. I can’t help you if you won’t describe your ideas.

One thing you can bother not asking is whether your plan will work or not. That’d be giving you the answer, and I can’t do that. Just describe your plan and start with it. While I can’t say if something is right or wrong, I can point out where maybe there’s an issue to think about (or not, heh heh).

Type something

Seriously, type something. I understand that some candidates need a few minutes to think, plan out a design, maybe sketch out some stuff on paper before jumping in. But, I can only judge you based on what you type in, so don’t spend a lot of time before the first keystrokes.

Don’t have the loop conditions quite worked out yet? Write the loop anyway, then come back to it. Can’t remember the exact API? Put down something close to it and keep moving. Need a helper method? Declare something empty for it and use it, then if you get time implement it. Stuck? Write a comment there and attack some other piece of the problem.

This really favors people who can plan out and act fast, versus the more thoughtful bunch. I try to mitigate that by setting up a template for the problem, defined as precisely as I can, and with example executions of a “correct” implementation, to get you to the place where you really can just start rolling. In the worst case scenario, I’d rather you go with a half-baked plan, and correct it later on after we chat about it, than have nothing to look at for more than ten minutes and then see you’re off course. It’s maybe not your preferred mode of working, but a phone screen can’t last a super long time to be effective.

Get interested

There’s an old trick I learned about the SAT. The reading comprehension section of the test (I assume it’s still there) would intentionally pick the most boring-ass passages for you to read and answer questions about, because that makes things harder. You’re reading three paragraphs of Tolstoy and your eyes glaze over, and then you can’t answer the questions.

The trick is to get artificially pumped up about the paragraphs. “I am so psyched about 19th century Russian politics right now!” It’s amazing how that self-delusion will carry you through. Your retention soars, and the questions become just as easy – well, almost as easy – as those about your favorite topic.

While I hope the exercises I present aren’t that boring, I think it still helps to imagine it as a neat technical challenge that you get to play with and get into. You might be surprised at the facets of the problem that you come across, that you didn’t expect to be there. Still, since the exercises have to be small, they tend toward being more like grunt work, but doing grunt work sometimes is an inevitability of working on a coding team, so it’s best to buckle down and crank on it for the short amount of time and show what you’ve got.

The goal

To be honest, phone screens sort of stink. They cannot give me, as a screener, a full picture of who you are and what you know. They are a blunt tool used to cheaply narrow down a candidate pool, necessitated by practical limits on how much time we can devote to interviewing. It’s almost silly, because of how vital it is to hire the best you can, to use a flawed method like phone screens, but there are few lightweight alternatives.

On the plus side, though, this means that the bar for “getting past” a phone screen is lower than a full interview. The point you need to get me to isn’t “I want us to hire you” – although if you can, hey, great – but it’s “I want to learn more about you because we might want to hire you”. If things go well for you during phone screens, only then you’ll need to work at clearing the higher bar, so don’t sweat that challenge until you succeed in winning the privilege to try.

My deepest fear with phone screens is that I get you on a bad day, or I’m off my game, or we have trouble communicating, and I decide to pass on you when, really, you’d be awesome. This can happen with in-person interviews, sure, but I think it’s much more likely with a phone screen. So, I encourage you to use these tips, or other (better!) ones to minimize the odds of that happening. Let’s have my decision, and your decision too, not be warped by the limitations of phone screening.

Kicking off background jobs over SSH

I needed this information yesterday, as I was trying to use SSH from one machine to start a shell script running in the background on another.

You’re probably using the OpenSSH server, and started a background process on the server which you intended to continue after logging out of the SSH session. Fix: redirect the background process stdin/stdout/stderr streams (e.g. to files, or /dev/null if you don’t care about them).

Works perfectly. So, not this:

ssh remotehost "script.sh &"

but this:

ssh remotehost "nohup script.sh < /dev/null >script.out 2>script.err &"

This is also needed for pssh.

pssh -h remotehosts.txt "nohup script.sh < /dev/null >script.out 2>script.err &"

From Dropbox to BitTorrent Sync

I’ve been a fan of Dropbox for years, mainly due to how dead-simple it is to use and how well It Just Works. Lately, Amazon and Google have been trying to move in on the cloud storage game with their own offerings, and of course there’s Box, Ubuntu One, and other systems already competing. Obviously, the ability to sync files across your machines is super-handy.

My main problem with Dropbox has always been how little space you can get. Right now I have 4.42 GB of space in my personal account, over and above the standard free amount due to several referrals and uploading photos and trying Dropquest 2012. It’s a decent amount of space, but … Google Drive kicks you off with 15 GB right away, and Amazon even starts at 5 GB. Box starts you with 10 GB. Dropbox still starts you with just 2 GB.

I would have figured that Dropbox would start bumping things up with the growing competition, but instead their latest announcement was for some sort of photo gallery thing. I mean, I guess they have the whole file sync thing down pat so they need to branch out, but I don’t get how a gallery app is a logical next step. I really want more gigabytes. I could start using the storage in new broad ways.

A while back a friend of mine had me set up BitTorrent Sync in order to transfer some files. Unlike all of those other systems I mentioned, this one has no central server. Instead, your files are shared democratically across all computers you have linked using the same shared secret. As a bonus, all files are encrypted during transport, so that plus the lack of a central server means your files are better protected from anyone who might like to see them without your permission. That’s all fine and good, but what I really care about is that the space is unlimited, since you bring the storage.

So, I’m transitioning from Dropbox to BT Sync. Right now I have two Dropbox accounts, one for work and one for personal use. I’ll have the work one switched over relatively quickly, and the personal one before much longer. I’ll leave the personal one alive for a few isolated items, and as an alternative for cases where BT Sync isn’t as convenient (e.g., web access). Plus, I worked hard for those extra 2.42 GB, dangit.

I have an Ubuntu machine at home, and I installed BT Sync there to take the place of the central server in my scheme. If nothing else, it serves as a backup location for the files in my Sync folders. Although the system really doesn’t need an anchor like that, it helps me transition over. A better option would be to sync to a trusted friend’s systems, which would give me offsite backup. If there were a way to encrypt those copies, it’d be just about perfect.