Finding A Job You’ll Love: The Reverse Phone Screen

Once you’ve sent out resumes, you’ll hopefully get a few people interested in phone screening you. You’re really best off if you prepare for these and for the in-person interview. Get a relevant textbook and start reading it in the evenings or on your lunch break. People seem to love algorithms questions, so get a copy of The Algorithm Design Manual and read the first few chapters. For my Endeca interview, I started reading Introduction to Information Retrieval. I got through about 5 chapters of it, and one of the interviewers started quizzing me on it. When I answered all the questions without thinking, he said “I’m trying to see how you do on a problem that you don’t already know the answer to, so let’s switch to something else.” Still, I’m sure it reflected well that I knew my Information Retrieval stuff.

The phone screen is for them to decide whether or not to bring you in for an in-person interview, and you want to help them with that decision. So you’ll spend most of your time answering their questions. You should ask a few questions of your own, but don’t spend more than 5 or 10 minutes on that.

However, once you hear that you passed the phone screen, you should do a reverse phone screen: before you schedule the in-person interview, ask to talk to the person who will be your manager if you join. Or you could ask for a tech lead, if you those are the sorts of issues that you care more about. For managers, my favourite questions are:

  • What’s your management philosophy? This is so open ended that it can be hit or miss, but with the right person it can be really insightful. Plus it gets them thinking, which will help them answer the later questions. Then ask What’s company X’s management philosophy? as an individual’s style may not represent the culture of the company as a whole. Some good follow up questions are What management books would you recommend? What do you like & don’t like about each one?
  • How do you figure out what to promise to the customer and when to promise it? There’s a sad truth about software process: It’s impossible to estimate exactly how long a feature will take to build. Even half way through the project, most organizations are off by up to a factor of 4. So, if they promise a fixed set of features on a fixed date more than a month or two away, you’ll probably end up being stressed and working crazy hours to deliver, and then the deadline will be pushed back anyway.
  • Do you use an Agile development process? Why or why not? What specific processes do you use? Whether you like Agile or not, you should know what you’re getting into. Also, it’s amazing how many people say “yes we do [insert buzzword here]” but when you question them on it, they don’t understand it at all. I had the CTO of a 500 person company tell me they didn’t use Scrum because it was a heavyweight process involving Gantt charts.
  • When an urgent task is supposed to take two days for a task, and half way through the second day the developer says “I don’t think I can finish it today,” how do you respond? I’ve been in this situation and had my boss just look at me, with a serious look on his face, and say “It has to be done today.” So now it still isn’t going to be done today, but its somehow my fault.
  • When a developer is working hard but not getting far, how do you notice? It’s actually quite tricky to know how productive a developer is. Some developers pile on the quick hacks, so it looks like they’re making lots of progress. On closer inspection, their code is full of bugs, and incredibly difficult to understand, debug or extend. If you don’t have design reviews, code reviews, and/or QA from the start, this can slip by until you think you’re almost ready to ship. Other developers keep up on the latest technologies, and are able to say “this is a known problem, let’s use X for it rather than inventing our own version of it.” But more directly, if you don’t have a detailed schedule, then you don’t know whether you’re behind schedule. So dig into it. When do they do QA? Who looks over the check ins? What about people who don’t just code up the first thing that comes to mind, but spend a little time looking for a better way?
  • Once you notice, what do you do?
  • Here are three developer personalities from a post on Reddit. I think they do a great job of describing personalities I’ve seen. What role, if any, would they have in your company?

    Coder: values velocity. Wants to “produce code” and “get things done.” They are proud of working hard, staying late, generating thousands of lines of code, and of knowing dozens of obscure APIs by heart because they type them in all the time. They’re great on anything that’s a clown fight of interacting APIs, like LAMP stacks or AJAX apps. However, they won’t produce a memory allocator that you’d want to use as anything but a prank.

    Programmer: values correctness. Wants to “solve problems” and “do it right.” They are proud of working efficiently, being caught up enough that they don’t have to stay late, and deleting code. They’re good at algorithmic code like a memory allocator.

    Researcher: values knowledge. Wants to “find problems” and “publish.” They are proud of producing new knowledge, and sharing it. They don’t stay late at all.

    Also, what do their career paths look like?

  • What’s the right level of pressure for your developers? In other words, should projects be slightly under staffed? Should deadlines be aggressive?
  • In practice, how many hours a week do people typically work? You can ask this near the end of the interview, although hopefully not as the last thing. Asking it earlier may make it seem like you care more about leaving on time then on getting the job done.
  • Can you give me an example of someone under you who has worked to improve their skills? For example learning new software, going to conferences, etc. What’s the right amount of time for someone to spend improving their skills?
  • Do you do anything to explicitly identify “best practices”? Do you adopt best practices from outside your company? Can you give me an example of a practice or two you’ve adopted? You want to see if they learn from their mistakes, and the mistakes of others.
  • What’s the best and worst thing about working at X? Both the best and worst are worth paying attention to.

For a tech lead, see the list of questions in my next post, about the in-person interview.

The big advantage of the reverse phone screen is that it’s quick. No one will miss you if you’re not at your desk for an hour, so you can do a lot of them. In-person interviews are half a day to a full day, so you have to take some PTO time for them. By doing reverse phone screens, you can consider many more companies than you normally would.

Posted in Brain Rental | 6 Comments

Finding A Job You’ll Love: Locating Opportunities

I’ve changed jobs a bunch of times over the last few years, and now I’ve found one I’m going to stick with for quite a while. So I thought I’d write up the tricks and tips I’ve learned for anyone in a similar situation.

The first thing to do is figure out what you want. You might think this is easy, or that you already know. But as I took job after job that seemed good then turned out bad, I realized that the stuff I thought was important wasn’t really important, and other things I wasn’t even considering were essential. I’ve noticed that, as people progress through their careers, they often start by focusing only on the technologies (“I want to work on cool stuff!”) and, over time, realize that compatibility with their boss and co-workers as more important.

So for every job you’ve had, write down a detailed list of everything you liked and didn’t like about it. Think back to every project you worked on, and every person you’ve worked with. What did you like about them? What did you dislike? Did you learn something new? When things didn’t work out, did your boss help or just put pressure on you? When you made suggestions, did your boss give you good reasons for not following them? Think about each of your co-workers. When did you enjoy interacting with them, and when was there friction?

I’ve come to realize that “process” is the only “must have” aspect of a job for me. I can’t be happy in a “get a lot of good people and set aggressive deadlines” place. I feel ownership of the project, not just my part but the whole thing. When I’m forced to create spaghetti code that is then full of bugs and takes forever to extend, when I’m forced to work crazy hours but can only produce shippable code very slowly because of the spaghetti, it bugs me. I take the failure personally.

Another thing I’ve learned is that job ads are almost useless. They tell you what technologies you’ll be working on, and they always say the company is great, but nothing about what your day to day work will be like. How much politics and bureaucracy? How much overtime? If you come up with a clever solution to a problem, will people be happy & let you implement it? Or will they give you blank looks and consider you weird?

Whether you prosper under a sane process, cutting edge work, or perks (massages and free snacks!), the job ad won’t tell you. Recruiters might help if you find a really good one that takes the time to understand what you’re looking for. They’re rare, but they’re out there.

So you might be tempted to do a shotgun approach: send your resume to every job that isn’t completely out of the question. But that’s a bad idea. The people reading your resume are sifting through hundreds of them for every open position. The way to stand out is to tailor your resume to them, and that takes time.

So in the end, the way I find positions is:

  • Talk to friends, see if they know of anything. If you don’t need to keep your search a secret, you can post on Linked In/Facebook/Twitter that you’re looking for a job and would like suggestions.
  • Look at lists of “best places to work,” such as the Boston Globe’s or the Boston Business Journal’s. Of course, they may have a different definition of “good place” than you do, but that’s ok, we’re just getting a list of candidates. We’ll look at all of them more closely soon.
  • Search and for jobs that look interesting. This won’t tell you about their culture, but you’ll filter for that later.
  • Work with a really good recruiter.

Before you send out any resumes, try to narrow down the list. Find the company on Linked In and see if you’re connected to anyone who works there. If so, chat with them on the phone. Ask:

What’s the best and worst thing about working at X? How many hours do people actually work per week? How much time is spent bug fixing? Does your boss have a technical background? How do you come up with schedules and release dates? How do you decide what to promise to customers and when?

and anything else that’s important to you. Also look for people who have left the company in the last few years and talk to them.

When sending out the resume, make sure you tailor it to the type of company. I usually have two resumes, one that emphasizes my machine learning/AI background, and another emphasizing my general programming skills. I also tailor each cover letter to the company. You’d be amazed how many cover letters are so generic that they don’t even mention the company’s name. If you mention the requirements from the job ad, you’ll set yourself apart. And you should also “connect the dots,” describing how things from your background relate to the requirements. Hiring managers have to sort through hundreds of resumes, so they’re really skimming each one, and may not see the connections you’ve seen. Your cover letter should be a “cheat sheet.”

When you send out your first resume, a clock starts ticking. If they like you, they’ll want a phone screen, then an in-person interview, then make you an offer, and want you to accept. If you try to delay it while you search for other opportunities, they’ll take that as lack of excitement and it may hurt your chances. So make sure you’ve found your list and narrowed it down as much as possible before you send out resumes or contact a recruiter. Then, send them to all companies on your list at the same time and contact recruiters that day.

Posted in Brain Rental | Leave a comment

Finding A Job You’ll Love: Recruiters

Ah recruiters. If you understand their motivations and find a good one, they can work wonders. But the average and bad ones can be worse than searching yourself.

When looking for a job, you should definitely search on your own through websites like and But you should also work with a recruiter. They can find jobs that you wouldn’t find, that aren’t even listed. And what’s more, they can help you understand how employers will view your resume, and when talking to companies they can help explain away any red flags. They can sometimes even give good career advice, if you know how to filter what they say.

The key to working with recruiters is to understand their motives. They’re middle men who are paid by commission, like used car salesmen and real estate agents. They’re paid by the company that hires you, and are paid 1 – 3 months of your salary, as far as I can tell in Boston.

You might think that, because their commission will go up if your starting salary goes up, they’ll negotiate a good one for you. But even if they negotiate a $5k/yr increase, they’ll only see ~ $1k of that. If they spend that time finding someone else a job, they’ll get a whole other commission, ~ $10k+.

So they try to close as many deals as possible and ignore the quality of each deal. To maximize their income, the bad ones will rush you into the first employer that will hire you. They also spend as little time on each deal as possible, and generally just do keyword matching: “This job requires XML, and you have XML on your resume, so it’s a match!”

The good ones will want to cultivate a long term relationship with both you and the companies they work for. But keep in mind, even good recruiters are generally non technical and don’t understand any of those acronyms. And both good and bad recruiters will only get you an offer from a single company, which really reduces your ability to negotiate.

Plus, each recruiter only represents a fraction of companies in your city. Google, for example, doesn’t work with any recruiters. So you always want to search on your own, even if you’re using a recruiter.

When you first talk to a recruiter, describe what you liked and didn’t like about past jobs. Then ask them for career advice: what sort of job do you think I’d enjoy? At what sort of company? What’s a possible career track for me for the next 10-20 years? Why? Listen to their thought process. The bad (including average) recruiters won’t have thought about such things, so they’ll say something generic. Treat them like another job web site: they’ll send you job ads and that’s about it.

How do you find a good recruiter? The best way is probably to ask your friends and co-workers. If you post your resume on job web sites, they’ll contact you, and you can try the test above to see if they’re any good.

In the end, the best strategy is to look for jobs yourself and work with a good recruiter. Just make sure that you do a thorough search on your own before you talk to a recruiter. One of the first thing’s they’ll ask you is what companies you’ve applied to. Once you give them that list, if you discover a company they work with, you need to go through them.

Posted in Brain Rental | 4 Comments

Reading The Fine Manual

I’m always amazed how long people spend trying to figure out software by fumbling around with it, rather than reading the manual. Now, I know what you’re thinking. You’re thinking “Golly Martin, reading manuals is all swell and good, but I’ve got to write code and fix bugs. If I spend an hour or two reading those manuals, well jeepers, by the end of it I won’t have written a single line of code, or fixed a single bug. Not one line! I don’t have time to read them, I need to get things done!”

Continue reading

Posted in Brain Rental, Process | 5 Comments

Introductory Books on Web Testing

Someone at work asked for introductory books on testing, that would help them test our web site. I think these are the best, and thought I’d have some fun with Amazon’s web widgets. Widgets

Posted in Brain Rental | Leave a comment

Concurrency ≠ Threads

Here’s a conversation I seem to be having over and over these days:

Someone else: Computers are getting more and more cores. So, we need to thread our software to take advantage of them.

Me: But threads (the Dijkstra style shared-state-with-locks-and-mutexes-and-semaphores-oh-my variety) are almost impossible to get right, and when they’re used in other than the simplest way, its easy to get random deadlocks that happen every few months/years.

Someone else: Computers are getting more and more cores, so we need threads.

Me: But there are other forms of concurrency. Processes that communicate using files, pipes, sockets, or even shared memory. Or software transactional memory (hell, people use databases for IPC now, so STM can only be better), or message passing.

Someone else: … ?

A few days later:

Someone else: Let’s talk about how to multi-thread our code.

Sorry people. As Sutter and Larus say:

“humans are quickly overwhelmed by concurrency and find it much more difficult to
reason about concurrent than sequential code. Even careful people miss possible interleavings among even simple collections of partially ordered operations.”

And as Edward A Lee says:

“[Threads] discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism.”

[Clever summary encouraging people to understand concurrency more closely.]

Posted in Random Thoughts | 19 Comments

Should you pursue your PhD?

“A PhD is a big, multi-year project. You really learn self-reliance, how to budget your time, and how to motivate yourself,” says Martin Martin, a senior software engineer with a PhD in robotics from Carnegie Mellon University.

From Should you pursue your PhD?, an article that includes a couple different paragraphs from yours truly.

Posted in Random Thoughts | Leave a comment