Take the 2-minute tour ×

First, some background on me. I have a PhD in CS and have had jobs both as a software engineer and as an R&D research scientist, both at Very Large Corporations You Know Very Well. I recently changed jobs and interviewed for both types of positions (as I have done in the past).

My observation: SW engineer job interviews are way, way disproportionately more difficult than CS researcher job interviews, but the researcher job is higher paying, more competitive, more rewarding, more interesting, and has a higher upside.

Here's a typical interview loop for researcher:

  • Phone interview to see if my research is in alignment with the lab's research
  • In-person: give presentation on my recent research for one hour (which represents maybe 9 month's worth of work) and answer questions from the audience
  • In-person one-on-one interviews with about 5 researchers, where they ask me very reasonable questions on my work/publications/patents, including: technical questions, where my work fits into related work, and how I can extend my work to new areas

Here's a typical interview loop for SW engineer:

  • Phone interview where I'm asked algorithm questions and maybe do some coding. Pretty standard.
  • In-person interviews at the whiteboard where they drill the F*** out of you on esoteric C++ minutia (e.g. how does a polymorphic virtual function call work), algorithms (make all-pairs-shortest-path algorithm work for 1B vertices), system design (design a database load balancer), etc. This goes on for six or seven interviews. Ridiculous.

Why would anyone be willing to put up with this? What is the point of asking about C++ trivia or writing code to prove yourself? Why not make the SE interview more like the researcher interview where you give a talk about what you've done?

How are technical job interviews for other fields, like physics, chemistry, civil engineering, mechanical engineering?

share|improve this question
I am going to take a wild guess and say that you interviewed at Google? –  Pemdas Feb 14 '11 at 20:15
Are you on twitter? –  P.Brian.Mackey Feb 14 '11 at 20:17
@ Ethel: If you look on glassdoor.com, where people post their salaries anonymously, you can see that a researcher position pays about $10K to $20K/year more than a comparable SW engineer (same location, same field). Anecdotally, I know my salary is about $25K/year more than my other friends who graduated with a CS M.S. degree from my grad school at about the same time. And it's not just the salary; I've seen that PhDs have higher career trajectories than those without. I do not have direct evidence, but I've seen that PhDs are more easily hired into CTO/VP levels. –  stackoverflowuser2010 Feb 14 '11 at 23:46
It's crazy, but apparently doesn't extend to the 'real' engineering professions. I know a ton of civil engineers and they're shocked at what I've told them about some of my past interviews... many have said just what you did: "why would you put up with that?" –  red-dirt Feb 15 '11 at 1:03
@el fuser - It depends on the employer. The electrical engineering interviews I've had all either ask me to look at PLC code, write PLC code, and/or do something with electrical diagrams. On one, the first question was, "What is ohm's law?" It was the equivalent of the fizzbuzz test... if you just took 4 years of electrical engineering and you can't get that one right, the interview is over. –  Scott Whitlock Feb 15 '11 at 12:51
show 7 more comments

8 Answers

up vote 35 down vote accepted

It is relatively easy to establish if you are technically competent enough to do the research -- you've got publications the hiring managers can read and those publications probably hint at other folks they can talk with to check you out.

Software engineering, on the other hand, is a discipline so packed with incompetent wastes of space one needs to do plenty of due diligence making sure that the guy you are hiring can in fact write the code you are planning to hire him to write.

share|improve this answer
fortunately things like github and bitbucket are making it easier to see what that person has done. it can alleviate (or greatly reduce) the need to ask the due-diligence questions. –  helloandre Feb 14 '11 at 20:39
exactly on point. it's very hard to separate the good from the wannabe programmers. even with code to show, it would take a lot of time to read and understand it to the level of being able to judge the author. research papers, OTOH, are written for readers, it takes just a few hours at most to really understand one, usually a bad one is recognizable in a few minutes. –  Javier Feb 14 '11 at 20:41
Code to show is a trick -- how do you know that Joe Interviewee actually wrote that code short of making him actually write code? –  Wyatt Barnett Feb 14 '11 at 20:55
I've got an article published, and a book on the way. Usually the technical screens get short-circuited because my knowledge is well documented, they want to make sure that I am that Mike Brown –  Mike Brown Mar 24 '12 at 21:08
add comment

Going out on a limb here.

As a researcher with a PhD, you have already proven to multiple recognized organizations your value and minimum qualities as a researcher. You successfully defended a thesis in front of a board of your peers and have convinced at least one peer reviewed publication to publish your work.

Software development, on the other hand, has no qualification standards. People routinely over inflate their knowledge base. As a result, software development interviews have to do all the work that PhD defense and peer review do in academia. They make you prove that you really do know what you are talking about.

share|improve this answer
add comment

Consider this for a moment.

If I tried to apply for this CS researcher job I wouldn't get my CV/Resume looked at. I wouldn't get to an interview in the first place. I'd get a standardized "no advanced degree" letter telling me that I wasn't even qualified to have my CV looked at.

My questions are these: "Why is it so hard to get a PhD?" And "Why do I need a PhD to be CS researcher?" "Why so many barriers and hurdles?"

Why would anyone be willing to put up with this?

What is the point of doing all that course work and getting research printed in journals and conferences? Why can't I just do the research and get paid more than I do for engineering?

Why rely on graduate schools and publications to establish credentials? Why not make the research interview more like the SE interviews where everything depends on what you can recall right now during the interview?

share|improve this answer
I kind of get what you're saying. The right kind of interview should fit the right kind of job? Is that a correct interpretation? –  stackoverflowuser2010 Feb 19 '11 at 1:24
@stackoverflowuser2010: No. I'm simply complaining that the academic world is far, far harder to break into than the software engineering world. You got an interview as an SE. I could not even get in the door in academia. Your perspective is so badly skewed you're not seeing the differences. Academia is much, much tougher. –  S.Lott Feb 19 '11 at 1:59
add comment

Well, I have a theory. Research is typically paid for by grants, so the supply of cash is high. They have a bucket of money to spend, and they just need to find someone to spend it on. Whether you actually accomplish anything in that position or not, the company/institution doesn't log a net loss because it was just an accounted-for expense anyway. There's little risk in hiring the wrong person. The worst case scenario is that they throw away everything you did.

On the other hand, the success or failure of existing products rests on the shoulders of day-to-day developers. Particularly if you're in product development, you're a profit center for the company. Good or bad developers have a huge impact that's way beyond the cost of their salary. A bad developer actually causes damage. They can set back a team, product launch, etc. The consequences of hiring a bad SW engineer are much higher.

share|improve this answer
+1 In fact, cash spent on research is justified by published papers, so if a candidate has a good list of those from the past, chances are (s)he can produce some more, which will most likely satisfy anyone who happens to be checking what the research grant was spent on. –  Péter Török Feb 14 '11 at 20:50
@Péter Török: Yes!!! Funds that give grants then require to file a report and the key thing they look at is the number of published papers. –  sharptooth Feb 15 '11 at 8:07
add comment

Our company also "asks lots of hard questions" and I'll explain why. We do care whether you really know how a virtual function call is done, but not because it is so critically required for the job you'll be doing.

Instead we do care because we need to know how fast you can learn fundamental stuff. You claim X years of experience? Okay, we'll ask hard questions to find whether you've got solid knowledge.

You don't know how a virtual function call is made under the hood, but know everything about profiling and optimizing? Great, we likely hire you - you've gained solid knowledge in one field and so you'll surely gain solid knowledge in another.

You claim X years of experience "developing, debugging and fixing C++ code" and can't explain in plain words how a pointer points to an object? Sorry, we can't hire you - if you can't do that how will you explain harder problems when we need to make complex technical decisions?

share|improve this answer
That's fair, but do you cast a fairly wide net when doing the technical component or focus on a given area? –  rob Feb 15 '11 at 15:06
@Rob Z: We try to ask very simple questions about C++ - mostly about pointers and recursion, we provide snippets that are about five lines of well-formatted code and ask for details on what and how they do. Surely we don't ever ask about multiple virtual inheritance and order of base classes initialization in case of virtual inheritance. –  sharptooth Feb 15 '11 at 15:08
Why are virtual function questions so popular? It seems sometimes that's all one'd have to study... –  Xepoch Feb 15 '11 at 20:01
@Xepoch: I guess because they are very simple and knowledge of their inner working indicates well whether you care what happens inside or just paste lines of code together. –  sharptooth Feb 16 '11 at 5:32
I think I've had luck in my career. Rarely have I ever seen a cut & paste coder. I've known bad practice coders (myself included), but at least it was of their own design :) –  Xepoch Feb 16 '11 at 6:45
add comment

Short answer: there are plenty of people on the market who claim to know programming, but cannot program.

Side remark: I am surprized that no-one posted a link to FizzBuzz essay.

share|improve this answer
True, but there you can tell pretty quickly if someone can or cannot program on the basis of a whiteboard problem or two. Whiteboard problems aren't quite the same as asking the various textbook questions that come up during some interviews. –  rob Feb 15 '11 at 14:28
add comment

I'm going to take a different route and say that the problem may not be so much that the software engineering interviews are inherently harder, but rather that different sectors are looking for different things which shows in their interviewing style.

I've interviewed across a fairly wide range of sectors (e.g. start-up company, small company, large company, internal IT department, software company, research organization) and they all have a different way of interviewing that I have found usually tends to follow the following pattern:

  • Start-ups tend to be concerned with knowing that you can start writing code right now and can handle a fast paced environment. As such, they tend to be concerned with how much you know off the top of your head as they seemingly don't want to see you spending a lot of time looking up whatever they deem to be "core" knowledge. Admitting you don't know something may not be such a good thing in this environment if it is something they expect you know.
  • Small companies tend to look for the same things as start-ups in regards to how much you know, but aren't as concerned with how well you handle fast paced environments (depends upon the job) and more with what sort of soft skills you bring and how well you will fit in wit the company.
  • Large companies and internal IT departments seem to be more concerned with ensuring that you have a given standard of technical knowledge, but aren't as concerned if you don't know everything off the top of your head since they anticipate that there will be some time involved with getting you trained up on what the company expects. Thus, this is an environment where admitting you don't know something but are willing to learn and study can be seen as a benefit.
  • In the research environment (i.e. software development support for scientists in my experience) they tend to be concerned with if you can write software, but more so if you are willing to do what is needed to ensure that you can learn what they are doing so they don't have to hold your hand while you are trying to solve a problem. Since it is also a research environment, they also seem interested in how interested you are in learning new things.

Now, I neglected to mention software companies (i.e. Google, Microsoft) as they tend to do their own things and depending upon how mature the company is and what group you are interviewing for, they are looking for different things.

At the end of the day though and as with most things in life, it all depends. Personally I have found that some companies focus very much on the "book knowledge" which might come at the expense of being able to actually solve the higher level problems where as other companies appear to be very concerned with how well you handle the higher level problems (i.e. can you design a schema for x) and operate under the assumption that they are willing to invest three to six months to get you fully up to speed before you will be fully productive.

share|improve this answer
add comment

Again, tech interviewing is arbitrary and capricious.

There's a big difference between grilling a person on the minutiae vs seeing if they know their CS. Like I said above, I have over a decade of experience with C++, but I'd tend to bomb the OOP/Inheritance questions. Why? Because once support for templates was added, I've used C++ almost exclusively for Generic Programming.

I've interviewed with several BigHouseHoldNameTech companies in the Bay area & Seattle, and one of the best interviews involved real questions that they've had to deal with on the job, involving data structures and algorithms [i.e.: You have 300 billion data points consisting of XYZ. How do you efficiently store & search?].

That pretty much lets you know how a candidate could step in and help solve the real problems you're facing. The absolute worse was also with another BigHouseHoldNameTech company, but they asked hours worth of incredibly arcane questions that you really ought to just look up in a manual [i.e. describe the main differences between the PCB in windows vs. Linux --and this wasn't for a kernel level position]

Hedge funds are the bizarre with their intent to torture... expect 8 hours of solving knapsack type problems on a whiteboard.

share|improve this answer
add comment

Your Answer


