How necessary are the programming fundamentals?

https://swiftrocks.com/how-necessary-are-the-programming-fundamentals.html

by rockbruno • 5 years ago

118 112 5 years ago

Emigre_2• 5 years ago

A knowledge of the fundamentals shows an appreciation of programming as an academic discipline, and it shows an interest on its academic (theoretical) foundations. And it requires effort and intelligence to master these topics, which is a good sign. To me, personally, it makes sense to ask these kind of questions about the fundamentals.

samsquire2• 5 years ago

I can write btrees, radix trees etc but I cannot always solve problems on a white board. I'd rather take a problem home and work on it.

I'm against whiteboard interviews

LorenPechtel5• 5 years ago

I've been writing code for 40 years (admittedly, not all of that time was writing it professionally), you say "btree" which to me could be a binary tree (which I've dealt with in the distant past but not for a long time) or balanced tree, something I've read about but never had the slightest reason to implement. I can't even recall ever hearing of a radix tree.

You go dig up the specialized stuff when you need it, it's not common enough to be worth learning in general. What's important is enough foundation to understand the answer when you look it up.

samsquire2• 5 years ago

I am interested in database internals. Btrees come up with regard to designing database systems that are efficient to query on disk. Postgres uses them for its indexes. Radix trees are memory efficient tries which are useful for answering prefix queries. They're also called prefix trees. I use them to get a list of prefixes of a string. Useful for simple intellisense style forms or dynamodb style querying. I've also been studying LSM trees which are used in Leveldb and RocksDB.

I experiment with database technology in my experimental project hash-db https://github.com/samsquire/hash-db The code should be readable.

I need to change my search tree to be self balancing currently it grows to the left or right without balancing. I think I need to use tree rotation depending on which branch has the highest height.

lordnacho2• 5 years ago

I think people certainly need to understand that DS&A are a thing, and time/space complexity is a thing.

The problem is the way they test for this makes no sense. At most having done DS&A will flash some lights in my mind when an n^2 or higher solution comes up, ie I will think about how to do it better. But that thinking will inevitably lead me to google for a better answer, rather than plumb my limited memory capacity for how to do it. So it's a principle that relies on the right tools to get implemented, and that's rarely what anyone asks for in the interview.

More than anything else I've ever done, coding is an exploration. And nobody seems to test for that, they seem to all test for whether you've already been down a certain cave, recently. For instance, I can write a mobile app that trades stocks on an exchange through a server. I could write both the apps and the server for you. I've literally done all the bits that you would need to do this. If you ask me some random question about Swift or C++ syntax, I will fail. Because having those in my mind's cache is not sensible. Knowing that sorting is probably already a solved problem, or knowing what the unsolved problems ahead are, those are useful.

The real thing you need to do as a programmer is to handle complexity. Not in the big-o sense, but in the sense of keeping the mess of code a sensible size, in a way that allows you to make future changes easily, and allows collaborators to contribute easily. This is both a code thing and a people thing. Yet I don't come across a lot of people asking about how this is done.

username905• 5 years ago

More than anything else I've ever done, coding is an exploration

The fundamentals of exploration is the ability to traverse different types of obstacles. In programming those obstacles are traversed by being creative with algorithms. Therefore companies test you if you can be creative with algorithms.

Of course if you have never done that then you don't see it as exploration but instead tedious nonsense. So at least in my eyes anyone who sees these things as just tedious nonsense are self filtered out, why would you want to hire people who have never tried to be explorative in this field? Them not applying in the first place is great!

emteycz• 5 years ago

Being creative with algorithms is different from carrying algorithms in your head..

carlmr2• 5 years ago

Exactly on point, which is why for interviews I like to discuss code snippets. Asking what's wrong here, is this the right collection type to use here, what would you do instead, how would you refactor this.

I do like to ask algorithmic questions, but I don't expect the algorithm in detail. Instead I want to know if people understand when to use it, and what is the principle behind it. Because while you don't need to implement your own collections, you should know what their advantages and disadvantages are.

tzs• 5 years ago

> More than anything else I've ever done, coding is an exploration. And nobody seems to test for that, they seem to all test for whether you've already been down a certain cave, recently
Exactly on point, which is why for interviews I like to discuss code snippets. Asking what's wrong here, is this the right collection type to use here, what would you do instead, how would you refactor this

LeetCode can be great for both of those--but not the way most interviewers use it.

Instead of using it as a source of problems to throw at someone and expecting them to produce in short order a working, correct implementation, use it collaboratively with the candidate.

Pick a problem, read it with them, and discuss possible approaches. Try to let them take the lead on this, nudging them as needed to keep them going in the general direction of a viable approach.

When that is done go to the discussion area for the problem. There people post all kinds of purported solutions. Go over a few of those with the candidate, critiquing them together. Plenty of the posts will contain errors, ranging from minor to severe, providing plenty of points for discussion.

kfreds• 5 years ago

Yet I don't come across a lot of people asking about how this is done.

Please elaborate! How do you handle complexity?

lordnacho2• 5 years ago

You can see how people explain what they do. Does the explanation itself become massively complex? Is there a reasonable high level explanation, or is it a mess of ifs and buts?

As for actually keeping things clean there's any number of things that can be mentioned. Reasonable abstractions, issue tracking, version control, documentation, choice of frameworks, and so on.

mujina93• 5 years ago

Once I was interviewed in this way: I was given a test with various questions (algorithms, general knowledge, etc.), and I was given a tablet with which I could google whatever I wanted. I was left alone with the test and the tablet and I was given some time to finish that.

I think it's one of the best way that I've ever witnessed or heard of to test for what you mention: the exploration and research that happens in real life when you encounter a problem to solve at work.

I haven't seen this anywhere else unfortunately.

Mauricebranagh2• 5 years ago

Surly the fundamentals of programming are converting between binary, octal hex by hand basic set theory, the standard control structures etc.

Bad analogy with music theory though at the super high end it gets more about the theory than the actual music.

Most musicians are not going to be using exotica like Xenharmony

nowherebeen• 5 years ago

music theory has also an implicit application, which is that people who learn music theory become better musicians in general. Even though the person might not be composing their own songs, their understanding of how music works likely makes them extremely comfortable playing and improvising any kind of song.

I think the author is trying too hard to draw a correlation between algorithm and programming. Knowing algorithm doesn't mean you implicitly know how to program.

He is also ignoring the masses that simply memorize the answers without knowing why a specific algorithm is used. Most will freely admit they can't remember these fundamentals after a few months. I don't blame them though because you are expect to give the optimal answer with a snap of a finger in interview. All those interviewers that argue they want to understand the thought process of the interviewee are simply lying to themselves. Some of them are even browsing the internet while you solve the question.

The real reason large companies use algorithms is because too many people apply for a job. Many are equally qualified and they need a way to justify their hire. 200 applicants in 1 hour for every single job.

The real sin are startups that think they are Google and use the same interview process to feel better about themselves. I have seen more than a few interviewers with a chip on their shoulder at some no-name startup.

yesenadam2• 5 years ago

Also, a lot of the sentences on music here are just not right. Jazz musician/composer here, who knows most of what music theory there is to know in a few genres, which is not much. Most of the musical knowledge good musicians, improvising musicians at least, have, is private and unique to themselves, or stored in their bodies and muscle memory and even they don't "know" or understand it, they can just play. "Music theory" just doesn't take you very far at all. Shakespeare couldn't have explained what he was doing or how he did it, nor could Hendrix. They just could do it, natural as breathing, or like walking, which people can usually do without the help of theory or being able to explain how.

Even though the person might not be composing their own songs, their understanding of how music works likely makes them extremely comfortable playing and improvising any kind of song.

Understanding music theory doesn't make you comfortable playing and improvising at all. Being able to play an instrument and improvise makes you comfortable doing that, which comes from doing them a lot.

if the person doesn't know the theory, it's likely that these songs are going to be hilariously bad.

No, the songs of people who don't know music theory aren't hilariously bad.

To make it worse, musical progression is not a thing you just come up with -- songs aren't random, the chords for each song have a theoretical relation to each other. Making a decent song is a science, and one can learn it by understanding the theory.

But a chord progression or melody or lyrics are often a thing people just come up with. Writing songs is in no way a science. You can't learn "making a decent song" by understanding music theory. The characteristic, memorable, wonderful moments in each song are usually the unique, irregular ones, about which there is no theory. Etc etc.

danbmil992• 5 years ago

Lifelong musician and programmer here. It's an interesting analogy actually.

I learned music by ear, then learned Theory. Then I found I had to forget some of my theory to get back to writing songs that felt right to me.

I experienced a similar arc in programming. Starting out self-taught, I absorbed the theoretical aspects later as I worked on problems that were higher level than just writing code.

In both cases, I think the theory is more descriptive than generative. Both programming and music require combinations of creative and Technical mastery to achieve a high level of competence. Theory can help you with the technical aspects of the craft. More than anything else, it gives you tools to analyze work that others have done. What Theory cannot do however, is give you the gift of creativity. That has to come from within, and I don't think there's an easy way to teach it in a book, or measure it in an interview.

Mauricebranagh2• 5 years ago

Just thought with the analogy with music is there a market for Fake/Real Books for developers.

jackblemming• 5 years ago

There is a large difference between having a decent grasp of the fundamentals, and being able to regurgitate parts from pure memory while being grilled by the interviewer in a high stress situation. While we may like to think the interviewee is an idiot who doesn't understand what a tree is, they may just be under a lot of pressure.

This article comes across as tone deaf and unsympathetic to me.

LorenPechtel5• 5 years ago

I think the right answer is something of a middle ground. You need to understand the theory, but at an abstract level. Unfortunately, that can be pretty hard to test for. Companies are making the same mistake teachers make in college--testing by asking for regurgitation of details. You need to understand the forest, knowing individual trees is unimportant. Look at the concept of cramming for an exam--memorizing details, not understanding. You can't cram for a truly well-written test.

LaundroMat• 5 years ago

What are good introductions to Data Structures and Algorithms for a hobbyist developer?

satysin• 5 years ago

Coursera and many similar online resources all have good DS&A courses.

Check out https://www.coursera.org/browse/computer-science/algorithms or just search for free courses, they all cover the same things so just find one you like.

Emigre_2• 5 years ago

MIT Press ‘Introduction to Algorithms’ by Cormen et al. is an excellent book to learn although it is perhaps not an easy and accessible introduction; it’s academical and extensive. It would require time and effort. Maybe other options are better, like a Coursera course, if you want to get a superficial taste of the topic instead of a more in-depth exploration.

nwb• 5 years ago

I've been slowly making my way through a course on udemy, in Javascript, focused on DS&A - https://www.udemy.com/course/js-algorithms-and-data-structur.... I've been developing for 10+ years, mainly on Frontend, but it's given me more confidence in how I approach writing code.

ChrisMarshallNY6• 5 years ago

As someone that was almost entirely self-taught (started as an EE -also heavily self-taught), I’ve looked up many, many noses. One of the manifestations, is that I often don’t know the “official” name of a pattern or the “standard” way to do something, despite being quite good at it.

So I don’t do things the way everyone else does it, and I often fail to deliver or comprehend industry jargon.

But I have been shipping software for my entire adult life. I have an extensive open-source portfolio of extremely well-executed projects that anyone can clone, build and incorporate into a shipping project without worrying about quality or performance. I have had to deliver the goods -in public, and under a microscope- since I’ve started.

I’m highly disciplined, and have been working on large, heterogeneous teams, my entire career. These days, I work alone, or in small teams. Not by choice. Working for a Japanese corporation for 27 years, means that I am very used to hard taskmasters. I’ve had my feelings hurt more often than many.

So I’m used to backing up my rhetoric with deliverables, and watching those deliverables get inspected, criticized, rejected, and improved. It’s made me take Quality rather seriously. It’s also made me quite aware of schedules and deliverables.

Q. C. D.

I’m not particularly competitive, and don’t especially care whether or not I’m “better” than anyone else. I’m used to being the dumbest person in the room (I spent most of my career, working with some of the best engineers and scientists in the industry).

So I work well in teams, know how to bite my tongue, and listen.

Every single day -every single day- I start the day with some scary, insurmountable issue that needs to be solved, or the whole project goes into the bin; and I solve it -often in an unintuitive manner.

So I’m fairly good at solving problems. I’ve been doing it since I was 21, and trained as an electronic RF tech.

I also have dozens of articles, sites, and documentation that I’ve personally written; often going into great detail about how I architect, troubleshoot, test, configure and release. I tend to write in the vernacular, which also means I come across as plebeian.

So I’m pretty much an “open book,” and I’m fairly decent at writing in an approachable, accessible, entertaining manner, as well as coding.

I’d have been happy to have had a more formal introduction to things, but that was not in the cards.

Also, since I’m constantly in “ship mode,” I have to stay focused on practicum, as opposed to theory and exploration. That slows down learning some of the cooler, more esoteric things.

Nevertheless, every day is a new adventure, and I am still learning new stuff, regularly. I feel as if my experience helps me to establish a context that makes learning easier, faster, and more comprehensive.

There’s a lot to learn, and I have miles to go, before I sleep.

teddyh3• 5 years ago

I often don’t know the “official” name of a pattern or the “standard” way to do something

So what you’re telling us is that you don’t communicate well, or at all, with other people. Other people who will, later, have to maintain your code.

ChrisMarshallNY6• 5 years ago

I saw what you did there.

That was cute.

Hey, here’s an idea…why don’t you check for yourself? All you need to do, is go to my HN handle.

https://news.ycombinator.com/user?id=ChrisMarshallNY

alkonaut• 5 years ago

This right here. We often talk about "Communication skills". This isn't separable from "being able to describe a problem or solution using standard terminology".

It's no less important to know what common things are called, than it is to know how common things work.

There is no brighter red flag to a than people who just "gets things done" or "solve problems in unorthodox ways", so a candidate who describes themselves as a problem solver that might not know all the "words" for it is to me a big red flag. This isn't gatekeeping or saying everyone needs a CS degree to be a decent developer. Terminology is a trivial addition to the skillset and ignoring it just means one doesn't care about communication.

tempodox2• 5 years ago

I often fail to deliver or comprehend industry jargon.

In my experience, that alone can act as a powerful blocker. Although I'm quite sure that the jargon thing is being used as a proxy for something more substantial, I doubt that it's a useful one. I suspect it's actually more of a social-group thing (are you “in” or are you “out”) than anything else.

One question about the “Q.C.D.”, though (quantum chromodynamics?). Could it be that you meant q.e.d. — quod erat demonstrandum (≈ “what was to be proven”)? Lowercase to distinguish it from the acronym for quantum electrodynamics.

ChrisMarshallNY6• 5 years ago

Quality, Cost, Deliverable.

The Japanese live by it. If you ever want to work with a Japanese company, it's a good idea to know it. I think Deming may have started it.

"Quality":

How do we measure the deliverable? Not just testing targets. Any form of quantification. Progress tracking goes here, as does a lot of things like CI.

"Cost":

What will the cost of the deliverable be? Not just money, but also schedule, the number of folks working on it, prototypes, BoM, progress meetings, buy-in from stakeholders, risk management, etc.

"Deliverable":

What will be delivered? Please describe expected deliverable, what will be delivered at milestones defined in (Q) and (C).

It's a very rigid process (good for hardware), but can be difficult to deal with in software. I've learned to do my own version of it. I've written about it.

BTW: I just demonstrated "jargon," but in a different way. I do not think less of you for not knowing it.

danbmil992• 5 years ago

TIL that Iron Maiden are masters of Music Theory

gfxgirl3• 5 years ago

I have not been tested on the fundamentals of programming taking interviews from FAAGM and other famous tech companies. Instead I've been asked "puzzle" questions that generally have nothing to do with the millions of lines of code I've written in the past nor anything to do with what I will do for the company. All those questions on leetcode are 95% unrelated to actual problems IMO.

95% of every web app, mobile app, or native app is just very basic stuff. How often do you need to be able reverse the first half of signally linked list? Or compute the most amount of water that will fill a vertical grid. Or find the largest rectangle in a bitmap. Or divide to giant integers. Or solve sudoku puzzles?

The interview should not be "can you solve a puzzle that took 50yrs of programming before someone noticed the solution". It should be "will you be productive on our team". I don't feel most tech interviews actually check for that. In fact I know several people who got through the interviews at the last company I was at (one of the top 4 tech companies) that were not productive at all. Sure they could answer the leetcode type puzzles but they couldn't actually get work done. Many of them were eventually let go when enough colleagues reviewed them poorly.

The article claims these interview questions test for fundamentals and I agree that fundamentals are important. I just don't agree the leetcode style questions asked test for that.

cjblomqvist• 5 years ago

To add: 1) The fundamentals of algorithms can be relevant, such as understanding that one solution is more or less computational (or memory) efficient then the next (and why), but I agree that figuring out how to do a certain a algorithm in a specific situation (usually quite far from anything the person will likely be doing) is rarely useful (unless that's the job, but that's rarely the case). There are more nuances to it, but that's the gist of it imo.

2) Fundamentals on writing maintainable code on the other hand is rarely focused on (AFAIK, I personally don't really have any experience interviewing with such companies) - even though that's usually something that is emphasized a lot in most people's jobs. Even more interesting is that, based on my experience (I've interviewed a significant amount of devs), devs are surprisingly bad at these questions and also quite often become defensive about those type of questions (very similar to how I imagine people become about algorithm questions).

I believe the industry would produce better solutions if we focused more on writing cleaner, simpler and more maintainable code - also in the hiring process (thus incentivizing the educational system to align with that) than our current algorithm focus.

jiggawatts3• 5 years ago

95% of every web app, mobile app, or native app is just very basic stuff.

But 5% isn't, and can absolutely derail a project.

I'm a consultant that goes to various orgs to help them with a huge variety of things, much of which boils down to fixing issues with "simple web apps".

I literally cannot remember the last time I saw any application, written in-house or by a vendor, that had even the basic set of essentially mandatory indexes in the database. I don't mean clever stuff like partitioning, or sorting tables by a column other than the primary key. I mean that most of these databases had no indexes at all on 100M row tables. Just a week ago a large software vendor argued with me, stating that it's absolutely fine to require 10 GB of parallel table scans to display one web form to one user!

That in my opinion stems from a lack of understanding of what a B-tree is, how it works, and how databases utilise it.

That's firmly in the "fundamentals of programming" that every developer writing "simple web apps" should know, and in my experience almost none do.

These people go about their work every day with a firmly held belief that the database server is essentially a magic black box that can never be understood.

Is that okay?

raspasov5• 5 years ago

No it's not ok. But the people who didn't add indices maybe even had all the basic training on DS and algos.

But they were simply either incompetent or more likely simply careless and didn't give a sh_t. Because adding indices in the proper places requires a few minutes of PLANNING. Who has few minutes nowadays, when you can read HN? On top of that their management/leadership was careless, and didn't give a sh_t. In the end, the poor database tables were left all alone, in the dark, without indices :).

bsder• 5 years ago

But 5% isn't, and can absolutely derail a project.

Precisely.

Do you know something about byte order? Can you set or reset a bit? Can you check that your if-statement conditions are exhaustive?

Those are from a second-year class in most CS curricula. And I have seen people programming for 10+ years screw them up. Horribly.

I have seen 10+ year programmers use "addition" for "logical or". And it works, mostly, until it doesn't. And it creates mysterious failures that they can't debug because they don't even have the concept that they need to hypothesize correctly.

Most of the people whining about this stuff are whining about whiteboarding things like "graph algorithms"--and they're right. That's a stupid thing to test for since you rarely use graph algorithms unless you use them every day at which point you'll come up the curve anyhow.

If I'm interviewing, I can ask really simple questions like the "set a bit" or "change from network to machine order" and still get the information I need. If you know the answer, that tells me only one thing--you've probably programmed enough that you hit it. I'll keep increasing the problem difficulties until you don't know the answer and have to think.

To be fair, if I have to wind the difficulty up to graph algorithm questions, you've likely already passed the interview long ago.

mewpmewp27• 5 years ago

Knowing to use indexes you should know, and I know it from practical experience, not from learning comp science or theory. However I don't know sorting algorithms top of my head and their complexities, since database does the sorting and heavy lifting underneath. This is the key difference.

When I have gone through FAANG level companies, I spent 2 weeks preparing and learning the fundamental theory, a year or two later I have forgotten most of this and I'd have to prepare like that again.

It's interesting and can be useful to go through the material on how database engine exactly works underneath, but you definitely shouldn't have to memorise this long after you went through the material and you probably won't use this information in your real life, except for the interview process, of course.

Pretty sure indexes are basic things you learn when setting up your database schema, and most ORMs provide very easy way to do that and go over it in their getting started section. They usually have indexes by default for ID fields and foreign key fields. I had no problems understanding having to add indexes to often queried fields and the trade off for having too many indexes. When I started learning how to actually use something like MySQL I had no clue what data structure indexes used underneath, but the concept itself is fairly simple compared to how b-tree works. The vendors you have met have been incompetent for some other reason as opposed to not knowing data structures.

gfxgirl3• 5 years ago

I agree with you fundamentals are important. My point was, leetcode and leetcode style interview questions don't test that. As an example I don't think there's a single "leetcode" question related to database indices.

q-big• 5 years ago

I have not been tested on the fundamentals of programming taking interviews from FAAGM and other famous tech companies. Instead I've been asked "puzzle" questions that generally have nothing to do with the millions of lines of code I've written in the past nor anything to do with what I will do for the company. All those questions on leetcode are 95% unrelated to actual problems IMO.
95% of every web app, mobile app, or native app is just very basic stuff. How often do you need to be able reverse the first half of signally linked list? Or compute the most amount of water that will fill a vertical grid. Or find the largest rectangle in a bitmap. Or divide to giant integers. Or solve sudoku puzzles?

I accept your point. But I do believe the much more interesting question to ask is: why do they do these puzzle questions instead of questions that are at least somewhat related to actual programming problems that might occur as part of the prospective job?

gfxgirl3• 5 years ago

IIRC their claim is they are trying to avoid bad hires more than skip good hires. I haven't seen any data though that their interviewing methods achieve those results. If I was to guess why they do it that way it's just because of momentum and lack of any "known" good alternative.

fatnoah• 5 years ago

I have not been tested on the fundamentals of programming taking interviews from FAAGM and other famous tech companies

I've interviewed at three of those letters, but as a senior manager, and I (somewhat ironically) better covered my nearly 20 years of writing code (as an IC, to use the parlance of the industry) than the interviews given to coders.

I could certainly solve hard coding problems when needed, but later in my career I was doing mostly system design, which is figuring out how to put all the bits together in a way that could be built modularly and operated efficiently. Another question from one of those focused on how to handle an actual problem that came up regarding migrating log analyzers when a simple cutover wasn't possible. In general, I love those kinds of questions because my experienced and knowledge come in to play.

It boggles my mind when senior ICs get dinged because they're not able to traverse a tree in the way someone wanted in 30 minutes while coding in a plain text editor on a video chat. IMHO, 5 minutes to install the correct package and write a couple tests should be sufficient so we can get the REAL discussion which is to talk about whether a tree is the right structure and what we should do about it if it's not. ;)

goto11• 5 years ago

So if you want to try out a potential new member of a band, the correct approach is to grill them on the circle of fifth.

galbar3• 5 years ago

Since I started interviewing applicants, my two favourite questions are:

a) What's the difference between an array and a set?

b) Describe how a hash table works.

The reasons are:

a) It is important to know the difference between ordered and unordered collections and I don't want to be in a position where I don't trust that my teammate will use the right data structure in their PR.

b) a hash table works with the same principles on which scalable services are built: database sharding, traffic loadbalancing (with stickiness), kafka stream processing, etc.

In my experience, those two questions are a good indicators on how the interviewee will perform in the rest of the interview.

nathias2• 5 years ago

Whats so terrible about telling someone to use an ordered collection in their PR?

galbar3• 5 years ago

Depending on the usage and how core it is to the problem we are solving, the architecture of the subsystem may be affected negatively by the wrong choice of data structure.

It is also not hard at all to learn and understand the difference of these two fundamental data structures.

Aeolun• 5 years ago

When hiring for frontend developers, I don’t think there’s any point to those questions.

If someone is not using the right data structure in their PR, that’s something we can remedy by means of a short discussion.

Same for a hash table. Describing why it is better for some things is quick.

The goal of the interview is mostly that I trust that someone will understand (and listen) when I explain things like this. Not whether they know already.

mtberatwork• 5 years ago

When hiring for frontend developers, I don’t think there’s any point to those questions.

Why not? Array and Set are both part of JavaScript.

galbar3• 5 years ago

When hiring for frontend developers, I don’t think there’s any point to those questions

I've been at a company in which the website had very slow performance because the FE did not know the differences between those data structures and did a O(n*m) algorithm to match elements from two collections (`listA.forEach(i -> listB.indexOf(i.foo))`). The backend returned JSON objects with the keys ready to be queried correctly and the FE converted it to arrays for some reason.

Nobody in the FE team realized this was a bad idea until someone complained about how slow the site was.

The goal of the interview is mostly that I trust that someone will understand (and listen) when I explain things like this. Not whether they know already.

It hugely depends on the expected experience of the role for which the candidate is being interviewed. I would absolutely expect a mid-level engineer to know those concepts.

ManlyBread• 5 years ago

I have been working as a programmer since 2015 and I'm not sure if I could answer these questions.

ZephyrBlu• 5 years ago

Why aren't you sure? These seem like straightforward questions for people with a little experience.

loup-vaillant2• 5 years ago

Some companies are sorely mistaken about what they actually need, though. I was once interviewed (and accepted) at a small company that apparently needed fundamental 3D skills. I ended up being grilled quite a bit about rotation matrices and the like.

The reason for this? They maintained an in-house 3D engine they use for various products they sell to important customers. What I only realised later was that a grand total of two people actually worked on that engine. The rest of us ended up just writing and maintaining large C++/Qt programs riddled with technical debt.

What they really needed were people who can wade through large code bases with significant tech debt. I wasn't interviewed for that skill however, and I happen to not be very good at it. (I'm especially bad at resisting the urge to fix tech debt that is currently hindering my own work, even though sometimes I have to let it slide because of deadlines.)

I didn't last long there, and learned later they weren't very good at retaining developers there.

morelisp• 5 years ago

I have pretty much the opposite of this story. I contracted with a company doing a fairly basic photo editing app, who had managed to code themselves into some godawful mess. Basic frontend changes took days or weeks because they had a handrolled layout / animation system from someone who had no idea you could a) specify complex motion of objects over time via linear algebra, b) sequence operations more easily by even just slightly reifying some state machines. Instead the whole code was full of hundreds of variations of "if picture.x != picture.goalX && picture.rotating { picture.x += 3; picture.angle += 1; }".

I have seen this pattern over and over, simple applications grown into complex unmaintainable garbage because they didn't have someone who could write a state machine, or a simple interpreter, or a constraint system. Or because they needed something small but reached for something big instead when they didn't know how to implement the small thing, e.g. a task queue that could've just been an array with locks around it instead turned into 0MQ (or worse, MySQL). And these are not companies with only interns/juniors, often people with 10+ years experience who think "fundamentals don't really matter."

loup-vaillant2• 5 years ago

people with 10+ years experience who think "fundamentals don't really matter."

Sounds like people who think "programming is not math".

Granted, it's quite unlike the math we were taught in high school. But it does have patterns, opportunities for simplification, similar correctness problems, and sometimes good honest Math™ with geometry, linear algebra, and more. One can easily miss that when they assume programming is not math to begin with.

Even if those programmers didn't know the fundamentals behind animation systems, they could have reached for those if they recognised that this part may have some significant math behind it, and sought out relevant material.

raspasov5• 5 years ago

Not an expert on Iron Maiden (I do enjoy various metal/heavy rock) but just a casual read through Wikipedia doesn't scream "music theory as the cornerstone of their success". A forced analogy that I think does not really stand on its feet.

I disagree with the premise that there's some crystal ball that those companies have which tells them that asking those questions somehow determines good candidates. It's more likely that it actually filters for the type of person who is willing to do his homework and has a good baseline of discipline and is willing to prepare. Which arguably has some value in itself.

I don't have a formal CS degree but I have studied and implemented data structures/algos and spent quite a bit of time (months) to make them performant inside a database. I can guarantee you that the knowledge that you will ask for in a whiteboard interview is way less than one percent of what's required to implement performant and practically useable data structures for use in modern programming languages and databases.

And the punchline is that it is all about the seeming minutia that the author is dismissive about. The reality is that the market for simple, generalist solutions in terms of programming languages and databases is zero. There's a ton of optimizations and literally HACKS (for a lack of a better) word that make real-world data structures and algos go fast. Just take a look here and tell me how many platform-specific things you can find (this is bulk of the implementation of persistent immutable maps for Clojure): https://github.com/clojure/clojure/blob/master/src/jvm/cloju...

Regular whiteboard datastructure/algo questions are nothing more than regurgitating 1970s theoretical solutions without much practical day-to-day value. Is there a hint of a knowledge you can extract by knowing them? Sure. Is it much more than that? I don't think so.

vbsteven• 5 years ago

One of the defining traits of Iron Maiden is their use of double and triple guitar harmonies. You could say they popularized the concept and many newer bands were inspired by it. My favorite Maiden song section is the solo/post-solo part in Brave New World (live at Rock in Rio 2001). I think the success of Iron Maiden comes from the combination of theory, performance, lyrical content, image, live ambiance and a very charismatic frontman.

A better example of a band with music theory as the cornerstone of their music is Tool. I keep discovering new things in songs like Schism even after listening to them hundreds of times.

raspasov5• 5 years ago

Thank you for the informative explanation!

username905• 5 years ago

Software Engineers aren't equal to Software Engineers. What different subfields require is so different, some are fine with bootcamp grads and for others they absolutely need most of it. The confusion stems from still using the same job title for those vastly different jobs.

SilurianWenlock2• 5 years ago

What's the hardest area?

Have you got a list from easiest to hardest areas?

hnfong• 5 years ago

There are so many dimensions of skills related to software development that it's really meaningless to compare which areas are "easier" or "harder".

Some people are better in some areas, and it's usually a combination of time invested and talent.

djipko• 5 years ago

Most companies that people put up as examples of asking "fundamentals" that are unrelated to the job, actually don't at all ask candidates to regurgitate fundamentals. Instead they ask them to solve a programming problem, which commonly requires them to apply their knowledge of some very basic fundamentals. This is very different. "Very basic" is important to note here, because almost no companies nowadays ask anything other than very basic application of common data-structures. If we are sticking to the music analogies - this is closer to asking a musician to perform a well known piece of music from a sheet than regurgitate esoteric music theory.

The performance part might be a problem for some people and I agree - programming is not music, and it's tricky and unnatural to program in front of an audience, but this is a completely learnable skill by practice. That said I agree that it will always penalise a subset of people who will always perform less good under pressure.

There is a flip side to this though which often goes overlooked and author hints at it: programming interviews are a great equaliser - there are no credential checks (or they are getting much less common) for getting into top companies, and you can be based almost anywhere in the world - all you need to do to get in is crush the coding interview which is totally a learnable skill. This has opened many doors and economic opportunities for people that did not have them even a decade ago, and I think we as an industry don't talk enough about the opportunities our attitude to barriers to entry create.

Finally there's the question of whether the skill tested in coding interviews are really unrelated to the job performance. I've seen arguments that state: "some data shows that how a person performed on the interview is unrelated to how they perform as an employee". But this kind of reasoning almost certainly suffers from selection bias, as we'd really need to include how people who did not pass the interviews perform at the job (for obvious reasons companies don't have this data). I would bet that there would be a much stronger link with interview performance in that case.

Overall I think it's more likely that coding interviews are the way they are because they work extremely well in practice, most of the time. They are also on average a massive equaliser and overall a good thing for almost everyone involved provided they are executed well. They do have their problems, but commonly proposed alternatives (like take home tests etc.) have problems too. Coding interviews are not a thing because there is some kind of collective madness in the whole industry, where people in charge of procuring the most expensive resource just can't help themselves succumb to group-think. They are a thing because they work well (but not perfectly).

ElFitz• 5 years ago

Funny thing, regarding the music analogy, The Beatles never studied music theory. Not even the basics (ie reading music sheets).

They did however play a lot, and probably deconstruct and analyse many of the cover songs they played at their beginnings.

roland35• 5 years ago

Fundamentals are important for software engineering, just like they are important for any type of engineering! I certainly would be more comfortable driving across a bridge designed by engineers who understand material properties and so on. Understanding the fundamentals allows them to select an appropriate design based on the requirements and budget.

That said, there is a lot of programming work where you don't need an advanced degree to be effective. But I still think fundamentals are an important part of application design - being able to select the appropriate system design for a problem.

mythrwy• 5 years ago

While that's definitely true, people were building bridges for thousands of years before formal engineering was a thing.

Of course some number of people probably died crossing those, and Golden Gate scale bridges weren't built.

Just to torture your analogy, maybe it depends on the scale and weight requirements of the software as to exactly how much fundamentals will be required.

Sometimes all that is needed is to lay a 2x4 across a mud puddle and that's fine. It's also how a lot of people get started.

iainmerrick2• 5 years ago

I really like this article and I love the analogy with music theory, which seems spot-on... but there’s one big difference, which is that you absolutely do not need to know music theory to be a professional musician!

At least in pop music, plenty of successful bands (maybe even the majority) don’t know music theory, they just know how to make music that sounds great (through natural talent and/or hard work).

There’s even a school of thought that music theory is actively bad for pop musicians, as it will tend to steer you down well-trodden lines and stifle innovation. For example, Paul McCartney supposedly avoiding learning any music theory when he was learning the piano, specifically to avoid losing his originality. He got the words for Golden Slumbers from an old piano piece belonging to his sister, but had to write an awesome new melody for it because he couldn’t read the music! (see https://www.the-paulmccartney-project.com/song/golden-slumbe...)

I think the analogy still works, though. To play in an orchestra you absolutely do need to be an expert sight-reader, and ideally have a good grounding in music theory. So working at Google or Facebook would be analogous to playing in an orchestra. They don’t want buskers, they want somebody who can read and understand a Messiaen score.

And maybe a small startup is more like a rock band -- you can get along perfectly well without any theory training. But if you want to grow into an orchestra (or in tech terms, more like 100 or 1000 orchestras) some theory training is essential.

Also, even in a small group, a mix of backgrounds can be beneficial -- look at the Beatles again, where George Martin’s classical training was a significant part of the overall mix (not to say a key part; Martin was the fifth Beatle at best).

raspasov5• 5 years ago

Now that's a good analogy with the orchestra being like a big-co! My thoughts exactly.

Cybotron50002• 5 years ago

Hi - I’m a largely self-taught musician/music teacher/producer of 15 years+ experience …played in loads of bands in many different styles and am a huge fan of the Beatles... Both you and the article are misguided in your assumptions about music theory IMHO. Whether they consciously know/admit it or not, every decent musician benefits from and needs to know about some sort of ‘music theory’ at every level of playing. I guarantee you that Paul McCartney and the Beatles knew/know rather more about music than you allow (or possibly than they recognise/would like to admit...). Granted, they could not perhaps sight-read musical notation and so on or arrange an orchestral score (though if you look into P.M./other Beatles’s background/family you’ll see that it was indeed very musical and he has done some pretty spectacular stuff with the hel of others…), but even if you want to play rock-n-roll covers in different keys you kind of need some understanding of eg. how a basic twelve bar blues format works, V-I change, some idea about scales/arpeggios/which notes ‘go together well’ etc. You don’t need to know the proper terminology for it or be able to do a full formal/Riemannian analysis or something, but you are using and systematising a kind of music theory directly, even if just on your own idiosyncratic terms... Theory and an ability to work out/make up /remember/categorise song’s etc. by ear or otherwise is more linked than you might superficially think I would suggest. Music theory across different cultures is not a science (as I presume computer science is?), but is based on kind of formalised aspects of that culture’s understanding of ‘common practise’. On a fundamental level you could look at it as being informed by how human beings perceive sound/frequencies/mathematical/aesthetic ‘rules’, but a large part is also based on conventions …so, even in the process of learning new songs/repertoire and seeing commonalities between them/remembering them, you are learning a type of music theory you could argue… Anyhow, I get where you’re coming from and there are some similarities, but sometimes I can’t help feeling people do tend to talk an awful lot of bunk/received nonsense about music and music theory… (the idea of ‘natural talent’ - although no doubt people have very different mental furniture/natural aptitude’s - is one of those things that can be very damaging to people progressing/learning about stuff I have found…)

iainmerrick2• 5 years ago

I think we’re mostly in agreement! Except I wasn’t totally clear what I meant by “music theory”, sorry :)

You don’t need to know the proper terminology for it or be able to do a full formal/Riemannian analysis or something, but you are using and systematising a kind of music theory directly, even if just on your own idiosyncratic terms

Yes, absolutely. Likewise, a self-taught programmer isn’t totally ignorant of complexity and data structures, they just have their own idiosyncratic understanding of them.

I guess when I say “knowing music theory” I really mean “formal music education”. You’re totally right that somebody like McCartney understands music at a deep level -- and in a knowledgeable way, not simply intuitively. But I still think it’s important to note that he doesn’t read music, doesn’t feel the need to, and has still been massively successful.

Similarly, you can be self-taught in software engineering and still be massively successful, even if you’re weak on some of the areas that would be covered in a formal CS degree.

I think the key question is whether there’s some part of formal CS education that’s essential to success at the biggest tech companies. I guess I’m arguing that there’s really nothing essential, although there’s a lot that’s very useful; and that it can be picked up in other ways.

I think that’s similar to what you’re arguing for in music theory -- even if you don’t have formal classical training, you can still “learn music theory” through practice, collaboration and self-reflection.

the idea of ‘natural talent’ - although no doubt people have very different mental furniture/natural aptitude’s - is one of those things that can be very damaging to people progressing/learning about stuff I have found…

Yes, you’re right. I used to think talent was essential in programming -- that there are just people who “get it” and people who don’t. That’s how it seemed to me in the first year of my CS degree, anyway. But I’ve since realised that what I saw as “talent” was simply “did programming for a hobby as a kid”, i.e. had a head start of 5–10 years of self-directed practice.

There’s clearly a cluster of related things. If you practice more you’ll tend to get better; if you enjoy it you’ll tend to practice more; if you have “talent” you’ll tend to enjoy it more; if you have exposure at a young age that can manifest as “talent”; and so on.

mkw2k• 5 years ago

The only answer is it depends on your job, IMO

K0nserv• 5 years ago

I agree with a lot of this, but I think it misses an important argument for why it's worth learning programming fundamentals: the eternal nature of it.

Think about it, in our fast phased industry, few things have the property that you can learn it today and it will remain useful and up to date until you retire. Programming fundamentals are one of those things. Why would you avoid learning something that will be useful your whole career.

With how much time we spend learnings new frameworks, APIs, and programming languages that rarely have the same staying power, learning some fundamentals is a no brainer.

jasonpeacock3• 5 years ago

IMO, there's a difference between people who are very good at connecting frameworks together and have a strong knowledge of many frameworks and platforms, and people are who are actually building those frameworks/services for others to use. It's the latter who are hard to find & hire, as most people (esp. coding bootcamps and self-taught courses) focus on the former because you can quickly create working mobile and web applications.

One question that I ask during interviews is to write a method to find the intersection of two lists of integers in better than O(n^2) time - basically, any solution that is not two nested `for` loops.

    intersect([1, 2, 3, 4], [2, 4, 6, 8]) => [2, 4]

Half the people I talk to cannot do that in 30 minutes. (no, you cannot use the built-in set operators)

commandlinefan• 5 years ago

Sorted or unsorted?

kubb2• 5 years ago

You can sort yourself, it's only O(n*logn), so it's still gonna be better than O(n^2), even when you include the linear scan to get the intersection.

LorenPechtel5• 5 years ago

And this is why the fundamentals matter.

marlowe2212• 5 years ago

I'm a self taught programmer who got his first full time job in tech in June 2020 after 13 years of practicing law. Here's how I would do it:

const intersect = arr1.filter(value => arr2.includes(value))

I don't know much about Big O notation yet, so I don't know if my solution would meet your speed requirements or not, but I'd be interested in your feedback.

You could also turn the two arrays into sets and then compare them. But I'm not sure what impact that would have on performance, if any, in your example.

jasonpeacock3• 5 years ago

`arr1.filter()` says "apply a filtering function to every value in arr1". This is O(n) because as the size of arr1 (n) grows larger, the work grows at the same rate (linearly).

`arr2.includes()` says "check if value is in arr2", and most languages implement this method as a linear search (esp. if arr2 is an array). This is also O(m) because as the size of arr2 (m) grows larger, the work (linear search) grows at the same rate.

Taken together, the algorithm is doing "for every value of arr1, apply a filter function which linearly searches for the value in arr2". If arr1 is size 5 (n), and arr2 is size 10 (m), then the total work being done is 5*10 (n*m). Thus the overall performance is O(n*m), though it is commonly simplified to the worst case where both sizes are the same: O(n*n), or O(n^2).

This is the same as using nested for loops, just more elegant (and functional):

    intersection = list()
    for i in arr1:
        for j in arr2:
            if i == j:
                intersection.append(1)
    return intersection

---- SOLUTION ----

One approach is to convert one list into a Set, O(n) because you have to traverse the list once. Then iterate the second list and check if it exists in the Set. Checking if something exists in a Set is constant time, O(1), so you only have the cost of traversing the second list once O(m).

The overall performance is O(n + m * 1), or O(2n) because we assume worst case of both lists being the same size. That is usually simplified to O(n) as we're usually only concerned about the performance behavior, e.g. "how does it change as it gets bigger?" and not directly comparing say two algorithms of O(3n) and O(5n + 1).

There's still a lot of unhandled edge cases and other issues that need addressing in the solution described above, and there are other valid solutions as well. The goal is only to be better than O(n^2), not optimal.

sireat• 5 years ago

Question is if you allow using prebuilt Map type data structures.

Then it is easy just bucket count with keys being integers in the list and iterate afterwards filtering for value >= 2

Now if no Maps are allowed it is a bit trickier... you might need your own hashing function or as someone else suggested write your own nlogn sort..

kubb2• 5 years ago

I'm always surprised that companies interview based on obscure knowledge in specific PLs. If you know the fundamentals of CS (not just A&DS), you can learn a language in a month (sometimes a week). Concepts translate between languages.

SilurianWenlock2• 5 years ago

Does 1000+ Leetcode questions mean you've grasped the fundamentals?

why55• 5 years ago

Once I had to solve a memory problem because someone assigned what should have been a byte array to a list of byte. Nice enough programmer for high level concepts but needed the fundamentals. I think a good skills assessment is needed and then you patch the missing knowledge. A smart resource who can learn and is nice to work with is still a good hire.

allo37• 5 years ago

Isn't this just the old engineer/technician dichotomy but applied to programming?

I mean sure you can design circuits without learning all the differential equations governing how each component behaves, and you can fire up a copy of SolidWorks and build a lot of really nifty stuff without ever studying resistance of materials. But if you want to be an engineer in one of those fields you're definitely going to have to knuckle down and learn the respective theory at some point, even if you find yourself using very little of it on the job.

I've seen people with a more practical "technician" training brag that the engineers are "mired in theory and can't do anything useful", and then I see people with a more theoretical background think anything practical is trivial and beneath them.

Wanna know what I think? Learn both!

lmilcin• 5 years ago

I think fundamentals are extremely important, but there is a confusion what is fundamental and what is not.

I have interviewed thousands of candidates and hired and worked with dozens of them.

In my experience, the most important, most fundamental abilities for a programmer are:

- analytical approach,

- ability to predict what the code is going to do.

I don't care if the candidate knows how to implement A* on a whiteboard. Frankly, I think this is stupid if he/she will never see a problem like that and if it happens, the solution is just a google search away.

Don't get me wrong, knowing algorithms is very useful. But it is not critical to writing working code.

What I do care about is that you can reason about the code you are given, that you can construct/modify the code methodically. That you can predict what the changes you are going to make will do to the program. That you can have workable mental model of the program that.

The worst type of developer I have seen have memorized all algorithms, data structures, language details that were in the book. Yet they can't modify the program and tell what will happen without actually running the code.

When you observe them writing code it seems they are modifying it at random until it happens to work. Then they are happy they have "solved" the problem after two dozen or more iterations.

When it fails they are not at all interested in understanding how it failed, only where it failed -- to have a starting point to keep changing they code until it runs.

For this reason -- to filter out those candidates -- I will never pass a person without seeing them writing code.

I have observed over the years HN community being somewhat negative to programming on interviews. Ask yourself, would you hire somebody to build your house based on only how they market-speak how fanstastically they can build fantastic houses?

mewpmewp27• 5 years ago

My issue is that when you are an experienced engineer, and you do not use those fundamentals daily you will simply forget them, even having learned them in the first place, so the folks who pass those interviews are not the folks who do actual work on projects, but ones who practiced countless hours on LeetCode and or recently studying theory in order to game the interview system.

Do you prefer a person who spent their last 6 months leetcoding or someone who has been working last 6 months on actual projects?

eaa• 5 years ago

One can argue endlessly about necessity of knowing theory, but instead I would describe a funny situation I have seen once.

There was a piece of code that had to receive some items asynchronously one by one while they were being downloaded. Also, duplicates had to be found by some key and merged together. So, first a dumb and straightforward implementation was done using a vector and linear search. After some time management decided to stress test it with some extreme amount of items. And instead of fraction of second or seconds it was taking minutes which was unacceptable. A colleague of mine was assigned the task to fix this. What has he done, what do you think? He spawned another thread for search of duplicates. On a single core hardware. It didn't help. So he asked our team leader for help. What did he do? He increased a share of CPU time for that thread (it was a RTOS). That also didn't help. I was watching at all this with interest and suspicion and remembered at some moment that there is an algorithm for binary search which is much faster than linear search. So I removed all the code for additional thread and instead made vector to be always sorted and applied binary search. Download time changed from minutes to 10 seconds.

This way I learned about importance of algorithms (which for some strange reason haven't been taught in my university). But my colleague didn't learn anything, because he still thinks that theory of algorithms is for that kind of people that take part in programming contests and not for real programmers who "get sh*t done."

Let's face it: even programming is full of people with attitude of anti-intellectualism. Although this whole industry wouldn't be born with such attitude.

musicale• 5 years ago

Programming fundamentals are valuable, but whiteboard interviews have little to do with programming fundamentals.

If you look at (hackerrank, leetcode, etc.) you will see that many questions asked in actual interviews are the sort of algorithm puzzles that you might see in "programming" contests like ICPC. As such they can be impossible to solve on a whiteboard or google doc in 45 minutes unless either a) you are Donald Knuth or b) you have a lot of experience with algorithm puzzle contests and have solved a similar problem before.

However, there do seem to be a number of NP-complete combinatorial optimization problems, so I think may be useful to be able to tell your interviewer "well, this problem is NP-complete, so in the worst case it's likely to be exponential."

How necessary are the programming fundamentals?

Related Stories