Hacker News Reader

Comment by xianshou | Hacker News Reader

I've interviewed a lot of Ph.D. candidates for software engineering jobs at startups, and have only ever encountered two problems: (1) lack of ability to code, and (2) mismatched expectations.

Poor coding skill accounts for perhaps 80% of the industry no-hires. Well...that's not exactly fair. Poor coding skill under pressure. Most Ph.D. candidates are either out of practice or used to taking a long time to think about and solve a coding problem. That's great for academic software, but misaligns with both rapid development and (importantly for the candidates) the style of interviews. Most Ph.D.s wither under the expectation of producing a feature very quickly.

Some Ph.D. engineers can code extremely well. If they don't end up at the company, it's because the following dialogue happened, implicitly or explicitly:

PhD - Look, I'm great.

Company - Yes, you are. How about $X?

PhD - Given my specialized skill, I was expecting more like $1.5X.

Company - Well, $.8X is what we pay the new grads, so $X is what we'll pay you.

In other words, their ability is clear, but their market value isn't enhanced very much by their specialization, when most companies are looking for the skills that developers get during their bachelor's or master's.

View on HN

I am fed up to the back teeth with "speed" as a positive metric for coding.

> used to taking a long time to think about and solve a coding problem.

that's a good thing. A good friend of mine is a phd and lead programmer on a radio telescope project. my solution to a problem he described was quick to code and hellish to run, his involved maths I did not understand took five lines and ran super fast. he chose an algorithm that fit the problem domain better - because of more extensive training than I got.

Algorithms count massively. Google is built on an algorithm that fits the problem domain better. finding and applying better algorithms to give "unfair" competitive advantage is a very good thing

so I want to see a slow code movement like a slow food movement

- Producing higher quality software delivers more business value in the medium term than lower quality

- Iterating to a solution is often slower than applying the best algorithm directly

- it takes time to understand and evolve a story

- rewrites are a good thing. most books and film scripts are rewritten a lot

- daily status meetings encourage trying to do something each day instead of taking a week to make something fantastic

I see no problem here. If algorithms count massively, then those slow skillful algorithm coders can start their own companies, and because algorithms count massively surely soon the market will be full of companies that require algorithmic skills and don't value speedy hacks.

But just surprisingly, the market looks like it is full of those crappy startups, which value speed over quality, and don't do rewrites. Wonder why that is so.

Actually algorithms are kind of important.

How do you think it is that google is able to return your search results in a fraction of a second? And how is a game able to represent and efficiently display a massive 3D world?

I didn't claim that algorithms are not important. If you look at the market, there is a lot of demand for certain types of employees, while there is less demand for others. I think that the market represents pretty well what people actually demand.

The comment I replied to implies that demand is specified by the companies, not by customers. I guess you get that kind of attitude in university jobs, where money comes from goverment grants etc, not from customers.

It could be that we see many startups in "the market" because like flies they spawn and die quickly, but have few to nil influence on the world, while real big new things are few and last longer, and influence the world, and require higher skill levels. Think about it, between Instagram and Bitcoin, which will be influencing our world and our life more?

The problem is that for the vast majority of business applications there is no algorithmic innovation required. I mean, to build a basic CRUD app, you need no algorithms knowledge at all -- rough and ready experience will serve. Even for data processing, unless you're processing truly vast (e.g. terabytes to petabytes) amounts of data, the algorithms you learn in an undergraduate introduction to algorithms class will work just fine.

At this point, employers quite rationally want someone who can put together a combination of basic algorithms in 5 minutes over someone who takes a week to come up with an a elegant jewel of an algorithm that no one else at the company can understand. To put it another way, just like the slow food movement hasn't really made a dent in fast food culture, I don't expect a slow code movement to make much of a dent in the "ship yesterday" culture of modern software development.

People underestimate the difficulty of writing "boring" CRUD apps.

I remember the bad old days, before Ruby on Rails, when we were writing Perl cgi-scripts to connect to the database, or when 100% of the time I'd inherit a PHP application the people either: (I) had magic_quotes_on which caused everything to be FUBARed or (II) didn't consistently quote HTML in forms or in SQL, so you could easily bust forms by typing in a " or '.

Today the ideas in rails have spread to every other language, and it's better, but people still screw up database schemas every day.

Steve McConnell's book "Rapid Development" is really about efficient development, which, in the grand scheme of things, takes about 10-20% more time than truly "rapid" development where you consciously spend more to compress the schedule over efficient development.

Efficient development is a matter of getting things mostly right the first time rather than expensive "iterations" on a series of bad database schema designs when a system has customer data in it.

Frankly, I've never seen a software project fail because the developers were too careful. I see them fail all the time when people set an unrealistic schedule and run around like chickens with their heads cut off and wind up taking much longer than they would have taken if they'd really practiced project management and design and all the other things that the usual (failing) company fails to practice.

"Poor coding skill accounts for perhaps 80% of the industry no-hires. Well...that's not exactly fair. Poor coding skill under pressure."

I have a PhD, and by now I think it's safe to say that I'm a productive programmer, but it was hard to get (back) into the industry. I've experienced the bias against PhD-holding coders firsthand.

The interesting thing is that I've now also been on the interviewer side of this equation more than a few times, and I know that a lot of programmers have a huge inferiority complex that really gets revved up when they hear that a candidate has a PhD. I've seen the hiring bar shift dramatically higher for a candidate simply because interviewers on the loop knew about the advanced degree.

Given that most companies have virtually no interviewer training, and even fewer checks or balances on the attitudes and predispositions of their interviewers, I suspect that this latter problem is a far more parsimonious explanation for the hiring gap for PhDs than is the presumption that >80% of doctoral graduates can't write code.

Maybe you really are that bad, but if you honestly aren't then how horrible

> I suspect that this latter problem is a far more parsimonious explanation for the hiring gap for PhDs than is the presumption that >80% of doctoral graduates can't write code.

Combined with the terrible quality of candidates I've had apply, ">80% can't code" is probably valid over a random sample.

If you add in some confirmation bias you'd probably explain a lot. However, I'd also add that I'm not shocked at the idea there are a lot of people who are great at academic research but terrible production coders.

"Combined with the terrible quality of candidates I've had apply, '>80% can't code' is probably valid over a random sample."

The average applicant can't code, but that's true across the board. Yet there's a strong and systematic bias against people specifically with doctoral degrees. There's something else going on, and IMO, it isn't explained by chance.

"I'm not shocked at the idea there are a lot of people who are great at academic research but terrible production coders."

Why? Isn't this just a gentle way of saying that you have a bias?

There's no fundamental reason that you should expect that a PhD (especially in CS) would be less able to write code than any other randomly selected applicant. More likely is that most interviewers don't have any idea what goes on inside a PhD program, and bring some very weird, negative ideas to the interview room about what the degree implies.

> The average applicant can't code, but that's true across the board.

That's exactly what I said, and was the point I was making. Combine this with confirmation bias and you're likely to see the result we do.

> Why? Isn't this just a gentle way of saying that you have a bias?

Academic research and production code have different, conflicting, requirements. That there are people good at one rather than the other is not surprising. I know people who are fantastic researchers, but their code should never go into a production system. I know people who write beautiful code, but they'd never have something good enough for academia.

> There's no fundamental reason that you should expect that a PhD (especially in CS) would be less able to write code than any other randomly selected applicant.

A PhD versus a coder straight out of university, or a PhD versus someone who has 3 years experience writing production code?

"Academic research and production code have different, conflicting, requirements."

Have you ever actually produced any academic research code? Because my direct experience with the matter says that you're wrong. I've seen plenty of "academic projects" that had far wider distribution, bigger teams and more complexity than your average "production code" (most of which is never used by anyone).

"I know people who are fantastic researchers, but their code should never go into a production system. I know people who write beautiful code, but they'd never have something good enough for academia."

I know a great many people in industry who micro-optimize for beauty and who go off on architecture astronautic expeditions with no provocation, so what's your point? Are you generalizing to all academics? I can tell you for a fact that "academics" as a group don't care more or less about beautiful code than anyone else, and that research is just another kind of production system.

You pretty clearly have a bias that "academia" is this ivory tower place where nobody gets anything done, and that's a stereotype, not reality.

You seem to think I'm attacking all academics, I'm not. I've repeatedly said that people on both sides write bad code.

> Have you ever actually produced any academic research code?

Yes. I've also maintained other peoples academic research code.

> I've seen plenty of "academic projects" that had far wider distribution, bigger teams and more complexity than your average "production code" (most of which is never used by anyone).

And there are plenty of industrial projects with wider distribution and with bigger teams than a lot of academic projects.

> I know a great many people in industry who micro-optimize for beauty and who go off on architecture astronautic expeditions with no provocation, so what's your point?

There are bad people on both sides, and that being good at one side does not necessarily mean you're good at the other. I thought that was clear in my previous replies, but maybe not clear enough.

> You pretty clearly have a bias that "academia" is this ivory tower place where nobody gets anything done, and that's a stereotype, not reality.

Please quote me where I've said anything like that.

Your first reply to me was taking something I said and repeating my point back at me, to be honest it's just getting a bit tiring. So here's a change, I'm going to ask you this: Do you think that there are some people who are good researchers but bad coders?

As someone who interviewed PhDs in a prior life, and is now getting a PhD, this is an excellent summary of the situation in the CS realm.

I would add, though, that a lot of people in industry mistakenly believe that what the PhD provides is specialization. It is true that you end up with a specialized skill, but you also end up with the ability to ask important questions, cut through all the things you could do and decide what you should do, experience managing long-term projects, proposing work, managing people (undergrads, usually), and mentoring, just to name a few.

So to industry folks out there who get occupationally sucpicious when interviewing a PhD ("just to make sure, are you comfortable not continuing your current research?") try asking a few questions like, "besides your research topic, what do you think you've gotten out of the last 6 years that will help you at this job". Yeah that's a softball question for an interview, but it will help them show you all the other things besides some obscure academic topic that they've learned.

1.25x, let alone 1.5x for a PhD to write code seems a little high. Typically a PhD doesn't make you a better software engineer, so why pay more (other than its expected)? $1.5x for a PhD to solve hard problems your company needs solutions to and can't hand to a random new hire, on the other hand, is reasonable.

Perhaps they think they are getting hired to do the later and you are hiring them to do the former ?

Simple suggestion: Perhaps they heard that PhD's make 1.5X, and haven't yet realized that the PhD's making 1.5X are solving the hard problems, not working as code monkeys? Thus they assume that the degree simply merits 1.5X for the same work.

Possible, but I'd imagine unlikely. Why would a PhD apply for a code monkey job? Most don't do so intentionally, certainly they didn't get a PhD to become a code monkey. So if they are willingly doing so, they probably exhausted all alternative career options or think they have. In which case, while they may ask for more money, I don't think they would actually turn down the job if denied.

certainly they didn't get a PhD to become a code monkey

Well, what did they get it to become? I bet most of them don't even know. I know I contemplated a graduate degree, and if I had done it, it would have been for love of the material and love of learning, not because I knew precisely what I was going to do with it.

Well the whole problem with "knowing what you'll do with a PhD" is, if we knew how research was going to turn out, we wouldn't have to do it. A PhD is training to probe into the unknown, which means that the economic yields of research are, by definition, unknown, which means finding jobs for researchers at for-profit businesses is hard.

I get that. Which is exactly why it is feasible to me that a PhD might wind up applying for code monkey jobs.

Since it's a hard problem, it sounds like someone should write their PhD thesis on finding jobs for researchers at for-profit businesses.

I believe S. Brin and L. Page have locked that dissertation topic up.....but might take a while to submit.

No, a PhD is training to become an academic. It's reasonable to assume that a PhD has lowered themselves to work in industry because they couldn't get a post-doc. Whether that's true or not it starts out the interview on a bad footing. What if a guy walked into your company and said "I couldn't get a job at Google so I thought I'd try you schmucks"?

> " ... a PhD is training to become an academic."

Back in the day, so was doing an undergraduate degree. If you wanted a job in industry, that's what you did. University was for academic pursuits.

> "It's reasonable to assume that a PhD has lowered themselves to work in industry because they couldn't get a post-doc. Whether that's true or not it starts out the interview on a bad footing."

It's not reasonable to assume that at all. Last time I checked, the majority of PhDs leave academia after their degree (they don't want a post-doc - so don't even try). I do understand why non-PhDs in industry may harbour false impressions about the degree and why that can set things off on a bad footing.

> "What if a guy walked into your company and said 'I couldn't get a job at Google so I thought I'd try you schmucks'?"

This is completely independent of whether or not someone has a PhD. Undergrads can do this too.

Of course it is reasonable, or not unreasonable if you prefer. As in, a normal person would not be thought outlandish for thinking it, and particularly, it is actually perfectly normal for interviewers to think so.

It's reasonable to assume that a PhD has lowered themselves to work in industry because they couldn't get a post-doc.

Let's conduct a poll. Other than you, did anyone here who's been involved with PhD holders or grad-school and academia themselves actually think this? How many of us actual academicy types actually think it's "lowering oneself" to work in industry?

I don't. I do think that both academia and industry need to drop their utterly ridiculous notions of professional passion, because most people most of the time will never work on Their Life's Defining Passion when there are bills to pay, but industry can certainly come up with problems just as big, just as hard, and just as worthy as academia.

http://matt-welsh.blogspot.com/2010/11/why-im-leaving-harvar...

I'm getting mine so I have the toolkit and experience to solve a certain class of problems.

It's certainly something I could have taught myself over the years, but at the time and now it makes sense to me (i.e. sunk costs are irrelevant, only a little bit left to finish).

What a derogatory term: "code monkey"! Writing, maintaining and managing source code requires quite a bit of talent. It is not a trivial job. It is often also a very difficult job that most outsiders would be incapable of doing, not even to save themselves from drowning.

Thank you for saying this. I've seen this a few times now on HN and really bothers me.

It's common industry jargon in the US, tongue-in-cheek like so much other jargon, and widely used by people to describe even their own jobs. You're ascribing a sense of malice to something that carries none.

Yes, I'm well familiar with the term. I did not mean to imply it was intended maliciously (nor that it wasn't.) I simply think that it is easy to interpret it as a devaluation of skill. This reactive feeling may just be based on my personal experience, but I also know I'm not the only one.

It's not really derogatory. It's just self-humiliating humor that is pretty common in many professions.

self-deprecating

Here it is a literary device to succinctly contrast the highly specialized PhD to the most basic of all programming jobs. It is not intended to be derogatory; rather, simply to emphasize the contrast between the two roles/qualifications.

In general it falls into the same category as other colorful ways to reduce a role either for the purposes of humor or simplicity, such as 'keyboard warrior' or 'desk jockey'

"Typically a PhD doesn't make you a better software engineer, so why pay more (other than its expected)?"

I don't know if a PhD makes you a better writer of code, but it definitely makes you more determined, focused and unflappable person. (That's pretty much all it does, actually. Everything else is a stereotype.) These are all qualities that are worth buying in an actual engineer.

The problem here is that PhD's should not be applying for developer jobs. It's like a fluid mechanics expert applying for a job as a plumber.

Wrong analogy. Your analogy compares demands of a specialized non-intellectual profession (plumbing) that does not value general problem solving with abilities of someone who is purportedly good in general problem-solving in addition to possessing industry-specific expert knowledge (your fluid mechanics expert).

While here we are talking about a profession (software engineering) that does value general problem-solving ability except it also requires additional industry-specific expert knowledge.

"specialized non-intellectual profession (plumbing) that does not value general problem solving"

Haven't worked with any plumber I take it? A plumber does quite a bit of general problem solving.

Yes. So the distinction is more like abstract problem solving.

Your description of plumbing is so off that I don't know where to begin. I assume you have a similar conception about other "working class" professions?

My brother was "just" a welder and could look at the blueprints produced and approved by experienced architects and engineers and tell them exactly why their designs would fail under load and how to fix them on the fly without massive cost overruns.

I urge you to reconsider your preconceptions about people working in "non-intellectual" professions.

I'm very impressed by your brother's ability, and I believe that if he exercised it to its full extent, he would not be "just a welder" as you describe.

Well that's why I put it in quotation marks, to indicate that the description was a bit sarcastic. He worked as a welder for a good ten years (17-27) before going to college to get a degree in construction management. My main point is that people in the "trades" are often just as intellectual and capable as anyone else might be.

Reminds me of the classic joke:

A surgeon has a backed up sink, and he calls a plumber. The plumber comes, works for 15 minutes, fixes the drain, and gives the surgeon his bill.

"Six hundred dollars?!?," the surgeon exclaims. "For fifteen minutes? I'm a surgeon and even I don't make that kind of money!"

"Yeah," replies the plumber. "I didn't make that kind of money when I was a surgeon, either."

I will take a pay cut to do the research i want to do, and I would do for free otherwise.

This is great :)

That would be the same like saying that PhD's should not be applying for jobs that require typing, or touching a keyboard in any way. It would be like a fluid mechanics expert applying for a job as a secretary.

I think this analogy sums up the problem and the social dilemma it creates quite nicely. Who wants to hire someone who has past experience that pretty readily indicates they will not be interested in the work you are providing them.

You mentioned "poor coding skill under pressure". Did you assess that during interviews? Because in my experience, the pressure during an interview is not at all like the pressure while developing software. At an interview, you may have to come up with a solution in, say, half an hour. At work, you can usually sleep on a problem, and come back with a solution the next day, even if you are under pressure to ship a new feature. In other words, nothing like the pressure during an interview.

On the other hand, interview problems are often way easier.

Not necessarily easier, but definitely less ambiguous. To be honest, in terms of absolute difficulty, I'd say that interview problems have I had to implement quicksort. Only in interview problems have I had to create a new data structure to fit a problem. On the other hand, I've always been able to suss out the requirements for the solution in one or two questions in interviews. In real life, figuring out what the solution should even look like is often a process that takes at least a week.

Pressure is not doing fizbuzz at an interview its when the billing system you are in charge of has its first 5 mill month and the CTO nudges you and says "this had better be right other wise we are both out of a job"

Since, by definition, a PhD has faced down a committee that has the power to say "this had better be right otherwise you've wasted the past five years of your life", and has likely been on grant projects where their funding is similarly on the line, that suggests you should probably try to hire more PhDs, not fewer.

Two questions:

(1) From your observations, what is the rate of poor coding skills among PhD vs non-PhDs? (ie. the PhD may still be a partial signal for better (or worse?) ability.)

(2) A PhD has 4-6 years of experience over a "new grad"... so 0.8X vs 1.0X seems off to me too. Most companies I've spoken w/ allow each year of a PhD to account for 0.5-1.0 years of industry experience depending on the individual's skillsets and the job's responsibilities.

Fog Creek values a PhD at 1 year of experience. http://www.joelonsoftware.com/articles/Ladder.html

Which makes sense in their domain. If you look at the skills they actually care about: software development/programming, user interface design, managing software teams, software testing using scripting/programming tools, marketing software, selling software, system administration.

A PhD would (likely) only have done development-programming and testing -- and only (at best) about half-time, since so much of their other responsibilities are coursework, writing, teaching, etc.

Fog Creek will never be google, either.

Nor will the vast majority of companies writing software. Hence why PhDs can't get jobs. There are way more of them than companies that actually need their expertise.

I haven't known any CS phD with job finding issues, beyond the standard..."would I be bored to death doing this job or not."

Years of experience don't matter (IMO). I will pay you based on the value you bring. PhDs have demonstrated the ability to read the literature and conduct research under supervision. That is not necessarily very valuable (knowledge gained during that process may or may not be very valuable). And, honestly, the research often seems very mickey-mouse compared to real world problems, of the "assume a spherical cow in a vacuum" variety. That's nice, but does it get me to launch with the feature sets I need? If not, your value is not high. If so, well, name your price.

I think you're heavily discounting/missing "ability to work independently" which I think is a huge win for most softeng jobs. If they can code (if), you'll find PhD holders need very little hand-holding to get stuff done.

>I think you're heavily discounting "ability to work independently"

Really? I mean, anecdotal evidence and all, but I haven't found that PhDs can actually work more independently in a commercial software setting than non-PhDs. I think it's because academic settings are just too different from commercial settings. In academia, your project is your own. You're responsible for it, from start to finish. But in commercial software, your project is often just one component or subcomponent of a much larger system. This requires a much greater level of communication and cooperation with other developers and business-people. So yes, a PhD may be able to work more independently on a project that allows for independent work. But most commercial software development is a highly cooperative activity, where the sort of independence that PhD holders exercise can often turn into being a loose cannon.

So take your 20 man project - all of it - and give the entirety to the Ph.D. In fact, since you'll be saving so much money, get three Ph.D.s to work on it simultaneously and independently. In fact, tell them it's first to publish - sorry, I mean launch - and you'll probably see them work 24/7 until it's done. In fact, what you've just done is start an industry funded research project. You should now go to a university, "collaborate" such that they get to put their name on the project, and you get to harvest their Ph.D. candidates for minimum wage, and you're laughing all the way to the bank!

In this case, supply and demand wins and everyone is happy. If you value a phd at N and another company values him (or her) at 2N, they will go work at the other company. If they have expertise that you can't leverage, your lower valuation is justified.

Also, it is hard to value PhDs if you aren't one yourself; e.g. it took Page, Brin, and Schmidt to figure put how to leverage PhD talent to build what was basically a new industry. Other people would see PhDs as seeming "very Mickey-mouse compared to real world problems." They wouldn't have the creativity and experience to see the connections.

From my experience I would NOT call PhDs coding skills as poor. It is just that the coding style is so different. And tend to go toward extremes. From ad-hoc approaches to the extremes of elaborations that attempt to solve every possible future problem. Sometimes without common sense, laziness and foresight of just a regular engineer.

There are reasons for that. It's just that the research grade code IS different. And labs tend to have their own cultures and approaches. Sometimes to the extreme of writing in their own languages. But in some cases it can be very advantageous.

> From ad-hoc approaches to the extremes of elaborations that attempt to solve every possible future problem.

If you're writing code that needs to be maintained (i.e. not just run a few times to generate results for a paper, but read and written by several different people over time) this is pretty bad and leads to much more technical debt than would otherwise be accumulated.

This is the type of thing you learn to avoid by working in industry a few years and is why experienced ICs are paid more than new grads.

IC? What's that mean?

Individual Contributor (as opposed to manager).

My group just hired a C.S. Ph.D. to write code.

Her coding skills were fine, but lacked some things very common in industry experience, like relational databases, Object Relational Mapping frameworks, distributed version control systems, and continuous integration tools.

None of this has been a problem. She has only been on our team a couple of weeks, but there was no delay to her being able to contribute to our code base relative to any other developers we have hired.

Well the other side of the equation also must be true. You should not be interviewing a PhD candidate unless you think you need one for that job. Else if you are interviewing a PhD even though a regular programmer would do, its not fair to the candidate. There in lies the main problem. The expectations are high for both parties involved. Also by definition they are already way too specialized and steering away from that specialization would be tough for a PhD as well.

"You should not be interviewing a PhD candidate unless you think you need one for that job."

Consider we produce twice as many PHDs as the business sector requires. This is probably accurate. From a humane perspective, what should we do with half the grads, soylent green seems a little harsh... The social perspective is they should just sit on an ice floe as it floats away in the ocean, which seems wrong.

We're moving toward a class based neo-feudalist system. The first time around with feudalism, the bottom of the barrel of knights and barons and such got wiped out in more or less continuous low-level warfare. In our new neofeudal era we don't have a solution for the bottom of the barrel of our various classes of titled nobility, leading to all kinds of angst.

To mix some metaphors it seems a waste of talent and economic costs to euthanize the bottom half of the modern Baronry after all that education and accomplishment.

Although it would screw around with modern feudalistic class based ideas, maybe we should be able to arbitrarily officially reject titles of nobility. Better to have a lower 50%-ile PHD writing CRUD apps as a code monkey than turn them into hamburger.

The main problem with Ph.D. degrees (from US and world) is that they sometimes really poorly equip you for a job in our field. I don't think coding is really what is missing - it is just misalignment (lagging?) of the curriculum and projects with fast changing pace of the industry. They are a little behind...

That PhD-Industry Gap is more about the hiring managers' disconnects between Science and technical techniques such as ability to code etc. It's just as ridiculous to request a linguistic scientist to be fluent in multiple foreign languages. I guess even Jeff Dean might have problem dealing with today's coding interview questions of regular software engineering jobs (or not, according to Jeff Dean facts). Those kind of hiring managers just do not have visions and would just miss the potentials of solving pioneering questions such as BigTable and MapReduce.

Accurate, except it's not hiring managers who are making that miscalculation.

By and large, hiring managers will see a PhD and be like "yay, give them an interview." Its the interview with an engineer where things break apart, because the engineer expects a PhD to be solving things the same way he would despite coming from totally different backgrounds.

(This is born out in the OP's experience, as he got many interviews but few offers.)

For once, hiring managers aren't to blame.

Same thing goes here in hardware industry. Having Ph.D. does not indicate how good they are. It really depends on individuals and their mindsets. Ph.D. with specialized major anyway have learn things over at new workplace. So whoever catch up fast and do hard with 'i will contribute this' attitude makes better results.

Someone may argue about this but people with less advanced degree tend to obey more to management.

Reply on news.ycombinator.com