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?

  • 14
    I am going to take a wild guess and say that you interviewed at Google?
    – Pemdas
    Commented Feb 14, 2011 at 20:15
  • 2
    @ 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. Commented Feb 14, 2011 at 23:46
  • 3
    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
    Commented Feb 15, 2011 at 1:03
  • 3
    @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. Commented Feb 15, 2011 at 12:51
  • 1
    Scott:"if you just took 4 years of electrical engineering and you can't get that one right, the interview is over." I fear I may have flunked a couple of those because I laughed, or was insulted. I guess coming from the research environment you take basic competency for granted. Commented Feb 15, 2011 at 17:52

9 Answers 9


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.

  • 2
    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
    Commented Feb 14, 2011 at 20:39
  • 3
    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
    Commented Feb 14, 2011 at 20:41
  • 3
    Code to show is a trick -- how do you know that Joe Interviewee actually wrote that code short of making him actually write code? Commented Feb 14, 2011 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 Commented Mar 24, 2012 at 21:08
  • 1
    There's also very real fear on the part of technical managers in hiring truly smart and experienced professionals — those who might know something better than they do, hence may argue for and against a solution as opposed to just being code-writing robots. Ultimately, hiring someone who can reverse a linked list in a minute instead of hiring truly smart engineers is the loss of all those who make financial profit from the product. As Bjarne Stroustrup put it, "An organisation that treats its programmers as morons will soon have programmers that are willing and able to act like morons only." Commented Aug 11, 2017 at 22:03

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.


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?

  • 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? Commented Feb 19, 2011 at 1:24
  • 5
    @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
    Commented Feb 19, 2011 at 1:59

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.

  • 4
    +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. Commented Feb 14, 2011 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
    Commented Feb 15, 2011 at 8:07

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?

  • That's fair, but do you cast a fairly wide net when doing the technical component or focus on a given area?
    – rjzii
    Commented Feb 15, 2011 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
    Commented Feb 15, 2011 at 15:08
  • Why are virtual function questions so popular? It seems sometimes that's all one'd have to study...
    – Jé Queue
    Commented Feb 15, 2011 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
    Commented Feb 16, 2011 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 :)
    – Jé Queue
    Commented Feb 16, 2011 at 6:45

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.

  • 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.
    – rjzii
    Commented Feb 15, 2011 at 14:28

I am a software developer (c/c++) with over 20 years in the field. The type of interviews we routinely see now (the brain teasers, implementing data structures, search algorithms etc. on the whiteboard) didn't used to occur much except for newgrads. If a person worked for a reputable company for reasonable amount of time, that was considered proof of one's ability to write code. Now its become very schoolish and I'm not sure why. Really, the typical things they ask you to code, CAN be memorized so doing it on the whiteboard really does not prove anything. On a work project, you'd use the internet to research something and you would not be writing btrees or linked lists from scratch. What companies truely need now are innovators and asking someone to prove they can write from memory structures from college does not demonstrate innovation.

I think its another management fad - just like scrum - with this one probably being started by google, amazon and microsoft. Everyone else copied just like they did with Jack Welch's rank and yank...remember GE?

If you are a hiring manager reading my comments, what you SHOULD be asking candidates is HOW they would go about solving certain problems. Instead of asking them to code a hash table, give them a problem involving a hash table and ask how they would solve it.

I also agree with the developer above this post who said "give them a real world problem that the company had to solve"!

"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 also agree with the above. When you work for a company, you write code THEIR way. I still struggle sometimes to remember C++ call by reference syntax off the top of my head because the senior architect at the company I worked 15 years for, prefered to use pointers, not references. He was an old C programmer you see. So thats what we all used.


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.