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.
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
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.
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.
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?
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.
"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.
> 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.
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"?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
(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.
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.
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.
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.
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.
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.
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.)
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.
Wow, a lot of harsh criticism for Ph.D's on here! I can't speak much for a graduate degree in computer science (I don't know anything about it), but at least in my field - chemical engineering - there are many jobs that absolutely require a Ph.D. When I was an undergrad, I was dismayed by the number of "Ph.D. required" comments I saw on Intel's job listings for anything involving original processor design (only a BS was necessary for being a fab engineer).
A BS in chemical engineering basically qualifies you to be a process engineer. Sure, you can get a R&D job, but it's going to be a lot harder than if you have Ph.D. And there's plenty of research jobs out there; it's basically the impetus for a company's success over its competition (again, the science-y industries). There's certain tasks I would not consider hiring anyone for unless they either had a Ph.D. or had somehow independently demonstrated the capability for novel, unique research and problem solving skills.
I know the article was about CS, but the title was "Ph.D. - Industry Gap" and there's many fields out there where I feel like a Ph.D. is almost essential for particular jobs in those fields.
There are some areas of CS that are more along those lines. They're less common in the industries represented on HN, though.
One example that comes to mind is graphics: places like Pixar and ILM heavily hire PhDs for R&D work, developing rendering algorithms and infrastructure and the like. They do also hire non-PhDs, but without some equivalent research track record (e.g. a SIGGRAPH paper or two), usually not for R&D jobs.
I hadn't actually counted before, but if you go to http://graphics.pixar.com/research/people.html and look at the bios, 9 out of the 11 have a PhD, and there are more outside the formal research division.
By and large, comparing chemical engineering to software development is misguided. Software development isn't an engineering field, i.e. the application of a refined theoretical framework to a concrete problem. It's more like carpentry. There's a few basic theoretical principles, but by and large it's just building things. You can spend a lifetime becoming an expert carpenter, and that can be very valuable, but nobody gets a PhD in carpentry because by and large there's not much there that's theoretically interesting.
There are many areas that are theoretically rigorous, of course. Machine-learning/AI, crypto/security, graphics, audio, video, etc, and unsurprisingly a PhD is quite valuable for programmers in those fields.
Computer Science has a solid axiomatic foundation in the lambda calculus. Specific areas have their own foundational framework. For example, the relational algebra is an algebraic structure solidly vested in the Zermelo-Fraenckel set theory. So, in terms of math and science there are very solid theoretical principles. Computer Science is fundamentally and undisputedly a branch of mathematics. The fact that it can be practically applied, and very well so, does not detract from its roots and origin. This may sound hard for other academic disciplines, but it is not because it is also useful that it is no longer science.
I didn't say computer science wasn't scientific, I said software engineering isn't an application of scientific principles. Software engineering mostly isn't a practical application of computer science.
To use the example posed above: you cannot be designing chemical processes without a solid grasp of the theory. You cannot do your day to day job without applying the theoretical concepts of the field to daily problems. That's what makes a PhD valuable in that field.
In contrast, many software engineers have no idea about lambda calculus, set theory, type theory, etc. You can build a lot of software with just the crudest theoretical understanding that you can pick up from hacking on software. That's why I likened it to carpentry. A carpenter will have a crude theoretical understanding about wood, it's grain patterns and how it absorbs stains, etc, but he doesn't need a solid foundation in the science to effectively do his job.
There's a lot of (understandable given the user base) bias in HN towards startups and the software industry, where you don't exactly need a PhD to crank out the next social media app or whatever. Therefore people will emit opinions based on their experiences, which might explain the negativity that you perceive. However, as you point out, in pretty much any other field of engineering, PhD hires are a most if you are pushing the frontier and producing genuine research.
At my little biotech/bioinformatics startup (this was 13 years ago), pretty much everyone had a PhD. What made us somewhat different was that only a few of us had done any postdoctoral work.
I think CS as a field has theoretical problems at its foundations that chemical engineering doesn't have. This makes a PhD in CS worth less to business than it otherwise would be.
Obviously I don't expect this to be a wildly popular sentiment...
I have a phd in computer science that doesn't involve much theory. Pure theoreticians exist, but they are quite rare. If your company doesn't have hard problems to solve, it doesn't need phds.
Anyone who can solve hard theoretical
problems can pick up a Ph.D. quickly.
Why? Because the main requirement for
a Ph.D. is just the research. Commonly
there is no coursework requirement.
For the research, the main requirement is
that it be publishable, and there the main
criteria are "new, correct, and significant".
It's a grim, nearly bloody, literally life
threatening fact of life, that doing such
research is really tough and the main
challenge of a Ph.D. The Ph.D. training is
supposed to help people do such research, and
it does. Still the research is tough. Without
the Ph.D. training, such research is much more
difficult.
Net, the idea that a Ph.D. is not needed for
good research can be true only for really
rare exceptions. Again, getting a Ph.D.
is tough, yes, life threatening, and the main challenge is just
the research.
Broadly there's another option: Now
the richest area of the US is likely
within 100 miles of the Washington
Monument in DC. Why? Because the
US Federal Government has a license
to print money - literally! Simple.
My career started there,
and that area just loves technical
Ph.D. holders. I failed to understand
just how much that area loves such
Ph.D. holders and should not have
left.
You can apply to US Civil Service
and/or individual parts of the Federal
Government or to the huge number
of private companies that do work
for the Federal Government.
The Washington Post used to be
a fast way to get job ads, send
a few resume copies, go on seven
interviews, and get five offers
(I did that once). Some routine
Google searching should get you
a lot of names and addresses, and
sending 100 resumes should get
you some good offers.
Your first paragraph is a bit too simplistic. There are still political issues (institutional political issues) that impede otherwise good researchers (and some, many even, dropout--there's a reason that "ABD" exists as an abbreviation, and it isn't because PhDs needed a quick and handy shorthand to cast aspersions) from getting the degree itself.
Doing the research necessary to write a dissertation really isn't that tough for somebody who is bright enough to tackle the problem. Its navigating the waters of academic politics and knowing the right people to be able to get into a research program that fits one's skills that is the toughest part. If this seems like it's familiar, it should be: academia has as much political and networking based "merit" as any place else. It just manifests differently there.
Sure, your point that a Ph.D. program
can be a political mud hole is correct.
For your
> get into a research program that fits one's skills that is the toughest part.
I didn't bother with that and, instead,
picked my own problem, did my own
research, and submitted my results.
My professors had very little idea
what I was doing until I was done
and submitted my work. Net, my
"research program" was mine. Maybe
in some fields, e.g., cell biology,
can't do what I did and your description
is correct.
But if pick a good school, then what
I said is simple but correct. E.g.,
Johns Hopkins, where I got my Ph.D.,
then, and maybe still, has no official
coursework requirement for a Ph.D. The
official requirement for a dissertation
was, and maybe still is,
"an original contribution to knowledge
worthy of publication". If there is
any doubt, then the student can just
submit the work for publication.
In my case, I took a problem I noticed
in a course, did a pass by the library
to confirm that there was no solution
in the literature,
worked up a rough solution, asked for
a 'reading course' to attack the problem,
got the course approved, and right away
showed my rough solution. Two weeks
later I had a nice, clean, solid solution.
I walked my original work around campus
to some world famous guys, and they
saw my work as new. So my work
was clearly publishable.
So, in two weeks I'd met the official
requirement for a dissertation. My
work was not trivial: I found a
new result comparable with the classic
Whitney extension theorem and applied
my result to solve the problem I'd
started with but noticed that my work
also solved a problem stated but not
solved in a famous paper by Arrow,
Hurwicz, and Uzawa. Poor Uzawa may
still have not gotten his Nobel prize!
I didn't try to use that work as my
dissertation, but the reading course
credit filled out what I needed for
a Master's. Also my research in that
reading course put a halo on my
head so that a Ph.D. was much more
likely. Let me emphasize again, the
key is in one word, research.
For my dissertation, I
took a problem I'd brought to graduate
school, done the research on it
independently in my first summer,
got the work approved as my dissertation,
wrote and ran some illustrative software,
wrote up my work,
stood for an oral exam, and got my
Ph.D. For the work of the reading
course, I published that later
in a good journal.
In most good research universities,
a student who passes the qualifying
exams and has some good, publishable
work will have to do something really
strange not to get a Ph.D.
Some good research can make the
political mud wrestling
disappear quickly.
The main reason for ABD is the challenge
of doing some research that is publishable,
"new, correct, and significant". If there
is any doubt about the quality of the work,
then just publish it.
The definition of a good algorithm is
from J. Edmonds. He was a graduate student
at U. Maryland, told the faculty to stuff it,
went to NBS, did some research on graph theory,
published it, and got a visit from U. Maryland
saying that if he would take copies of his
papers, put them in a stack, put a staple in a corner,
and submit that as his dissertation, then he'd
get his Ph.D. Again, the point is the research.
The mud wrestling is nonsense easily wiped away
by some good research.
My wife and I lived in Laurel, maybe 30
miles away. Likely the whole area within
100 miles of the Washington Monument is
much more highly built up now than then.
I suspect that now Laurel is a bit expensive,
and the traffic from there to the Homewood
campus is
likely too much for a daily commute.
When my wife and I were at Hopkins, there
was some nice graduate student housing
just east of campus, and I'd look into
that.
For the
neighborhood of the medical school
campus,
maybe it's okay, but I'd
check to be sure.
"Anyone who can solve hard theoretical problems can pick up a Ph.D. quickly. Why? Because the main requirement for a Ph.D. is just the research. Commonly there is no coursework requirement."
0_o What Ph.D. program has no course requirements?
> 0_o What Ph.D. program has no course requirements?
When I got my Ph.D. at Johns Hopkins, the official
statement was that there were no coursework requirements
for a Ph.D.
At times the math department at Princeton has stated
on their Web site that graduate students are expected
to prepare for the qualifying exams on their own, that
courses are introductions to
research fields by experts in those fields, and
no courses are offered for preparation for the
qualifying exams. So, with no courses, pass the
qualifying exams, do some research, and graduate.
How to do the research? If some of the courses
help, fine. Still the main requirement is the
research, just the research. It's all about the
research. Can cover the main requirement in
one word -- research. Did I mention that the
main point is the research?
Sure, in high school and college, academic
success is almost entirely about just courses,
credits, and grades. For a Ph.D. at a good
research university, the emphasis is elsewhere --
did I mention research?
Unnecessarily repetitive annoying response is unnecessarily repetitive. And annoying. Did I mention that it was unnecessarily repetitive? And also annoying? Because it totally is both unnecessarily repetitive and annoying.
I suspect there are more projects than this. The way it works is you like a particular lab, you contact their PI, agree on a topic, and work on it for 3-4 years. In Cambridge (where I work), the university enrols all research students in a "Research Skills" course/workshop, but that is it.
If they believe you are not up to snuff, you might be asked to complete an MPhil/MRes course first which does have a taught component. Apparently, if you fail this part, and in some circles, you will be seen as a PhD failure. Apparently.
PhDs are adept at solving hard problems, which is why google hires so many of them. You can develop these research skills without getting a PhD, but experience at many companies only really trains up code monkeys.
This, if true at all, is a very unique characteristic of the software industry. In pretty much any other place, you need advanced degrees if you are doing new and genuine research
It's more the fuzziness of terms like "hard problem" that is causing confusion.
The way I would put it, the things that CS PhD's typically end up working on in industry, are usually things that would require a CS PhD. E.g. almost all the cool computer vision stuff you see on HN is developed by people with PhD's or PhD students.
Every successful, real-life application required solving at least one really hard problem. This hard problem may only look like 1% of the application, but if it does not get solved, the application would have failed. That 1% requires you to build something of a similar level of difficulty as rolling your own relational database system. At least one guy has to be able to recognize the problem and to solve it. Otherwise, the other ones won't be able to build, support and maintain the remaining 99% and won't have a job at all.
The article is hard to read because it feels like this guy is really fooling himself.
If he were as good in academia as his rhetoric claims (building software that "revolutionized" a field) he should have no problems. He should not even need a job, as he ought to be able to just start something. He should have no shortage of strong ideas about what he could be doing.
Instead he is aimlessly searching for a job.
So, I have no choice but to disbelieve his rhetoric. He probably isn't particularly good at anything, and just stumbled through the PhD system. Well, surprise, that isn't worth much!
So go find his academic webpage and check if he actually did receive a research award from Stanford's CS department as a PhD student.
All his external awards point to someone who very probably can do any tech job the industry could throw at him, in contrast to the usual developer who just has a self-generated github profile and "Ruby ninja rockstar" on his resume.
Well not everyone wants to "start something". Starting a business is risky and requires tremendous dedication. Some people work better in technical/supporting roles. Perhaps after years getting paid peanuts in grad school, he wants something more stable?
Indeed, and who says this guy has the management and commercial skills to be able to pull it off? As I think many people here know, starting a business is way more than just the concept & application.
Very few programs will throw you out on the street. I've heard of a few people that got their PhD's eventually for passing go enough times. It happens.
They don't throw you out on the street - they just cut your funding or string you along.
One story I heard about a physics PhD candidate at UCSB (this isn't me, I wasn't in the physics department). A MechE prof he worked with stole his research and got a tenure track offer at another school, leaving him behind. He was living in his car for a while and was a paintball aficionado. One day he happened to pull up outside KITP just when some of the more senior professors were walking by. He, in a disheveled state, opened the car door and mounds of paintball ammo spilled out. Looks were exchanged, emails were sent and phone calls were made, and he was PNGed from the campus soon after.
Academia doesn't teach you how to fight for yourself in the world. The eventual injustices (observed on the scale of many years) are brutal, but the feedback cycle is so delayed that the judgment-of-character skills that most of us learn in their 20s (through humiliating, frustrating trial-and-error amid entry-level grunt work that, now that the corporate-ladder system is antiquated, serves no point) they never get.
In the corporate world, if adversity comes after you and you don't defeat it, you'll be out of work in a few days. You start to learn the signs. In the academic world, your career just stalls out one day leaving you with no idea why, and the causes were probably decisions you made years ago.
So it's quite possible, if not common, for very talented people to have no idea what the fuck to do for themselves out on the battlefield. That's how they end up aimless and clueless at ~27-30 despite strong technical talent.
Once again, your comments are on the mark. I'm a systems PhD and wow ... it seems messed up. I don't feel satisfied writing yet another paper that no one will read. At the same time, I feel a CS undergrad with 3-4 years of industry experience is better at writing professional software than me. It feels like a kind of purgatory. I have my gripes with academia but I worked very hard to earn my PhD. I'm very surprised that the PhD ended up being worth a lot less than what I thought it would be worth. I'm not even talking about financial compensation - I'm talking about lack of opportunities. I thought a systems PhD would mean I could always get a job in industry ... so not true :(
As a (perhaps permanent) refugee from academia, my $0.02.
You get out of academia what you put into it. If you go in with no plan of action or just wanting to be like your mentor/advisor, or solely dependent on his funding or the department's TAship still thinking this is like undergrad, but only you get paid for it, you will be in for a rude awakening.
The signs do take longer, maybe one or two years, but they are there. Your prospective advisor has no pull in the department, or can't twist elbows and get a RAship for you. Or he puts you on a project to reproduce someone else's experiment with unreplicable results. You start to notice his papers with foreign colleagues have serious mistakes that get through peer review. You wonder why he hasn't been properly funded in years.
I managed to get out alive, with a degree and a good publication on the way (with people at another institution), despite one adviser leaving the university nine months after I joined and everyone else being broke. How did I do this? I came in with a overarching research goal (learn how new techniques in quantum information could be used to solve chemical problems), one that encompassed more just my advisor's research area. I executed on the overall goal and when things got harder, I doubled down even more. I didn't let departmental barriers stop me from learning what I knew I needed (quantum field theory for condensed matter) to solve problems, even if those courses weren't in my department and even if the connection wasn't immediately apparent. I sought out conferences on my own, paid for them myself, networked my way into summer visiting positions and invited talks, because nobody was sitting there and spoon-feeding me little bite sized research topics. In fact, I lived in my office for three months when I couldn't afford rent anymore and no one gave a shit. I am reasonably sure people would probably have taken 3-4 months to wonder where I had gone to had I jumped off a bridge.
My central point here is that many people in grad school don't recognize that your adviser's interests and incentives are not necessarily your own (just like your boss's). Unlike your boss, your adviser will never be held responsible for bad management. If your _department's_ incentives and interests become unmoored from your own -- well, then in the words of Mr. Garrison it's a "big lowercase t for time to leave"
The sooner you recognize that and find a happy medium between your needs and theirs, the sooner you can be productive for all concerned. Every contingency measure I took in terms of classes, planning, networking in terms of the overall goal, all were leveraged and all were necessary to bring things to a reasonable close.
I know this was posted here a while back, but this really is the best description I've read (he finished, while I left with a Master's and may go back elsewhere but the hustle necessary was much the same.) http://www.pgbovine.net/PhD-memoir.htm
I agree with you about feedback in the academia but what common kind of adversity in the corporate world puts you out of work in a few days as opposed to the next layoff at least months down the line?
It's a great observation, but I think the cause runs a bit deeper than the author attempts in this short piece. The issue is that academia has grown a lot over the past several decades [1]. Federal funding has approximately doubled in the past two decades, and the annual number of PhDs has increased by ~50% [2]. At the same time, the number of tenure track faculty positions in the US has nearly halved [3].
So you have a situation in which we're training a lot more PhDs, so mean research group size is growing dramatically, but we're offering fewer of the sort of academic jobs that can allow them to excel in their trained discipline. As these folks then leave academia, they're very often leaving for jobs outside their field. This is a really unfortunate loss of the incredible taxpayer investment in their education that we should all be supporting, not discouraging.
The PhD in question though is Computer Science, who's faculty ranks have (probably) not followed the same path you're charting for academia as a whole.
You know poor candidates can go to great schools, they can even get doctorates. They can also be useless, and the set of skills that make you useful are not necessarily the set that you get from an advanced degree.
Also FWIW the part about "dropped out of PhD a plus" is intentionally taken out of context. The full context from the link
BS/MS in Computer Science or equivalent (PhD or dropped out of PhD a plus)
After reading that I am very leery of taking anything else he said at face value. This is a target piece that is clearly putting the headline above the truth.
No, but it happens, in any school at any degree level there are people who "pass" who shouldn't. Even in my lowly engineering school ( graduating class of Computer Engineers was maybe 30 ) there were a number of people who should not have been given a degree, but since they fulfilled the basic requirements they were. Those were the individuals who were looking for jobs after graduation. A majority of the people had jobs well before their senior year.
I am not saying this guy is a slouch who got what he had coming to him, I don't know him. I am saying that no compelling argument was made that this article was anything more then conjecture.
"the world’s most respected, business-savvy professors can misjudge companies’ valuations of the doctoral degrees they so thoughtfully hand out"
It is impossible to convince a man of something when his salary rides on his not believing it. Your professors have certain incentives to hold particular beliefs about the value of a phD.
There is no polite way to say that, which must be why it was not included in the essay.
This just isn't true. If anyone was arguing that PhDs in general were worthless, then it would be a very reasonable point to think about. But in this case, it isn't really the PhD itself under discussion, it's the preparation and skills acquired through a course of a PhD. The difference is that the specific nature of a PhD program is pretty flexible. If professors see that their candidates aren't doing well in the job market, they can, and will, make adjustments to their programs.
From what I understand, professors' salaries normally do not depend on handing out PhDs at all. At least, not once they have tenure.
You need to have students to have grants. But the reason you gets grants is to pay your students. So, anticipating that this issue may come up, I don't think that's it, either.
Actually, there is a set of incentives for professors to hand out PhDs. Before tenure, professors have to successfully graduate PhD students (or at least get most of the way there), otherwise questions will be raised in tenure review. After tenure, failure to graduate students equates to failure to attract new ones, loss of prestige, loss of connectivity to their academic network by way of a graduated student, etc.
You need to have students to help you in your research, and you won't have students if you have a reputation for never ever awarding a PhD. It's a give-and-take relationship.
This is what I find ridiculous about the software industry. On one hand, everything is highly derivative. Python, Ruby, C#, whatever, is just a warmed over syntactic variation of the same basic technologies that have been in existence since the early 1970's. On the other hand, the industry is hyper-focused on finding people with exactly the experience in the particular warmed over rehash that happens to be the blue plate special this week.
I hate to cast doubt on the guy, but he seems to have based the entire article on his own personal experience. So we have one side of the story from the most partial participant. Despite claiming to have approached the problem scientifically, he's only considered a sample size of one. If he's writing an article about this perceived societal issue, why not broaden the scope beyond himself? What percentage of CS PhD's are unable to find employment? What about Stanford CS Ph.D.s?
Further, I encountered a fairly high proportion of people in grad school who had, for one reason or another, difficult personalities (heck, this probably applies to myself). How do we know he isn't bombing the interviews for such a reason? We don't.
That said, it sounds like his graduate work was performed in an area that's irrelevant to industry. Despite acknowledging this, it sounds like he believes that this work alone (and the academic reward it received) should qualify him to work. He needs to realize that many employers don't think this way. They don't make the leap "He did X, so certainly he can do Y for us". That's just the way it is, and the sooner he realizes that and refocuses his attention towards the employers needs, (rather than his prior solution to an unrelated need), the better off he'll be.
Seconded. This is anecdotal evidence. If the poster is making it to interview I would be willing to wager that the interview itself is leading to the lack of success rather than the degree. In other words, if there was an inherent bias against doctorates then why would a company waste additional resources in an interview?
As someone who searched for jobs as a de facto CS PhD, I can relate to what the author is saying. PhD's tend to slot into very specific niches, and if you don't fill that niche they won't want you, even if your skills are a superset of the skills they need. I was rejected for certain jobs because my research wasn't closely related enough. People whose research was squarely in that area had no problem getting these jobs. In the end, my job ended up being something I didn't realize I was qualified for, but with hindsight I fitted the niche perfectly.
Part of the problem is simply that the market is "thin". There are less jobs, and less PhD's than there are people with Masters or Bachelors in CS. So the matching process takes longer. People won't want to hire you for a job you are overqualified for, and in the long run this would be bad for both parties.
As to the people who think that professors are just over-confident so they can keep churning out PhD's, I think this is wrong for two reasons. First, the situation is subtle, and hard to understand for someone who isn't actually going through it. Second, the market is not bad, it's just very peculiar: as you can see, the author did get a good job in the end, it just took a lot of time.
In my experience (as someone who dropped out of undergrad to enter the industry, fwiw) there is a pretty widely held bias against people with PhDs in quite a lot of the software development industry. Almost like having spent the time to earn a PhD is like a way worse version of coming to a (non-financial sector) software development job interview in a three piece suit with a tie... you're just instantly distrusted by a lot of folks. I'm sure it varies from company to company, but I've seen this behavior repeatedly over many years.
I don't agree with it, for what it's worth. I do understand the rough justification that academic work is very different than real-world coding, but even if you accept that reasoning 100% then at the very worst a PhD should be seen as a neutral to slightly positive indicator (at least they see things through) if the person is otherwise a fantastic fit, not a negative. However, in my experience this negative bias towards PhDs in the greater software development sphere is a real phenomenon.
Re: the suit-and-tie thing... I am a dev doing interviews now, and where I grew up (blue-collar midwest), wearing a suit to an interview is a sign of respect, so I've been doing it... not a good idea?
Already basically covered by some other responses, but it depends greatly upon company culture which varies between industry and region. I can't speak to your region at all as I've never worked in the midwest, but in a lot of places I have worked (which includes the east and west coasts), employees at pure software shops often have a negative view of anyone wearing a "suit", including to an interview. It isn't going to tank your chances with an otherwise good interview, but it can leave a negative first impression which is something that can snowball out of control on an interview if you aren't careful.
If you're totally unsure for a given interview, a good rule of thumb is to ask about the expected dress up front and then dress a little bit better than what the answer is.
In the tech industry, primarily the West Coast tech industry, it's a sign of being a "business guy" or worse, a "financial guy". Tech guys wear black T-shirts or turtlenecks, hoodies, and sweater-vests.
(That was intended to be a joke, but it's also a surprisingly accurate description ;-).)
Well the company website said "don't wear a suit"... but I feel like kind of an a-hole going to an interview and not wearing a suit...I always thought that "don't wear a suit" stuff was just there to trip up super-awkward devs...the interview went well - I make it a point not to act or communicate like a guy in a suit, so maybe that helps...
I went to a job interview at G-Research in London earlier this year, spending 7 hours there. Afterwards my recruiter told me, they were surprised how strong I was (despite having a Ph.D. and all), but they just wished I had shown a little more effort during the interview. I later found out that "a little more effort" was code for: You should have worn a suit instead of your hoodie. So glad I didn't get this job :-)
I think it depends a lot on the location. I work at a software company in the DC area where most people wear shorts or jeans to work, and yet still virtually every candidate that comes in for an interview is wearing a suit.
Just ask what kind of clothing to wear before you go to the interview. It's not an unreasonable question to ask and prevents the chance of any kind of awkwardness.
The elephant in the room is that if you're a successful academic, you should be either networking to get invited into the sort of position that companies don't post openings for or founding a company. Jobs, and especially job calls, are for suckers.
Good point. I've been mulling the founder route. It is annoying that my reason for founding a company was that I was unhappy in an academic job rather than having an idea burning in my soul.
The problem, essentially, boils down to the fact that the author had a Ph.D. but was a junior at whatever the companies he was applying for needed. But didn't want to get a junior level position.
This is where "And (2) my Ph.D. background, while impressive, just didn’t fit the profile of a data scientist (whose background is usually in machine learning or statistics), a product manager (Ph.D.’s couldn’t even apply for Google’s Associate Product Manager Program until recently), or a programmer (my experience writing code at a university, even on a product with 47,000 unique downloads, didn’t count as coding “experience”)."
I don't know about the other profiles, but programmers with only academia experience rarely code better than complete juniors. I've recently helped a team of Stanford grads get to grips with coding in an industry environment and the biggest surprise seemed to be that just because it works it doesn't mean it's done. You have to make it supportable, make it workable-on by others etc. etc.
A "data scientist" or a "programmer" are hardly senior level positions.
In my experience as a PhD with (currently) almost 4 yrs postdoc experience, I rarely get an interview when I apply for an industry position. I think there is a good element of truth in what the original author is saying about a gap. As PhD students and postdocs we do a lot of things. We have to write code, we have to manage students, teach, publish, apply for grants, manage research groups or entire projects, handle scientific and financial reporting, etc. The problem is that our skills don't exactly match company requirements that normally have different people for most of these tasks. To make things worse, people tend to believe that we will be arrogant pricks who will demand really high salaries even though we are clueless about how things work outside academia. Just look at some of the comments here.
For an entry level programming position a recent CS BSc appears much more desirable and cheaper than any PhD. I doubt that we even get much of a chance to show how good (or bad) we are. For higher level positions a PhD rarely has the "right" experience. What we are left with is usually something that fits well with our research. This is what the author found and as far as I know he is not in the minority.
Heck, I'm pretty terrified of the code written by CS professors.
One time I got a C code from one of the leading lights in machine learning, compiled it, ran it, and it segfaulted right away.
I started up the debugger, set a breakpoint in main() and it didn't even get that far.
I looked at the code and saw that he was statically allocating a 4GB array that he never used. I guess this didn't cause a problem on the 64 bit machine he was using, but it caused the code to blow up on 32 bit machines. I removed the array and it worked OK.
I was lucky to be programming in Java while it was still in beta when I was working on my PhD. One thing I noticed was that even the more computer savvy physics professors didn't get object orientation or any of the architectural concepts around it at all, so I was often called a "bad programmer" and told I should be more like somebody who cut his teeth on FORTRAN.
I have a PhD and have been talking to different employers and they don't know what to do with me. Sure I can code, sure I can sysadmin, sure I can solve problems, and convert cutting edge research into practical applications, but what exactly am-I good for? The chameleon analogy is very good...
So I say, f*ck it, and keep doing what I know how to do best: teach, write and build tools for teaching and writing.
To all chemistry and biology PhDs out there, please get in touch with me if you want to write a short textbook to introduce UGRADs to your field. Together, we can partner and take over the textbook industry.
There are jobs for chameleons. It's just that there are fewer of them and companies don't tend to understand that they need them, so they don't explicitly hire for them.
Companies hire people to make a specific problem go away. If you're not a "make a specific problem go away" guy, then you need to find another way in.
I'm a fan of, rather than responding to job calls, identifying what companies you want to work for, deciding what you want to do for them, then going and meeting the people that can put you in the position to do those things. If you can't meet them directly, find people that can introduce you. Make a plan and give it about one year (these things take time).
I was in a similar situation, and I did notice a certain uneasiness in my interviewers due to the degree. I thought the reason was that it's hard to believe that someone who gets a fancy degree would be willing to stoop down to a software engineering job. That's very important to employers because they don't believe you will stick around. My interviewers asked me repeatedly if I was aware that the job wasn't going to have any glamorous paper writing or research or going to conferences, and that I would have to gasp write code. I caught on quick and was able to reassure them, and after a few fizzbuzz type questions they were convinced.
And amazingly, they told me that many Ph.D. candidates who come through cannot write a single line of code. I don't understand how that's possible but I would be wary too, in their shoes.
Real world software production needs little "computer science" expertise. There's too many Ph.D.s that take a research angle on projects. The goal is to design/implement/test/ship/support/improve and make money.
Best programmer I ever met didn't graduate high school.
Supply and demand determine wages. Ph.D. does not entitle to more pay. The industry simply does not rely on credentials like, say , the medical industry which does require an M.D. for the best paying "line" jobs.
Where I work an advanced CS degree is a strike against you. What we've found over the years is people with advanced CS degrees just aren't very productive when it comes to actually producing code.
They tend to want to rewrite things that work but aren't very elegant, or they become despondent over the language we're using and the reluctance of management to allow them to use Haskell for their piece of our Java project.
Yeah, you know what? Managers like you are the reason that when I screen Java candidates and ask them to clean up copy and paste reduplication in code with an anonymous inner class, I get blank stares. From every single one I interview.
I didn't explicitly say anonymous inner class to them. In fact, I didn't use the words at all. I simply gently pointed out the line of code in the code sample already and asked how it might be better leveraged.
Your comment seems to go against what other people have said is wrong with Ph.Ds. Other people are saying that researchers tend to write code that just works at a bare minimum, but you're stating that they tend to like to rewrite code so that it becomes better code. I think this whole thread might be giving ph.ds a bad rap. disclaimer, i'm not a ph.d.
> Other people are saying that researchers tend to write code that just works at a bare minimum...
That isn't specific to people with PhDs. Every programmer without job experience does that. Back when I worked on a Unix/C application for a company that hired new grads it was common to have code checked in without any error checking at all.
If the person is reasonably intelligent (and everyone who finishes a PhD is pretty intelligent) it takes all of about two weeks to break them of the homework coding style.
The author lost me here:
"Despite having programmed computers since age 8, I was rejected from about 20 programming jobs."
This reeks of entitlement and, well, whining. When I first entered the SofEng job market after undergrad, I stopped counting rejections once the number passed 30. It took another 6 weeks after that, and the rejection count must have pushed 100.
I agree with the fact that rejections should not be counted solely as an end result because many a times the reason may just not be a technical one. You've got to be a fit and have a strong synergy with the team.
I don't know the author, so I cannot say how his interviews went. In general I think you have to take control of the interviews and just show the person why you are valuable. It's hard to find talent; the person interviewing wants to like you, if for no other reason than she can get back to coding.
The PhDs that I've interviewed have applied for very senior positions, yet not brought all of the skills needed. Which is more than jusr abstract thought. You need to turn out code that is maintainable and readable by the team. You need to ruthlessly reduce the problem and algorithms to a level that allows you to launch before you run out of money. Far more than being a thinker or researcher, you need to be an engineer. You need to be very, very productive. And so on. I'm not sure what the answer is, but there is a pretty big gulf. You look at the projects and okay, it's somewhat interesting, but impractical. You ask them how they'd solve a problem that you are trying to hire them to solve, and you get "I'd conduct a study..." when we have 6 months to market and your study would take a year, and probably not provide definitive results. It's just a different mind set. I can't afford to bring you into a senior role and wait while you learn to be an engineer, while you learn to code at a higher level than 'University code' (a disparaging quote about the quality of the code Sergy and Larry brought to Google) and so on. We have a real, hard problem, and need an extremely focused, skilled, multidimensional person to perform it. I've yet to come across a PhD that made me think they could do it.
"I can learn to do that". Well, sure. Anybody can, it's just that so few do. Only a small handful of people actually produce at a high level in the ways I'm talking about. I don't want to bet on you being one of the few.
Most of the time if you do not get a job is because no one wants to work with you.
In my opinion, PhD to PhD, is that you have to learn to be modest and do not sound like an overconfident asshole.
you are not an used car to sell. Academia is famous for making people who loves the smells of their own farts. Be humble, be modest, demonstrate that you are good, and you'll get a job.
So I am actually a PhD student in physics, but I've been in love with tech for as long as I remember. I am actually doing a master's degree in CS along the way, both because I'm incredibly interested and because I thought that would really give me an edge when I want to finally go into the tech sector. (i'd be able to say more than "I have the technical chops and have done well throughout my academic career.")
This article troubles me though. Am I going to be faced with an employment brick wall in a few years? I have a lot of friends in tech, and they are very supportive of me joining. Will my PhD actually stifle my ability to get jobs I want? I haven't seen very convincing articles about it, but if there are Stanford CS PhD students having difficulties, what's going on?
I plan to do an industry internship next summer, and I hope that will at least help. What if I want to go into product management though? I have a google interview coming up in two weeks for a software engineering role, but I was shut down for even an interview for their APM roles. Maybe I needed more tech experience? Would this summer internship be enough? It's just unclear and troubling.
I have a PhD in CS from UC Santa Cruz, and I was hired by Google out of school. The key is to do internships: just like undergrads, you have to prove to companies that you can do the work, and internships are the best way of doing that. I did two internships at Google, and did the conversion interviews.
What I don't understand is why you are applying to Google if you're doing a Physics PhD. Why become a doctor of Physics and then throw it away trying to apply for jobs that have zero overlap? You're not trained for the job, and I strongly suspect this is the problem the OP was having. Why aren't you applying to NASA or SpaceX or something?
I hear it's actually not that uncommon for physicists to become data scientists. More importantly though, I was successful in physics as an undergraduate, and it's sort of the academic culture to continue onto to grad school (as well as the culture in my family). In any case, I could always leave grad school if I want to, but I think it's also helping me gain a better computer science background (I've only taken 3-4 computer science classes so far...)
I'm not applying to NASA or SpaceX because I'm really interested in consumer tech, and always have been. Honestly, maybe I have the total wrong idea for what I want to do, and I understand that. That's again why I want to do an internship.
I actually have a Google interview in a couple of weeks. If you don't mind me asking, did you work at Google as a researcher or software engineer?
There are very few people who actually work under Google Research, everyone else is a software engineer (including everyone who worked on my research paper with me [1]). The trick is to realize that there are many product teams for which what you'll be doing are researchy style jobs. These are usually things where you're working on the backend (Compute Platform, Search, Google X) rather than the frontend (Javascript UI stuff). While the job description is software engineer, for those reasearchy jobs, you're doing work that's very similar to what you might be trying at the university lab. Except with a lot more data, and a lot more computing power behind you.
Matt Welsh has written a number of times about his job change from Harvard Prof to Google, and he's a software engineer by title AFAIK, but he's clearly doing research work.
I like the internship idea. However, I should add that these should be non-research. I did internships at industry labs - this seemed like a good idea at the time since I was prepping for a career in research. Now that I want to get out of it, those research internships aren't worth as much as the Google internships.
As a someone who is 5 years out of his PhD (working at a research lab), I'm a bit perplexed at how I can make up for the lost years of industry experience. The best idea I have now is to start my own company.
I just finished my PhD in theoretical physics and had a relatively easy time finding a "data scientist" like job in the tech industry. I had two jobs offers from two interviews, neither of which were very close to my PhD research.
I did do an industry internship toward the end of my PhD and I think it made a big difference. Not only did I have the experience to show potential employers that I was serious about going into industry, but I also learned more about software engineering in 3 months of my internship than 5 years of academic coding during my PhD. And I ended up with an offer from the company where I did the internship.
I actually think it's an even better idea to do a software engineering internship early in your PhD if you're doing some sort of computational science, because you'll pick up skills that nobody will teach you in grad school but that are also valuable for writing academic code.
As you know, industry internships are way outside the norm for physics, but they're pretty standard for computer science grad students. In my view, not doing an internship was this guy's first mistake, although I have no idea what to make of the fact that he had no offers after 30+ interviews, which does strike me as highly anomalous.
Just so I understand, you actually did a software engineering internship, but ended up in a more data science role, right? I'm curious just so I better understand if even the standard software engineering role internship helps for more than just software engineering jobs after grad school.
It also strikes me as odd that this person had no offers after that many interviews, but the truth is that there are a lot of other factors that go into these decisions. Maybe this person wasn't the best at communicating? Maybe this person sold himself as an all-around generalist, and the companies didn't really know what to do with him?
Otherwise though, I'm happy to hear about physicists going into tech!
No, my internship was also in a data scientist type role. I was thinking of data science as a sub-specialty of software engineering. But I do expect that any internship, even if not in the exact role you are looking for, would help your employability.
Why are you doing a PhD in physics if you don't want to do research in physics? A PhD in physics won't "stifle" your ability to get jobs you want. The thing that will "stifle" your ability to get jobs you want is not having the relevant skills or not being able to play the game of interviewing.
E.g. I interviewed a physicist for a data science position. While he had worked on a lot of problems which could be categorized as data science problems, 95% of the problems he was working had one specific tool that he used, Principal Component Analysis. It was kind of hard to get him to think of another ways of solving a problem.
Part of the reason I'm doing a PhD in physics is, of course, because I enjoy the work. Everyday I come in and I always feel like I have something to learn from the people I work with. I feel like I grow as a person because I'm constantly learning new things from my peers - whether that be something purely theoretical, hands-on electronics work, cleanroom work, machine shop work, optics work, or, yes, coding. Could the same be true in industry? Absolutely. Is it nearly as guaranteed? I'm sure not. I definitely have friends that are starting to gain the golden handcuffs at their companies, and they've only been working for 2 years.
Moreover, I don't think it's fair to say that people waste their time doing a PhD in physics. Sure, they could be learning a lot more job-specific skills, but the point is that the people who do a PhD in physics absolutely have the ability to learn those things. I'm sure if the physicist used PCA it wouldn't take him long to learn plenty of other ML techniques. I think the skills you learn during a PhD aren't as simple as just listing out the technical things you became familiar with. (Still, I'm certainly considering leaving grad school, but I don't think it's an obvious decision.)
Of course, I think there is a lot more to a job than the technical skills you bring to the table --- your ability to communicate, your understanding of the market & product, and your ability to work well with others. (Yes, I'm fully aware physics people don't often hold gold medals in these categories). I think that doing an internship could help in these respects, and it's why I'm interested in doing one.
> Moreover, I don't think it's fair to say that people waste their time doing a PhD in physics. Sure, they could be learning a lot more job-specific skills, but the point is that the people who do a PhD in physics absolutely have the ability to learn those things. I'm sure if the physicist used PCA it wouldn't take him long to learn plenty of other ML techniques.
I sympathize with your situation as someone who accidentally got into computer science. As much as I have tried to portray myself as a fast learner or someone who can learn on the job, a secret in Industry that I have learnt is that very few people care. Most managers are looking for someone who can fit a resource need yesterday. To illustrate: the other day I was talking to a recruiter from BigCo, the recruiter strongly suggested that I write code on the whiteboard in an actual programming language rather than pseudo-code. This seemed strange because BigCo is known for their algorithm intensive interviews. Then, I was talking to a friend who works for BigCo2 and it all made sense: if there are two candidates A and B, of whom you can hire only one and both A and B solve the algorithm but B appears to be able to write the code with very few mistakes on the board, you are probably going to hire B mainly because B appears to fit the hole in your organization. Now, as much as people like to protest they are not like that, companies are hierarchies of managers, managers who have concerns and reports to file. The physicist who used PCA would probably have been able to learn everything else in 6 months. Who is going to spend six months paying him a shit ton of money while he learns or maybe doesn't? I am not saying everyone who gets hired is hired with an expectation of being productive from day 1 but you have to be productive sooner than later.
Ultimately what am I saying? If you are thinking of going into industry; get real. Get all the skills necessary, your resume in order. There will be millions of blog posts bemoaning the disconnect between industry and PhD or how the interview process is broken. However, all that fluffy bullshit is not going to bring a paycheck down the line. What is going to get you interviews is having "good internships", code on Github. What is going to get you a job is the ability to convince a collection of random people that you are worthy of getting a job. Sure, the stochastic nature of the game means there will be some moron who thinks that him dropping out of high school and spending the last five years writing spaghetti code for industry makes him superior to you. Or you may have an attitude that you spending five years writing research papers makes you better. Ultimately, all that doesn't matter.
When I was in grad. school, I thought the idea of doing a PhD was to train for a lifetime of contributing to human knowledge. Not a lot of PhD theses end up as a contribution to human knowledge. Sure, there are the 1% that do, those people don't typically have the problem of not being "able to continue contributing."
Agreed. You get a PhD for you, not for science. I would hazard 99% of PhD dissertations get read cover to cover less than 5 times. And I'm including the committee and author on that number.
That is, broadly, the ideal. Your PhD thesis is your first masterwork that qualifies you to call yourself a real researcher, and you go on to do many more along the length of your career.
In actual fact these days, there simply isn't a career model set up to support that anymore. Your PhD thesis is now supposed to qualify you for your first postdoc, your first postdoc or two qualify you for a permanent position, and you earn tenure or permanent contract in your permanent position, and then you can just focus on contributing to knowledge rather than on careerism.
I am currently working on my PhD Biomedical Engineering (3 years in), and I have mixed feelings on this. Certainly most PhD dissertations are a joke, but during the first few years of a PhD you are acting as the arms and legs of your professor, who, if they are any good, is capable of pushing forward human knowledge using you as an "instrument".
Paying for knowledge that is freely available will always be kinda silly in my opinion. This is how I see school in general and why I dropped out and never looked back. School is great for some but very detrimental for others. If your field requires a certification then you need school, if not, you're probably wasting your time. Try building something or making your own company.
Back in the 80's and 90's there were a handful of academics thinking about quantitative finance and no programs oriented at creating that sort of person, so of course you could walk out of your no-future physics PhD and get a quant job easily.
Since then there has been a shake-out ad you've actually got to be world class at something in particular if you want a quant job.
Many "quants" are now people who do algorithmic trading on their own accounts, the way people did day trading in the 90's. This may sound glamorous but it is definitely a business that comes and goes. You need a LOT of capital to do it safely, and most people blow up at least one account in the process of becoming good at trading.
I'd be surprised if someone from http://csl.stanford.edu wrote that article. My point is that it matters a lot what area you did your PhD in and not just that you finished a PhD in CS. If your area was Machine Learning and you can't get a data scientist job then you obviously messed up. If your area was networks/systems and you can't get a programming job then you obviously messed up! Those cases are very clear (and rarely ever happen). But you can't take a specific case of working in an area outside of core systems or ML and then try to generalize it as the "PhD -- industry gap". CS is an exception, and not an example, of the PhD--industry gap. Try talking to grad students outside of CS and you'll see how envious they are of CS PhDs finding industry jobs.
I guess what I was trying to say earlier was that a "PhD in CS from Stanford" is not a universal thing that can then be used to see how desirable (or not desirable) it is in the industry job market. It matter a lot what area you worked on. For example, both systems/networking and AI/ML are in high demand right now and it's very hard to argue against that (which is not clear from the article at all).
It seems to me that their must be more to this situation -- I'm doing a PhD in CS and I don't know of a single PhD I knew in undergrad (top 20 program) or grad (top tier program) who wasn't able to find a job right after graduation -- and by that I mean a job that payed more than what an undergrad straight out of college would get (though it may not involve any research). This was irrespective of the subfield in which the PhD in CS was.
It sounds very weird that someone coming from a Stanford CS PhD -- a top tier PhD program in the heart of the Silicon Valley would not be able to find a job quickly...
At any rate, whatever the circumstances, from anecdotal experience, such a case is almost unheard of for a PhD in CS coming from a good program.
The experience factor is huge here, and should be pinpointed. Being able to work in a non-academic environment is incredibly important, because honestly the pace and quality of technical work done in academic settings just isn't comparable.
> "Companies hesitated to hire a Ph.D. with no industry experience"
That, for me, would be the #1 red flag. How does one even go through getting a PhD without getting any industrial experience? Not a single internship, even as an undergraduate?
This tells me that either the PhD literally can't code (and hence nobody even wanted them as an intern) or despises industry so much that they never wanted an internship (and hence I'd be pretty worried about how much they'd be committed to the new job).
Alternatively, they had full funding (even during the summer), focused on research and graduating (so it didn't take them 10 years), and didn't realize they needed to get an internship to be competitive once they graduated.
Sure, I don't doubt that's what they did. But that's not a counterargument to my point, which is that they chose to not once in (I'm guessing) 6+ years set foot outside academia.
Even given unlimited research funding, to not once try working in industry (even during undergrad) betrays a worrying single-mindedness which I'd want to avoid in any technical hire. If all you do is proceed down one path, without ever trying anything else or being a little creative, I probably don't want you on my team.
The bar for passing technical interviews is pretty low. All you need to do is to get reasonably competent in one or two mainstream programming languages (I emphasize reasonably, you definitely don't need expert knowledge), say Java or C++. This shouldn't take more than a couple of weeks of focused effort if you already have some degree in CS and know programming. At the same time you have to refresh your memory about data structures and algorithms. Dust off your favorite algorithm book, and go through sorting, searching, binary trees, hashing, elementary graph algorithms and dynamic programming. If you have taken a relevant course before and paid attention to it (you were told this was going to be your most important CS course ever, no?), it shouldn't take more than a day or two to remember this stuff (again assuming that your undergrad CS degree was not a waste of time). Then you need to solve a few exercises to practice, mostly to become confident in yourself. Topcoder, dozens of online sample questions would do. You won't need full coverage of every possibility, but to assure yourself that your brain still ticks and backed by your knowledge you can approach the problem presented to you at the interview. In total you need a week and a half or two weeks to get to top shape to pass interview at the likes of facebook, google, amazon et al.
A big piece I found missing missing from the original article is the question of engagement: how do companies know that you're going to like the job? The kind of person who enjoys an academic career may not enjoy a software development career because the activities and values involved are rather different.
I moved from academics (freshly graduated computer science PhD) into software development four years ago and when I did I had to answer a lot of questions about why I wanted to make the move.
My experience is of course not universal but I think that career trajectory is a big part of senior interviews once it's been established that you can do the job. It's a broader issue than just academics vs industry. No matter what field you're in, you have to sell you your career transitions as 'make sensing' to the jobs you're applying to. Job searching from the company side is more complicated than accumulating experience and rewards (the Porsche in the original article) to end up being granted a job.
Say you have person A and person B who have equal raw ability. Person A spends 6 years gaining domain-specific knowledge for his job through real work experience, and person B pursues a PhD in a somewhat related field. Which person do you think will command a higher salary in the job market?
It doesn't seem to be an efficient usage of time to pursue a PhD for the express purpose of earning a higher salary upon graduation.
"It was like being a chameleon and trying to get jobs where you had to be red, blue, or black. Yes, you’re capable of becoming any of those colors, but companies would rather hire animals that already were those specific colors."
"I eventually realized that, like many Ph.D.’s in many other fields, I had fallen into the Ph.D.-industry gap—i.e., the gap between highly specialized Ph.D. training and corporate-world expectations..."
There seems to be a dissonance in these two statements. If the former is true (based on description of his experiences) then companies would rather have specialized people to fit into slots (red/blue/black) than have a generalist (chameleon) who could grow to match nuanced needs. It seems like the problem was that he was not specialized enough in the very narrow skill they were looking for. If that's the case, then it goes against the commonly held opinion expressed in the 2nd excerpt.
You could interpret it as saying he is highly specialized in a color industry isn't interested in, so his remaining marketable skill is his chameleon nature, which is not valued as much as he thought it would be.
Irrespective of whether or not he was highly specialized in some aspect, he had demonstrated a much broader potential to learn and adapt; more than the specialized people they would otherwise be hiring.
So it seems like the real reason he wasn't hired was:
1. They might have to pay him more, for his potential (as illustrated by his degree) than they needed to pay some other fellow they could hire.
2. The HR management doesn't really know what to do with smart broadly skilled people. They have well-defined slots for cogs, but generalists are tougher to manage... you can't just shove them into a predefined slot.
To me, al it proves is that the industry is not ready/willing to hire a possible generalists (who also happened to have proven that they can learn something and be good at it). The cognitive dissonance making them think that he was "highly specialized" might also have been a possible contributor.
I would bet generalists are going to be selected against. It's good to have a few generalists to handle the unexpected and such, but at least to me it seems you'd wind up paying the generalist more for the same work, so you would seek to use specialists wherever possible.
I think the business world has realized many professions don't need the Ph.D. 'Give me a hungry kid who's willing to
learn' --Gekko That's one of the lines that really resonated. Actually, that movie, along with Platoon
really captured the duality of man--at least for me.
Off subject, but I'm off today.
I'd love more info about what happened during the interview process at each of the 20 jobs the author applied for.
I can definitely imagine a situation (and being a recruiter, have seen situations) where a PhD will keep you from getting your foot in the door. There can be concerns about the ability to actually write code, the ability to be practical, to be OK with working with unclean data, the ability to get stuff out the door and have a hacker mentality, etc etc.
However, these concerns tend to arise BEFORE starting the interview process. Once your foot is in the door, unless there's a huge disconnect between the people doing the hiring and the people doing the filtering or unless the job description changes midstream, how you do in interviews is more important than your background.
> There can be concerns about the ability to actually write code, the ability to be practical, to be OK with working with unclean data, the ability to get stuff out the door and have a hacker mentality, etc etc.
These all seem to be concerns of someone who does not what doing a PhD entails, really.
Doesn't sound like he had much of a portfolio of launched apps. Just one 47k lines project is the only one he was specific about. The rest was about education that doesn't matter much.
If he really wants a programming job he should get his hands dirty and publish some apps, either alone or meeting up with tech meetup or study group. A PhD is not studying how to code, you just may code a little as a by product. Then he could talk about launching and features and getting code done day after day instead of talking incessantly about education, and he'd land the job.
Kind of strange he wasn't able to place due to the old boys network, though. I know tons of people running startups who simply check their alma mater first and foremost when hiring. Especially schools like his.
If he really wants a programming job he should get his hands dirty and publish some apps, either alone or meeting up with tech meetup or study group.
Speaking from the grad-school/research perspective: we never think of that. Why? Because our entire training is in thinking about research-hard problems. From our perspective, anything you can get together in a Hackathon and crank out an "app" for is trivial and beneath consideration for someone proposing to do serious work.
And yes, I do realize exactly how this sounds. The best I can say in our defense is that we still face all the normal design, development, testing/QA, and marketing issues after we've solved a research problem.
* Are you truly focused on the job at hand or are you focused on proving your credentials?
The difference is subtle, but its a trap that many highly qualified people fall into. I'm under the impression that the author spent a lot of time talking about his PHD and what he knows rather than the problems at hand.
* Are you sure you are not overvaluing yourself? Jobs are in short supply, PHD looks like risk.
And the example with the Ferrari was awful - if the luxurious car was on sale with a marginally lower price it would sell. Faster, the lower the price.
It is very hard for me to have sympathy for someone who spent 5+ years at a great school, likely funded, in a useful discipline that struggles to get a job.
I would like to hear from academic departments on why they said no the academic superstar from Stanford. I would like to hear from IBM and Microsoft on why they couldn't use him. That's what's missing.
Maybe it's entitlement? Some of that creeps into the article. Maybe it's a personality that just isn't agreeable? Some of that is in the article too.
There was an article on HN recently about how the STEM job-gap is a myth. In the article the author discusses how if there were in fact a job shortage in STEM careers, STEM wages would be driven up. Chand Johnson's article seems to go right up this alley. The perceived "STEM shortage" is really just a way to drive wages down in the technology center so that corporations can reap the rewards.
Depends on what type of job one is looking for; it depends upon the niche.
- i think that as an algorithm expert one will find places that do value a Ph.D
- as developer/coder you will have to consider that your prospective manager will feel discomfort at managing you (regardless of the applicants coding skills); A manager needs somebody who gets the job done, he does not need somebody smarter/more educated than his own person.
If you have the 'right topic' like chemistry, a PhD can do wonders for your career. If you work on other topics (like movie studies), not so much if you don't want to become an academic.
I'm worried that I'm going to follow this guys footsteps. I'm an academic economist with a penchant for data science (not useful really in consulting or smaller research groups). We'll see how this next year goes -- I might be writing a similar blog post.
Google grabs able PhDs like hot cookies. Is this another "I failed my programming interviews, hence all programming interviews are bad!" rants, thinly disguised behind an attention-grabbing headline?
There is an easier answer, a much, much, much easier
and better answer: Nearly all of business and industry are still
organized as a hierarchy much like in the early
factories of Henry Ford where the supervisor is
supposed to know more and the subordinate is
supposed to know less and to add muscle to the work
of the supervisor.
If a supervisor has a subordinate that knows more,
then the subordinate can challenge and compete with
the supervisor on technical grounds, look more
qualified than the supervisor, and threaten the
supervisor's job. Academics has solutions to this
problem: An assistant professor can win a Nobel
prize without damage to the career of the department
chair. But industry has no solution.
More generally, a Ph.D. must report to another Ph.D.
or to the CEO of the company. Put this fact into
the connected, directed, acyclic graph of the
hierarchy of the organization chart and see the
consequences.
In particular, industry just will not, Not, NOT
evaluate qualifications in a reasonable way.
Instead, they tend to have a list of 'skills' and
want to check them off -- Java, JavaScript, PHP,
Python, Django, JSON, C++, Mongo, SQL Server, etc.
If you can code heap sort or an AVL tree on a white
board, okay.
This whole situation is part of a larger one:
Basically the US economy for 'careers' as hired
'employees' is nearly dead. So, GE, GM, AT&T, etc.
are no longer offering 'career paths'. Actually, a
career needs to last about 40 years which means
that, really, only rarely since the start of the
Industrial Revolution did large, US corporations
offer 'careers'.
The flip side of this situation is good news: The
role of a good Ph.D. with some interest in business
should be a company founder, get some 'traction',
then take a walk down Sand Hill Road and collect
some Series A checks. Use the Ph.D. and/or the
corresponding learning/talent for the crucial, core
'secret sauce' of the business. Then type in the
software and get the 'traction'. No one on Sand
Hill Road will question just what the heck your
qualifications were for typing in the software.
Then f'get about a 'job'. That is, if you want a
job, then create one for yourself. An advantage
here is that, just as a solid consequence of just
what you have seen, the big organizations will be
essentially helpless at doing work that duplicates
or equals yours.
One short term option is to be a contract employee.
That is, some company needs some SQL stored
procedures or some such written, so you write them.
One 'academic' solution may be to get a job in a
B-school that wants to have a good course or course
sequence in 'information technology'. There your
qualifications are fine.
The 'gap' is all on the side of industry, and it can
be taken advantage of.
You can tell the EE department at Stanford that a EE
Ph.D. can easily want to swap their degree for an
electrician's license.
Why? Because the Ph.D. needs a large organization
which is in international competition, and an
electrician with a license has a geographical
barrier to entry, can work in nearly any town of the
US, can't be fired, and can make money enough to buy
a house. For the EE Ph.D. in a large corporation,
he can be fired after a few years (because he didn't
get promoted into management -- only a small
fraction of new hires do) and find that the guy he
knew in high school mowing grass now has eight trucks
and 20 employees and is doing better than the Ph.D.
is.
This guy's getting shredded-- and unfairly so-- here, and Porsche is the wrong metaphor (he's more like a high-end supercomputer; almost no one has any use for more than an iPad these days). However, he's dead right about one thing, and it will affect everyone here who is serious about programming.
As you get better, the jobs available to you get better, but the job searches get a lot harder.
PhD programs exacerbate the problem. You get better fast (faster than people do on typical early-20s grunt work) and by 27, you're already at that level of skill that starts to complicate job searches. (Again, jobs available are better; but 3-5 month searches are common.) In addition, you haven't learned the judgment-of-character skills that most people pick up in entry-level hell; whereas most people, by the time they get good enough that it starts to actually cost them job prospects, have learned those skills.
you and others are ignoring the fact that the guy has been rejected more than a dozen times at technical interviews. He has demonstrated an inability to pass what's the bare minimum: basic programming, algorithms and data structure. If someone with a PhD cannot re-master this material (which he/she has supposedly learned in undergrad) within few weeks of preparation, no matter how fancy the PhD research is, then that in itself is telling about his/her commitment, drive or competence. These claims sound like saying oh I am a best seller novelist yet having forgotten (and unwilling or unable to revisit) the alphabet. At the end of the day, there is no evidence that PhDs have a hard time getting interviews (the author got 20 or so), and if they really ace the interviews, heck even do reasonably well, they will have no problems getting hired. A PhD degree by itself will not get them hired, but it will not jeopardize their chance either, provided that they do well in the interview.
The analogy about the Porsche is really telling. This guy isn't a Porsche. This guys is a Kia that costs as much as a Porsche and so therefore is convinced it's a Porsche. A Porsche doesn't need to tell you how fast it can go, how well it's engineered, how beautiful it is. A Porsche can speak for itself. A Kia can't - it needs to be proven, and the only way it'll get a chance to prove itself is if it's cheap and the risk of it sucking is mitigated. John Carmack is a Porsche. Donald Knuth is a Porsche. This guy is not.
That was my gut reaction too--but I'm not sure that it's a fair one. It may very well be true; but it's too harsh to say he's incompetent just because he found trouble finding the right job. Sadly, even the tech world isn't as much of a meritocracy as we might like.
I found his story valuable, and even if it is just anecdotal, it's a useful anecdote. He deserves credit for sharing it, because it certainly doesn't help your career to have an "I wasn't wanted" stigma attached to it.
Don't forget that the article is part of a blog about PhD's placement experiences--it's not just idle carping. Reading the authors responses to the comments, he sounds like a stand-up guy.
I dropped out of my PhD program when I realized that
1. I didn't want to be an academic, and
2. Having a PhD wasn't going to help me get a non-academic job, and
3. Grad school kind of sucks.
But, as a result, I have a lot of friends who finished their PhDs, and the idea that they are metaphorically "Porsches" compared to the many talented non-PhD developers and data scientists I've worked with is laughable.
> I don’t believe that “top” graduates are entitled to jobs, or that going to a “top” university makes you “better” than anyone else, or that I “deserved” an easier job search.
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.