Hacker News Reader

Comment by jobu | Hacker News Reader

"15% dislike academic CS (and think that talking about CS is a sign that a candidate will not be productive)"

That seems really weird. Academic CS isn't really necessary for most programming jobs, but I can't see how it would ever be a detriment.

View on HN

I had a guy work for me that was very academic minded regarding programming. He had a hard time letting go of the "pure" way of doing things and taking a good/practical approach to just getting stuff done. It can definitely be, but won't always be, a detriment in my experience.

That's a mindset flaw, not one that can be attributed to having CS knowledge, or enjoying talking about academic CS.

This is exactly true. There are certain things about which you absolutely need to be anal about being pure, such as scientific experiments and theoretical deductions/proofs. And there are others where you need to be more practical. This one person seems to have been applying the same mentality to both, which is a personal flaw, not solely a result of having more academic credentials/experience.

I like how you discriminate against CS knowledge in general because a single person couldn't get stuff done.

What you've described is someone who follow some practices religiously. I don't see any correlation between people like that and ones with academic background.

I'm afraid academia may produce religion. After all, it's a place where they show you a bunch of tricks, you practice them in simplified applications and then risk leaving with a belief that you actually understand shit.

A recent example: https://news.ycombinator.com/item?id=14267555

I've worked at places where well-meaning 'just get stuff done' people created mountains of technical debt that hobbled the project in the long term. Made them look great, though.

Great programmers should hopefully recognize and implement a proper balance between practicality and rigor, as necessary. They should also exhibit self-awareness and self-restraint, which sounds like the real problem for the guy you mention.

>I've worked at places where well-meaning 'just get stuff done' people created mountains of technical debt that hobbled the project in the long term. Made them look great, though.

Those people were just getting a bit better at building things. They were building experience. It just so happens you found their bad code that they'll realize was terrible a few years from now.

We can't simultaneously hate our own previous code and expect everyone else to delivery perfectly when they first start (or even at mid-level).

anecdotally, I see a higher-than-normal correlation between those who are "more theoretical" and those who cannot adapt to change or differing situations.

There's also an immense cost to not having CS fundamentals in terms of performance and wasted time; I don't want to pay someone to try and solve a version of the halting problem, or matching opening and closing delimiters with regexes.

I have a CS degree from CMU, and I've only run into that sort of attitude once. The interviewer nit-picked my solution to some character array manipulation question. I didn't get an offer. The interviewer wrote some snarky comment on his Twitter the day after my interview; something about "the difference between a computer scientist and engineer". Six months later his company was bought and chopped up. He got laid off. Karma's a bitch.

Conversely, I've been hired, without a formal interview, twice merely for having gone to CMU. I guess it can work out either way.

In senior positions CS knowledge is less relevant day-to-day, because your experience overrides a lot of that theoretical stuff. However, whenever I apply to companies, the questions about basic CS usually result in me turning down interviews. It would be a poor use of my time to memorize that stuff again only to not use it beyond the interview.

I guess it depends on whether you want to agree to that stupid system. When I interview now, I rarely ever prepare, and I'm completely honest with the extent of how much I remember and don't with the interviewers. If, on learning this, they think of it as a deal breaker, I think its a good thing for both of us to not be working together. However, if they don't judge me, but are willing to provide that information and work with me on the solution, I am fine with it.

I had a really bad experience with this recently, where I had a final interview which went really well in 3 out of 4 interviews. In one of them the interviewer was expecting a very specific solution, and I believe that I said something like, sorry I don't exactly remember how tries work, and I believe that is what resulted in no offer.

At first I was disappointed greatly, since it seemed like a great opportunity, and I had a great interview and experience with the other 3. But in hindsight, I realized I would really not enjoy working with this person every day.

It’s a loss for any interviewer to let pedigree bias them one way or another. If you’re willing to be interviewed, then they’ve got a pretty good opportunity to make a much more informed decision than letting their bias do it for them.

I'm not sure I'd want to work at a place that was hiring me based on just the school I went to. Similarly, I don't want to work at places that screen on irrelevant "CS fundamentals", because some of my favorite developers to work with would never be hired there.

I think it's largely just human nature. People don't know what they don't know, and those who "make it" without college are often particularly disdainful of academics. They may also be hesitant to hire those with a deeper background (which is a general phenomenon in many areas). In many fields, the percentage who can "make it" without higher education may be higher, but it's certainly do-able in our industry -- especially if they stick to a certain kind of software. Someone in this position may develop a real knack for avoiding hard problems (in the computational complexity sense) without ever quite realizing that is what they are doing. I almost didn't go to college, since I thought I knew it all, and had plenty of offers when I graduated high school. One of the most general things I learned was how much useful stuff there was to know, that I would have never fathomed.

In my experience, people are often hesitant to hire people who are higher on some (perhaps tacit) measure of nerdiness. Only when people want to win badly enough and it's clear that others are doing better, will many people start questioning such biases.

Too much focus on academic topics is likely a sign of inexperience. If the candidate had good real-world experience, they could (and should) speak of practicalities instead of theory. If the explanation involves a reasonable amount of theory, that's all well and good, but too much is an orange flag because it signals inexperience. It may also signal a propensity for dwelling on theory instead of Getting Things Done(TM). Companies almost always favor iterative execution of imperfect systems over protracted theorizing/analysis.

Depending on context and delivery, overfocus on academics could also be interpreted as snobbery, giving an impression that the candidate is difficult to work with, or that they think less of potential colleagues who don't have the same formal training.

Huh? Being experienced does not mean you stop liking the theory. If nothing else, more experience makes you appretiate a lot of it more.

It's not about "liking" theory. It's about talking about issues as theory as opposed to practicalities. You can like theory as much as you want, but if you don't talk about the real application, people will assume you've gone to class but haven't put it into practice.

It is interviewers job to get rid of illogical assumptions like this. This particular assumption is odd, experienced people often moves to talk about theory - sometime literally because they expect interviewers to be interested in that.

I don't think it's odd. The article says that 15% of Triplebyte's clients dislike it when things get too theoretical. Absent other signals, veering deep into theory on the assumption that interviewers generally like that is clearly the wrong idea.

My experience is that most people are happy to leave school behind, and they invoke theoretical concerns only when they are applicable and relevant. People want to hear about you've built and what you've done, they don't want their compsci textbook recited back to them.

If a candidate only has heavily academic projects, or can only discuss projects in heavily academic terms, interviewers may assume that the candidate is either a student or a researcher, and in either case, that person is probably not a fit for a conventional programming job (but they may be a great fit for a much cooler job in R&D somewhere).

Some companies really value an intensive academic background, but not all or even most of them (the article says that only 40% "need to see" academic CS skills, 15% actively dislike overt CS discussion, and that leaves 45% that didn't respond or don't care or whatever -- 60/40 split that talking less CS is at least harmless if not beneficial).

The takeaway, IMO, is to keep things at the high level, and stay focused on real, practical experience until prompted otherwise.

Guess I Am lucky that I meet good programmers who were not above theory and continually keep themselves informed. Contrary to what you write, there is no dichotomy between the two and your coding skills are not harmed by learning theory or keeping interest in it.

I also think that if knowing something harms me in the eyes of the company, then I do not want to work there. Such environment must be demotivating for learning. And i need to continuously learn. It is ok if they don't care and it is awesome if they are interested in different things that me (I can learn from them). Especially if we are talking about small companies where people who interview you reflect wider culture. Working in environment where people sort of punish you for knowing things they don't know is road to mediocrity. I want to work with collegues that will motivate me to learn - that is super important in length term.

So that leaves 85% of companies where I can talk about theory and not be harmed at all.

You're continuing to conflate knowing theory with focusing too much on theory in the interview process. I don't think anyone begrudges candidates for knowing theory. It's when their answers are primarily theoretical instead of primarily practical that the issue comes into play.

> You're continuing to conflate knowing theory with focusing too much on theory in the interview process.

That sounds like the social skills issue. If the interviewer signals change of topic is needed and interviewee does not follow, you definitely know the person has limitation in the social skills area. Also, if the person can not talk about practical aspect, they can't.

However, "15% actively dislike overt CS discussion" does not suggest companies that merely wanted to talk about practical aspect and could not. It suggest companies that are hostile towards people who attempt to talk about theory - talk about it too much and you are primary theoretical despite being also capable practicaly.

In any case, I do not want to work somewhere where I am expected not to talk about what I know (beyond the normal "don't have long monologues they areally not interested in"). I want my collegues to talk about what they know too.

>Academic CS isn't really necessary for most programming jobs

Knowing how to code quicksort or reverse a binary tree isn't, but an understanding of normalization definitely is...

No. Source: I have worked for a financially successful company whose database was designed without any notion of foreign keys or surrogate keys. They also had serialized Java objects in database blobs by accident.

I've worked for several like that. The blob antipattern isn't uncommon.

I always use normalization/database design as an interview question. I firmly believe that good questions about database design can really identify the candidate's skills and weaknesses in this area:

- it works well sitting around a whiteboard, which is a nice friendly dynamic that emulates how we really work

- it doesn't require detailed/arcane recollection of specifics, is more conceptual. Who wants to fail someone because they don't remember a parameter or some specific details of how TreeMaps work?

- it can't be faked - no-one can talk their way through a database design discussion unless they really have an aptitude for it

- its interesting. Who doesn't want to spitball around, say, modelling what Uber's database might look like behind the scenes.

I would say there are plenty of decent programmers around who can't (or haven't) done any real database design work, but if its a core skill (SaaS app development) that you really need, then its an easy one to detect at interview.

Since people in this thread are trotting out the old "we have to FizzBuzz people to weed out the millions of fake coders" argument:

Remember that FizzBuzz was originally proposed as a response to the number of CS degree holders who allegedly could not code their way out of a paper bag.

I don't care if someone can derive the hierarchy of Turing degrees from first principles. I care if they can do the job I'm trying to hire for.

I think we all know people who are very detail oriented and will argue ad infinitum about minutiae, but don't actually get a lot done in a speedy fashion.

I imagine they correlate an over interest in CS concepts with said group.

It's clearly a detriment to the hiring process: a bunch of academic CS minded types are the ones who set these absurd CS trivia interview questions.

Reply on news.ycombinator.com