Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

I can't say I'm surprised. I've done my fair share of interviews before I was 30 and while I never cares about age I had several colleagues who would come to grab my for my turn interviewing and comments like "old guy in room 1 is ready for you" always made me think they viewed them negatively.

Though bias is hard to shake. I'll admit I have some bias against PhD holders interviewing for engineering positions. Almost every single one I've ever interviewed couldn't even do very, very basic coding but could talk lots and lots of buzzwords so it kinda wore on me and it was hard to not go into an interview starting with a negative view if I knew they had a PhD.

I feel like I still gave everyone their fair shake but it was hard to shake that feeling.

View on HN

It is a familiar comment that Ph.D. holders cannot program. I have a Ph.D. and I dare say I can program. I was offered a position by Google recently so I am above some threshold. It is really unfair to paint a broad class of people with such a sweeping brush. I find that people often overestimate efforts required to attain a skill level, probably due to human nature to elevate one's own skills or importance, or they unconsciously conflate familiarity with general intelligence. It is impossible to reinvent collaborative filtering within 45 minutes without any prior exposure if not told any reason behind or constraints under which collaborative filtering was invented. Software engineers ask basic questions from the narrow fields they operate in day in and day out and believe that the interviewees have all requisite knowledge and answers should pop into their heads. On the contrary, basic questions are often fundamental innovations and it is no small feat to come up answers in the first place. It is a hallmark of a real intellectual to probe deeper and learn from that experience and realize insights and reasons for reaching innovative solutions, so that next time he or she will be innovative quicker or better.

It is hard to accurately judge someone in 45 minutes. I made a mistake with fizzbuzz three years ago when interviewing with the hacker school (now called recurse center), so what? It isn't I cannot do it but that I was looking for better ways and not finding it. After reading that there is no shorter way than to enumerate all four possibilities I was able to mentally unlock. It took just a few months of studying example code and discerning coding patterns for different logic control flows and now multiple programmers have commented that I write readable code. Anyone who has worked through real analysis problems can reason through most code well. It is a matter of concentration and time. I firmly believe programmers can make good ML engineers even though I spent years on numerical linear algebra, mathematical programming (optimization), statistics with measure theory and I still feel I have huge gaps in knowledge. So what if someone doesn't know a basic theorem, as long as they can learn enough and apply it to do their job. We take people as they are and help them grow into roles we want. I hope you will give everyone a fair chance.

If you were as good at analysis as you say, you'd have recognised that the parent took pains to state their opinion is formed from personal experience, is caveated with 'almost all', and recognises their own resulting bias, labelling it such. It seems to me that you're projecting your frustrations on someone who doesn't deserve it.

Ironically, the parent complains of PhDs using lots of buzzwords (meaning using language as a cover), and your defence is full of long wordy phrases.

Edit: To clarify further, if you're going for a job, your ability with words is less important than your ability to solve presented problems. People are hired for solving problems, not for trying innovative solutions just for the sake of it. As an example, upthread there is a person complaining that one of their hires spent two months doing a project in a language no-one else in the company knew. An innovative solution, but bad for the company, because it leaves the 'maintenance' part of the problem unsolved.

> I hope you will give everyone a fair chance.

I certainly do / did (haven't done hiring in about a year now). I'd like to think I'm very analytical and put the person above any bias I have I just wanted to share how I thought it was rude to be bias against older folks and then I was doing it myself going into an interview with someone who held a PhD.

In the end I didn't let my bias get the better of me but that type of instinct, regardless of how inaccurate it may be, is tough for anyone to get over and everyone has them about something.

A negative view of PhD holders seems to be confined to the Valley. I am far removed from the Valley and all the PhDs I work with are some of the more brilliant people you'd ever meet. Great at their job. Extremely innovative.

And yes I call them Dr. So-and-so and no they didn't insist I call them that or anything. I just automatically address them with their title as a sign of respect. If they say "oh call me John" or whatever then I'd adjust accordingly.

Interesting… Why do you expect that a Ph.D. would necessarily be an above average coder?

Initially, before interviewing anyone, I kinda assumed a PhD candidate would be on par with other developers as far as coding goes (so not above average but also not below). But in my, only anecdotal experience, I actually haven't interviewed one yet who can do basic coding. That isn't saying PhD holders can't code or that even the majority can't code; only that those few experiences started to shape my own bias going into an interview viewing them as already negative.

Like any person I have biases but I feel like I did well not to let them affect the course of the interview and ultimate outcome it was just a feeling shaped by my limited experiences.

I think your conception of a Ph.D. is off by quite a bit. Outside of their dissertation topic I'd expect a Ph.D. to be on par with an undergraduate, from the time period they graduated.

You also said that you're hiring for an engineering position, but you seem to only care about coding. Perhaps I don't know what you mean by engineering, but I'm under the impression that there's a lot more to engineering than any single skill, even by the loose SV definition. How do your Ph.D. applicants do outside of coding?

> I think your conception of a Ph.D. is off by quite a bit. Outside of their dissertation topic I'd expect a Ph.D. to be on par with an undergraduate, from the time period they graduated.

Aside from dissertation research, my understanding was that Ph.D programs usually include substantial graduate level coursework in the degree area (at least equivalent to or expressly including, Master's degree level work), so they should both have greater currency and greater education, even outside the specific narrow focus of their dissertation, than an undergraduate. The degree to which this is job-relevant, of course, may vary.

> I think your conception of a Ph.D. is off by quite a bit. Outside of their dissertation topic I'd expect a Ph.D. to be on par with an undergraduate, from the time period they graduated.

Maybe? Maybe not? I've had very mixed experienced in interviewing folks where some had zero college and could code amazingly, great at solving problems, etc and I've had the exact opposite. I'm not convinced school education is any type of [significant] indicator for coding and problem solving at this point.

At least this is what's happened in my own experience hiring. Not sure if there are any good studies done in coding proficiency and problem solving versus education (though I could see those being hard to measure well).

> You also said that you're hiring for an engineering position, but you seem to only care about coding. Perhaps I don't know what you mean by engineering, but I'm under the impression that there's a lot more to engineering than any single skill, even by the loose SV definition. How do your Ph.D. applicants do outside of coding?

Well, software engineering involves reading and writing code so that's a huge part of it with the other part being problem solving. Really the problem solving is the most important part, the rest can be taught with time. But essentially we had some very, very basic coding questions (not even trick questions) just to get an idea where the person was as far as their ability to write code. We didn't care what language(s) they knew (they could pick) as long as they could demonstrate some basic knowledge of coding and then problem solving.

Since we were hiring for software engineers, if a candidate couldn't write code in any language they were simply not moved to the other interviews. Not much we can really do there.

Speaking as a Ph.D. (not software or computer anything but traditional engineering), I think you're conception of what a Ph.D. signifies is very wrong, and it's leading you to improperly value what advanced academic training is worth.

Software engineering encompasses the SDLC, which includes a lot more than coding. What about documentation, quality control, or formal methods? There's many roles that I would expect a Ph.D. to be likely to perform well in, more so than someone self-taught. Seems like you're ignoring the bigger picture.

I think we programmers tend to see coding as akin to reading, if you can't code you don't even get the chance to get into other stuff because you're missing the most basic skill of software engineering, the ability to make a computer do what you want it to do. No one interviews for "software engineer" and wants someone who can barely code, writing code is virtually always the number one requirement of the job.

If fact when I hire, I require a small programming project be completed (simple, save some objects to a file and read them back out passing this unit test), that is the resume, if you can't code I won't even look at any other credentials. Rookie programmers with only a few years experience often do far better at this task than people claiming a decade of experience. The most experienced people often completely fail the test.

> I think you're conception of what a Ph.D. signifies is very wrong, and it's leading you to improperly value what advanced academic training is worth.

The job requires being able to develop software. Candidate, who holds PhD, cannot develop software despite being a CS grad. This isn't charity; what would you prefer I do when I get such a candidate? I saw two PhD holders like this which, yeah, could be a HUGE minority but I'm being honest about how anecdotes can create bias and I also mentioned that I felt I did a great job not using my bias against them (we all have bias, remember).

Not knowing the language we use in house? Not a big deal. But if you can't demonstrate fundamental understanding of code structure in any language I'm sorry but I do not have the budget to educate you. I wish I did sometimes; someone who has awesome problem solving skills could be an amazing developer.

> What about documentation, quality control, or formal methods?

No offense but when shit hits the fan, none of those matter. At all. Unfortunately. Plus I think it's good when you make developers think about and do as much of the documentation of their own code as possible. Sometimes seeing it on paper can make you realize "hey, this is too complex to call; I think I can simplify!". At least in my experience anyway. QA / QC, yeah separate group is idea but rarely doable depending on your industry.

> Seems like you're ignoring the bigger picture.

Again, business is not a charity. Big businesses or academic arenas can afford more things but start-ups / small companies? Anything that isn't moving the product out the door gets slowly trimmed away as margins get leaner. It's far worst in the government contracting space where you're legally allowed to only have a certain amount of margin.

A PhD program basically produces a researcher who is the world's expert in a very very narrow area of a subfield. As a job candidate, a PhD holder could offer, in descending order of "putting their degree to use", A) their subfield specialty, B) their ability to work as a researcher, C) being a smart human.

If you're interviewing a PhD for a nuts and bolts software engineering role, you are basically hiring on the basis of C, ie their degree is a dubious value add for you. PhDs are rarely going to be an ideal hire for a startup unless their subfield is literally the core of your business.

As an aside, I am bewildered by the the idea of a CS PhD holder who literally cannot code in any language. But short of seeing their CV, who knows. Maybe they specialized in the more theoretical math- or EE-like areas of CS, and their undergrad data structures course was a distant memory?

> As an aside, I am bewildered by the the idea of a CS PhD holder who literally cannot code in any language. But short of seeing their CV, who knows. Maybe they specialized in the more theoretical math- or EE-like areas of CS, and their undergrad data structures course was a distant memory?

One mostly did neural network research and said his coding was rusty so he has having issues. The other I honestly can't remember. But yeah I'd assuming coding was pretty important but I kinda got the impression from both of them that maybe they had underlings do the grunt work or something. But not entirely sure.

Reply on news.ycombinator.com