Hacker News Reader

Comment by allan_s | Hacker News Reader

I can't agree more, when interviewing I always ask this kind of questions of "theoretical knowledge" not to have the actual answer, but to see how candidates reacts when they don't know. Because if the guy not only admits he does not know directly and is eager to know what it is briefly, then you know that giving your team and environment is favorable to learning, the guy will soon be able to catch up, and it's certainly the same guy that one day will bring in the team's "tips and tricks" channel an article or an insight that will make the team's knowledge grow too.

View on HN

How can anyone applying for a programming job not know Big-O notation? That's CS101. I don't care if you're self-taught, it's audacious to even call yourself a programmer if you don't know the very basics of algorithms and data structures.

If I were interviewing a candidate, and it was revealed he didn’t know Big-O notation, my next questions would be about data structures, because now I’m suspecting he wouldn’t even know how to implement the simplest of structures. What next, simple pointer arithmetic, is he unable to even walk an array?

We are no longer talking about a programmer then.

Not knowing these things, I usually chalk it up to either laziness, or lack of interest in understanding how things work.

Either way, that’s not someone I’d want on my team. Programmers should be enthusiastic about fundamentals. Good programmers have a “hacker” mentality, a need to know and understand inner workings, a craving to dig deep. I’d say this mentality is what you want from anyone in STEM.

I started off disagreeing with your statement but as I read further, I became a believer. In fact, "gotcha" and other trick questions are the worst, but understanding CS fundamentals shows that you were paying attention in class and are probably interested (if not passionate) about CS.

If not, there are hundreds of other openings that the candidate can apply to.

How can anyone applying for a programming job not know Big-O notation? That's CS101.

You pointed out exactly how someone would not know -- they may have never taken computer science classes and taught themselves programming.

Or they may have taken some CS classes, not enough to have covered that particular concept.

I'd guess that, especially for older programmers, anecdotally, it's not uncommon to not really understand or use it.

I don't care if you're self-taught, it's audacious to even call yourself a programmer if you don't know the very basics of algorithms and data structures.

Just because someone doesn't use the same terminology to describe a set of concepts doesn't mean they don't understand those concepts.

Also, I wasn't aware there were were formal qualifications for someone adopting the title of "Programmer", pretty sure big-O notation isn't part of the dictionary definition.

But still you had to hear about it sometimes, somewhere, it's mentioned in pretty much any serious text on algorithms. Thing is that many people see it mentioned, but never bother to stop & learn what it's all about... and that's telling something about their approach to programming (and life) in general.

Sorry, but, it doesn't tell you anything.

The world of computers is full of things to learn about, more than almost any one person could learn in a lifetime.

People usually learn about what interests them, or what they need to know. It's entirely possible to be an accomplished programmer and never really learn big-O notation just as some programmers never learn assembly or C.

Think about it differently, big-O wasn't widely discussed or well known until the 1970s, thanks to Donald Knuth who popularized it. Then consider that many programmers who learned programming may have done so before it was widely known and some may have learned programming from those same people.

Are those programmers from roughly 1980 and earlier any less a programmer because they weren't aware of or didn't use big-O notation? Of course not.

Is big-O notation something most programmers should consider learning? Yes. But we should not seek to exclude others from a profession simply because they don't meet arbitrary criteria we think is necessary when they are clearly already actively engaged in that profession.

I've been programming for 25 years and never had a class covering big O notation.

Thank you. As someone who is tangentially connected to software (I'm a mathematician who sometimes intersects with CS/software), the anti-intellectual attitude of some software people is really baffling.

You're working in a field that requires you to use your brain, learn new stuff regularly, and solve problems. Isn't being ignorant of the fundamental concepts of your field a massive red flag that something is wrong?

Depends on the role, for junior devs my company doesn't care if you have ever programmed before. If the person is clever, we can teach them to program. For example, the most recent hire has a masters in maths from oxford, he may have never seen Big-O, but he could certainly understand it if need be.

> simple pointer arithmetic

Because pointer arithmetic is so vital to being a programmer in Python, Java, Ruby, JavaScript, ...?

Personally I know most of these things. I'm mostly self-taught. I looked into C++ at some point. I took some university courses. I've also been programming for a decade and a half (I'm 31, made my first website around age 10 and later picked up PHP before moving on to other languages).

But in my entire career there was not one point where I needed to implement a sorting algorithm myself. Or where I even had to know the difference between the various sorting algorithms. There have been a handful of situations where I needed to implement some kind of tree structure but very few moments where I benefited from knowing the difference between a list, an array, a stack or a queue (other than the different APIs in the standard libraries).

You are right that someone who's sufficiently interested in how things work will likely teach themselves these things even if they're not relevant to their work. But there's only so many hours in the day and not everyone shares the same interests. I have a basic understanding of several programming languages I don't use, including C/C++, C#, Prolog, Erlang and Haskell. I know many but not all of the concepts that make them different. I understand the general idea behind how assembler code works, formal logic, TCP vs UDP, endianness, binary representations of numbers, even some basic electrical engineering (I've played with Arduinos and shift registers). I also have a basic understanding of state machines, neural networks, genetic algorithms and all kinds of other stuff that will probably never be relevant for most of my work.

I'm a full-stack JavaScript developer these days so I also have some rudimentary knowledge of design and layout (color theory, spatial relations, typefaces, accessibility, etc) as well as database operations and Linux system administration. I know my limits -- I'm not a designer and I'm not a sysadmin and I feel more comfortable working together with them knowing they have my back.

I'm fully aware I have a broader knowledge when it comes to software development than most people I've had the fortune of working with. But I'm also fully aware that they often not only have deeper knowledge on any given subject than I might have but that no matter how broad my knowledge is it's incredibly likely that I have knowledge gaps in topics they might be taking for granted.

We like to stroke our ego and brag about the "hacker mentality" and how hackers are superior because we want to know everything (implying we can know everything or at least more than others). But knowledge isn't simply defined as a quantity. There are very few things that are essential knowledge to be a programmer and even they are debatable.

Calling people "not real programmers" is bullshit posturing. Software development is an incredibly broad field and no matter how good you are, you can never have expert knowledge of all of it (and even claiming a working knowledge in all of it strongly suggests your overall knowledge is so shallow as to be useless).

I've seen this kind of elitist bikeshedding over the definition of what is a "real programmer" since I wrote my first line of code. JavaScript is not a real programming language because you're "just scripting the browser". Shell programming is not real programming because it's just the interactive command line. Dynamically typed programming languages are not real programming languages because you can't write serious software in them. PHP programmers aren't real programmers because PHP is only used by amateurs. And on and on and on.

You know what? If I see someone applying for a programming job who doesn't know pointer arithmetic, I don't care. It's just pointer arithmetic. They can still learn that if they have to. Instead I focus on what they DO know. Maybe they come from a strong math and logic background and can optimize the crap out of our code. Maybe they come from a design background and can spot deep flaws in our fundamental assumptions. Maybe they have intricate domain knowledge and can us help make a product our users actually want.

Yes, if you apply to a senior C++ developer position and don't know pointer arithmetic or can't implement a linked list, you're probably not a good fit for the position. But flat out dismissals based on bullet points are bullshit.

Yep, have to agree with this. People who don't know big-O notation (and other CS fundamentals) are the ones gluing together libraries and code built by people who do. Now there's nothing wrong with that; there's enough work to be done for all of us. However, it's not something to crow about either.

Reply on news.ycombinator.com