13 ms·

How necessary are the programming fundamentals?

118 points by rockbruno 5y ago

Emigre_ 5y 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.
samsquire 5y 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
- LorenPechtel 5y 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.
  - samsquire 5y 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 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.
    - LorenPechtel 5y ago
      Yeah, but how many programmers write database engines? That's mostly a don't-reinvent-the-wheel thing.
deleted 5y ago
[deleted]
lordnacho 5y 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.
- username90 5y 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 5y ago
    Being creative with algorithms is different from carrying algorithms in your head..
Mauricebranagh 5y 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 5y 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.
- yesenadam 5y 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.
Mauricebranagh 5y ago
Just thought with the analogy with music is there a market for Fake/Real Books for developers.
deleted 5y ago
[deleted]
jackblemming 5y 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.
- LorenPechtel 5y 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 5y ago
What are good introductions to Data Structures and Algorithms for a hobbyist developer?
- satysin 5y ago
  Coursera and many similar online resources all have good DS&A courses. Check out https://www.coursera.org/browse/computer-science/algorithms 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_ 5y 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 5y 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-structures-masterclass/ 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.
ChrisMarshallNY 5y 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.
danbmil99 5y ago
TIL that Iron Maiden are masters of Music Theory
gfxgirl 5y 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 5y 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.
goto11 5y 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.
galbar 5y 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.
- nathias 5y ago
  Whats so terrible about telling someone to use an ordered collection in their PR?
  - galbar 5y 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.
    - nathias 5y ago
      It could (probably not) be affected negatively by the wrong choice of a data structure, but what harm is it if the coder doesn't know, is then informed of it as part of peer review and that's that?
- Aeolun 5y 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.
loup-vaillant 5y 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 5y 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-vaillant 5y 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.
raspasov 5y 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/clojure/lang/PersistentHashMap.java 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 5y 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.
username90 5y 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.
- SilurianWenlock 5y ago
  What's the hardest area? Have you got a list from easiest to hardest areas?
  - hnfong 5y 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 5y 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 5y 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 5y 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 5y 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.
iainmerrick 5y 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-slumbers/ 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).
- raspasov 5y ago
  Now that's a good analogy with the orchestra being like a big-co! My thoughts exactly.
- deleted 5y ago
  [deleted]
- Cybotron5000 5y 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…)
mkw2k 5y ago
The only answer is it depends on your job, IMO
K0nserv 5y 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.
jasonpeacock 5y 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 5y ago
  Sorted or unsorted?
  - kubb 5y 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.
- LorenPechtel 5y ago
  And this is why the fundamentals matter.
- marlowe221 5y 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.
  - 5y ago
kubb 5y 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.
SilurianWenlock 5y ago
Does 1000+ Leetcode questions mean you've grasped the fundamentals?
allo37 5y 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 5y 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?
mewpmewp2 5y 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 5y 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 5y 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."

118 points by rockbruno 5y 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.

samsquire 5y 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

LorenPechtel 5y 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.
- samsquire 5y 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 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.
  - LorenPechtel 5y ago
    Yeah, but how many programmers write database engines? That's mostly a don't-reinvent-the-wheel thing.

deleted 5y ago

[deleted]

lordnacho 5y 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.

username90 5y 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 5y ago
  Being creative with algorithms is different from carrying algorithms in your head..

Mauricebranagh 5y 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 5y 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.

yesenadam 5y 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.

Mauricebranagh 5y ago

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

deleted 5y ago

[deleted]

jackblemming 5y 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.

LorenPechtel 5y 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 5y ago

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

satysin 5y ago
Coursera and many similar online resources all have good DS&A courses. Check out https://www.coursera.org/browse/computer-science/algorithms 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_ 5y 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 5y 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-structures-masterclass/ 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.

ChrisMarshallNY 5y 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.

danbmil99 5y ago

TIL that Iron Maiden are masters of Music Theory

gfxgirl 5y 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 5y 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.

goto11 5y 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.

galbar 5y 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.

nathias 5y ago
Whats so terrible about telling someone to use an ordered collection in their PR?
- galbar 5y 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.
  - nathias 5y ago
    It could (probably not) be affected negatively by the wrong choice of a data structure, but what harm is it if the coder doesn't know, is then informed of it as part of peer review and that's that?
Aeolun 5y 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.

loup-vaillant 5y 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 5y 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-vaillant 5y 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.

raspasov 5y 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/clojure/lang/PersistentHashMap.java 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 5y 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.

username90 5y 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.

SilurianWenlock 5y ago
What's the hardest area? Have you got a list from easiest to hardest areas?
- hnfong 5y 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 5y 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 5y 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 5y 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 5y 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.

iainmerrick 5y 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-slumbers/ 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).

raspasov 5y ago
Now that's a good analogy with the orchestra being like a big-co! My thoughts exactly.
deleted 5y ago
[deleted]
Cybotron5000 5y 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…)

mkw2k 5y ago

The only answer is it depends on your job, IMO

K0nserv 5y 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.

jasonpeacock 5y 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 5y ago
Sorted or unsorted?
- kubb 5y 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.
LorenPechtel 5y ago
And this is why the fundamentals matter.
marlowe221 5y 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.
- 5y ago

kubb 5y 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.

SilurianWenlock 5y ago

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

allo37 5y 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 5y 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?

mewpmewp2 5y 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 5y 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 5y 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."