[HN Gopher] How necessary are the programming fundamentals?
___________________________________________________________________
How necessary are the programming fundamentals?
Author : rockbruno
Score : 88 points
Date : 2021-05-18 11:40 UTC (1 days ago)
(HTM) web link (swiftrocks.com)
(TXT) w3m dump (swiftrocks.com)
| nowherebeen wrote:
| > 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 wrote:
| 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.
| danbmil99 wrote:
| 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.
| yesenadam wrote:
| Thank you, it's quite rare that people reply to my comments
| on here and I'm glad they did! haha.
|
| Every musician/singer that is famous, sounds unique--like
| themselves and no-one else.
|
| I keep coming across, in many fields, people saying that
| their subject can be learnt but not taught. Botvinnik
| (founder of the Russian School of Chess) said it about
| chess! I think it's true of jazz. You have to learn it for
| yourself, by listening to what you love and selecting from
| it and emulating what you love.
| jasonpeacock wrote:
| 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 wrote:
| Sorted or unsorted?
| kubb wrote:
| 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.
| djipko wrote:
| 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).
| Mauricebranagh wrote:
| Just thought with the analogy with music is there a market for
| Fake/Real Books for developers.
| ElFitz wrote:
| 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.
| [deleted]
| roland35 wrote:
| 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.
| gfxgirl wrote:
| 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.
| jiggawatts wrote:
| > 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?
| raspasov wrote:
| 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 :).
| jiggawatts wrote:
| I once had a friendly debate with a database professional.
| I argued that these days with storage being so cheap,
| databases should automatically create indexes. E.g.:
| anything referenced in a view or a foreign key, and also
| anything that occurs regularly in production. He said he
| thought that was a bad idea, because a tiny fraction of the
| time it could cause a performance regression.
|
| Now, years later, Azure SQL Database has automatic indexing
| and I feel a little bit vindicated. He does have a point
| that this _can_ go wrong, but compared to what the typical
| developer does, it basically can 't make things worse.
| raspasov wrote:
| Yes, you have a point. I think there's no fundamental
| limitation today why everything can't be indexed. There's
| definitely some overhead to updating the indices on every
| insert of course, but that's probably a relatively fixed
| ~O(1) cost in most cases.
| fatnoah wrote:
| >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. ;)
| cjblomqvist wrote:
| 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.
| q-big wrote:
| > 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?
| Emigre_ wrote:
| 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.
| goto11 wrote:
| 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 wrote:
| 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.
| ManlyBread wrote:
| I have been working as a programmer since 2015 and I'm not sure
| if I could answer these questions.
| ZephyrBlu wrote:
| Why aren't you sure? These seem like straightforward
| questions for people with a little experience.
| michaelt wrote:
| An experienced programmer in Python or Java would certainly
| know the difference between an array and a set.
|
| But someone doing embedded C programming, where a mere
| printf function is an extravagant luxury? You could program
| for years and not encounter a set.
| nathias wrote:
| Whats so terrible about telling someone to use an ordered
| collection in their PR?
| galbar wrote:
| 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 wrote:
| 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 wrote:
| 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.
| galbar wrote:
| >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.
| mtberatwork wrote:
| > 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.
| samsquire wrote:
| 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
| allo37 wrote:
| 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!
| SilurianWenlock wrote:
| Does 1000+ Leetcode questions mean you've grasped the
| fundamentals?
| jackblemming wrote:
| 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.
| K0nserv wrote:
| 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.
| LaundroMat wrote:
| What are good introductions to Data Structures and Algorithms for
| a hobbyist developer?
| nwb wrote:
| 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.
| Emigre_ wrote:
| 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.
| satysin wrote:
| 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.
| mkw2k wrote:
| The only answer is it depends on your job, IMO
| iainmerrick wrote:
| 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).
| raspasov wrote:
| Now that's a good analogy with the orchestra being like a big-
| co! My thoughts exactly.
| [deleted]
| ChrisMarshallNY wrote:
| 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.
| teddyh wrote:
| > _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.
| alkonaut wrote:
| 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.
| ChrisMarshallNY wrote:
| ...and then, there's spending 27 years, working for a
| conservative Japanese corporation, where they don't know
| the jargon (but are seriously good engineers). I learned to
| make things fairly clear, without jargon, and deliver very
| maintainable code (I'd have been fired, otherwise).
|
| Listen, I understand that researching people before we
| insult them is passe, but I'm a really good co-worker. I
| wrote the above in a manner that was all focused on me, not
| anyone else. I am sad that you saw it as an opportunity to
| attack.
|
| Maybe we would not get along IRL, and that's fine (but
| sad). I've spent my entire adult life, working with some of
| the most difficult folks on Earth (not in the tech
| industry). I have learned that we all have a story, and we
| all have value.
|
| If the only way that we can measure our personal worth is
| to compare it favorably against others, I can't help,
| there, except to say that it didn't work for me.
|
| YMMV
| ChrisMarshallNY wrote:
| 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
| teddyh wrote:
| I'd rather hear from your co-workers, or, preferably, the
| current maintainers of software which you originally wrote.
| ChrisMarshallNY wrote:
| Well...you're in luck!
|
| My LI profile is full of testimonials from both. Feel
| free to ask me for references. I'm not looking for a job,
| but I can probably scare up a couple of folks willing to
| go on record on my behalf. I would also be happy to send
| you some _very_ relevant links.
|
| You could also order the DSLR interface SDK from my
| former corporation. One of the APIs is a cross-platform
| imaging device communication layer I wrote in 1995 (in
| C). I think they still use it.
|
| _EDIT: Listen, in all seriousness, I 'm a really decent
| chap, as, I'm sure, are you. I regret that we have begun
| our relationship on this note, and I will no longer
| engage you. I scrubbed some of the snark off of this
| reply._
| teddyh wrote:
| I wasn't meaning to be _overly_ snarky in my original
| comment, it was also an invitation for you to push back
| with some references of how you _do_ communicate well
| with others and your code _can_ be easily be maintained
| by others. This, I imagine, could be due a few different
| possibilities. It might be that:
|
| 1. You _do_ use common idioms and patters, but you don't
| know that you do. Perhaps because you haven't
| specifically studied them; you might have just absorbed
| them by cultural osmosis.
|
| 2. You might be good enough at explaining things (and
| naming things) so that you, like Richard Feynman, can
| explain the most complex things in common simple terms,
| even though they are not the industry standard
| terminology.
|
| 3. You always find solutions and algorithms which are so
| simple to understand that you have never needed anything
| more complex.
|
| 4. You have some other explanation which I can't think of
| just now.
|
| Instead, what you said was some variation of "my work
| speaks for itself" and "do your own research", which does
| not inspire confidence in your communication abilities.
| ChrisMarshallNY wrote:
| OK. I know I said I wouldn't engage more.
|
| I lied. I liked your response.
|
| What I wrote was completely self-expository. It really is
| who I am, and I'm used to writing that way. It was not a
| challenge, and it was not an attack on anything (I can
| easily do "attack" -I'm an old UseNet troll).
|
| As I mentioned above (below?), it saddens me that people
| see self-exposition from others as weakness and a vector
| for attack. That's one of the reasons that I'm no longer
| interested in working for anyone else in this industry,
| and why I no longer want to be a manager.
|
| Things are _nasty_ these days. Hyper-competitive. We can
| 't just be _good_ at something. We need to be _better
| than someone else_.
|
| We can't just be enthusiastic. We need to be _combative_.
| Everything is a gladiatorial contest. Thumbs up /down.
|
| After leaving that silo I'd been in for 27 years, I
| started looking for work, and rapidly discovered what
| this industry I love has become.
|
| I don't really want to play in the cesspool, but I love
| to code.
|
| I guess I am "taking my toys and going home," but I am
| very, very fortunate in being able to do so.
|
| I'm working on a fairly ambitious project, right now,
| that will (I hope) help out a lot of folks. I have some
| prior art in the area. I'm working for a non-profit, for
| free.
|
| And _loving_ it.
| tempodox wrote:
| > 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.
| ChrisMarshallNY wrote:
| 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.
| tempodox wrote:
| Thank you for the explanation! I actually didn't know that.
| kubb wrote:
| 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.
| loup-vaillant wrote:
| 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 wrote:
| 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 wrote:
| > _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(tm) 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 wrote:
| 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 wrote:
| 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.
| raspasov wrote:
| Thank you for the informative explanation!
| username90 wrote:
| 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 wrote:
| What's the hardest area?
|
| Have you got a list from easiest to hardest areas?
| hnfong wrote:
| 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.
| [deleted]
| lordnacho wrote:
| 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 wrote:
| > 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 wrote:
| Being creative with algorithms is different from carrying
| algorithms in your head..
| FartyMcFarter wrote:
| That's why the best coding interview questions are the ones
| that can be solved without fancy algorithms.
| username90 wrote:
| Interviews almost never require fancy algorithms, just
| the super basic ones that you learn in the first course
| in college.
| username90 wrote:
| I've seen a ton of interviews at Google, none of them
| required fancy algorithms. They did require you to take
| some fundamental algorithm and change it up a bit, but
| the end result wasn't fancy algorithms just basic ones
| with a twist.
| username90 wrote:
| If you have been creative with algorithms then you will
| have the fundamental ones in your head. Every time you add
| layers the last layers needs to be really stable, so
| testing the layers they need to have built upon is a good
| way to filter out people who haven't progressed past that
| layer.
| tchalla wrote:
| > If you have been creative with algorithms then you will
| have the fundamental ones in your head.
|
| You can be creative with algorithms without having the
| "fundamental" ones in your head because you know where to
| look them up. Therefore, testing the layers; tests for
| recall and not for those layers. In most situations,
| these tests only test for short-term preparation.
| carlmr wrote:
| 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 wrote:
| >> 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.
| carlmr wrote:
| That's a cool idea. I rarely think about these platforms
| due to my personal distaste for them, but that's actually
| useful.
| kfreds wrote:
| > Yet I don't come across a lot of people asking about how this
| is done.
|
| Please elaborate! How do you handle complexity?
| lordnacho wrote:
| 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.
| Mauricebranagh wrote:
| 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
| danbmil99 wrote:
| TIL that Iron Maiden are masters of Music Theory
___________________________________________________________________
(page generated 2021-05-19 23:02 UTC)