22 ms·

They don't even know the fundamentals

• gitfan86 5y ago
  In a google interview I explained CAP theorem using the speed of light. The interviewer didn't understand. He clearly wanted me to regurgitate the official definition.
  • EdwardDiego 5y ago
    Keen to hear your speed of light explanation of CAP :)
    • avaldes 5y ago
      The speed of light puts a hard constraint in the simultaneity of data availability in a network. You can't have data replicated faster than c no matter how fast is your hardware.
• eussg 5y ago
  I like the Zoho strategy of just hiring high school kids and training them - https://m.timesofindia.com/india/this-man-is-also-driving-one-of-indias-most-profitable-unicorns/articleshow/85171268.cms https://m.timesofindia.com/india/this-man-is-also-driving-on...
  • nudpiedo 5y ago
    It’s interesting, many western corporations used to do that, but after decades it eventually was delayed to training during summer breaks or jobs right after university as it is often assumed that even after university they lack any real world knowledge. Cheaper and often a loyal employee, still works but not as mainstream as it used to be. Dojo’s approach seem to be one step beyond, but it requires even longer commitment to the employee and an asymmetrical market opportunity and economic chance. Definitely will help people and become a win win.
  • bsenftner 5y ago
    I've worked at visual effects studios working on feature films, and in that industry (where proprietary workflows rule) there is always an education department. Even if one used to work there, being gone for a year is enough to make one useless as the workflows change radically, VFX technologies move fast. When I spent time consulting at web shops, I was dismayed at the undocumented and loose workflows, plus no process documentation in sight. I get the sense the web is the worse of modern tech exploitation work practices. Hell, working in video games looks better.
    • gruez 5y ago
      >I get the sense the web is the worse of modern tech exploitation work practices. Web work is exploitative because... the workflow is undocumented? If it pays well, who cares?
      • bsenftner 5y ago
        Undocumented is much worse than your comment seems to realize. Wait until you are in a situation when the only people that know a mission critical procedure quit or die. This can cause entire large companies to crumble, as well as the reason so much confusion exists in development, and is also a reason the industry relies on leet code testing - if you don't know something before being hired, nobody can explain it there because they are all fixing fires or on not-really-understanding auto-pilot.
  • markus_zhang 5y ago
    It's actually a good practice. I think the intelligence community sort of do this too. On the other hand I think a more practical equivalent is to hire internal candidates who show some interests but didn't get the chance to work on real problems and train them.
  • littlecranky67 5y ago
    I've worked with several companies that tried that, in the end once the juniors became experienced and skilled enough, they took offers from other companies with a much higher salary. The issue is that training/skilling juniors or fresh university graduates costs you money and slows you down (as you need to assign senior engineers/mentors to assist them). It is not unlikely that a newly joined junior employees only costs you money and decreases throughput/value for your company in the first 6-12 months, but you still pay them a (decent) salary. So once you got them skilled, you as a company would probably need to raise the salary to market/senior level to keep them - given the mass amount of recruiter approaches we in IT get. In that case, you could just start off hiring seniors only in the first place. This is an issue I see everywhere, nobody wants to hire freshly graduated and everybody is only shopping around for seniors.
    • Clubber 5y ago
      >took offers from other companies with a much higher salary. Seems like paying at least market rates once they are trained up would solve that problem. Once someone develops a skill, a company can't expect to keep them at intern or junior salary levels.
      • littlecranky67 5y ago
        That was exactly my point. But why hire & train a junior dev when there is no company loyalty and the money spent on training is basically lost. Instead management focus on directly hiring seniors. Of course that doesn't work as a whole, because if no one hires juniors there will be a point where there will be no seniors anymore. I also feel little to no pity when those companies complain, that they can't find seniors.
    • BeFlatXIII 5y ago
      New unethical life hack: make up a failed startup to pad out your résumé to get hired as a senior right out of college.
• mypastself 5y ago
  “Atomicity, something, something, Durability?” My exact response after reading the first quote. It is indeed fundamental, and something I am mindful of with every database query I execute. But I haven’t thought about the exact definition and its mnemonic in over a decade.
  • gameswithgo 5y ago
    If I was hiring your response would be sufficient. Assuming you could expound a bit on the point of it and offer some example scenarios. So many interview objections are about extreme interpretations of these questions, which do happen but are not normal.
    • mypastself 5y ago
      Yeah, I assume the quoted interviewer attempted to further clarify the question and its intent. “Explain ACID” might be misheard or misunderstood by the subject. “Well, I don’t know, I guess I get reflux any time I’m doing an interview.“
  • ivanhoe 5y ago
    I don't think anyone reasonable actually suggest that one has to memorize the exact book definitions, but simply to be demonstrate that they understand the important parts. Not being able to give any explanation or sign that you've at least heard of it is a completely different story from not being able to recall what the letter C stands for (consistency IIRC?). As the saying goes: If you think you understand something, and you can't explain it to someone else, that you probably don't really understand it.
• jb1991 5y ago
  I will still never understand why I was asked to code an implementation of a binary tree for an interview once, something that is usually left to those who implement standard libraries or similar low-level needs, for a job that was basically writing user interfaces.
  • nostrebored 5y ago
    Because an implementation of a binary tree is dead simple.
    • jhgb 5y ago
      You mean a naive one, that is, a useless one...or a practical one? Such as, at least something like LLRB?
      • ascar 5y ago
        A binary tree is just a tree data structure where each node has at most two children. And that's dead simple and every programmer should be able to implement that when aksed. Note that it doesn't even have the search (i.e. sorted) requirement and much less the self-balancing one. You can work your way towards that with the right questions and that would be an acceptable way to structure an interview. Start with something simple everyone should be able to do and then work your way up the requirements and discuss potential problems/pitfalls and their solutions. Nobody talked about implementing a specific variant of a red-black tree when the general topic of self-balancing binary search tree hasn't even be mentioned.
        • jhgb 5y ago
          It is dead simple. What you're describing (two children, no constraints) is basically a cons cell. Yet I suspect that most people don't use cons cells as binary trees. Which is probably why I didn't understand that apparently rather nebulous topic as being this generic.
        • sureglymop 5y ago
• sparks1970 5y ago
  > There is another fundamental that is ignored by a lot of computer users. I think everyone who spends a lot of time behind a computer should learn how to touch type, since typing is still the main way of interacting with your computer. I sort of agree, but anyone typing out code at 120WPM isn't programming, they're writing. Programming is an intellectual activity, not a physical one so learning to touch type is worthwhile but might only gain you a few minutes a day of productivity over someone doing 40WPM in a home-grown hunt-and-peck style of typing?
  • edem 5y ago
    I don't agree. Touch typing is not about the speed. It is about letting you keep your eyes on the screen while you're typing. It enhances your "headspace" so much, that you don't have to micro-context-switch all the time between the keyboard and the screen.
  • geewee 5y ago
    I've seen this argument before and I don't think I agree. Surely there's a lot of times when I program that are heavy into thinking, but there's also a lot of mechanical work. Refactoring? Typing speed will help you. Going to try out a new approach? Typing speed will help you to see whether it's true or not. Everything else being equal, typing speed will help you try out stuff faster.
    • rob74 5y ago
      Yeah... even if you don't have to type fast, not needing to look at the keyboard when you type will at least help you to concentrate on what's on your screen and stay in the "flow".
    • have_faith 5y ago
      All else being equal sure typing faster is only going to make you more productive but a slower typer who is better at solving complex problems is always going to be more valuable than a fast typer who is not as good. I don’t think I’ve ever encountered a programmer that was too slow to simply be productive and valuable to a business which makes it questionable advice for anyone to follow.
• edem 5y ago
  > For the majority of programmers out there, something being RESTful means that you can feed it chunks of JSON over HTTP. The minority, who have spent some time reading about it, will complain that it’s a design principle defined in the Roy Fielding’s thesis and it has nothing to do with JSON or HTTP 3. How many of you have actually read his thesis? All of it? No skipping? I've been railing about this for years. Please stop calling it a REST endpoint. In 95% of the cases it is a custom HTTP endpoint and that's it.
  • bluepnume 5y ago
    Probably pick a different hill to die on. The meaning of "REST" in common parlance is now just HTTP+JSON, nothing more. At best, the url might represent a noun.
    • stepbeek 5y ago
      I'm not going to die on that hill, but I will gleefully call an API "RPC-over-HTTP" as a kind of silly trolling when this style of JSON-over-HTTP RESTful is equated with cool.
      • isbvhodnvemrwvn 5y ago
        And everyone is going to roll their eyes and continue on with their work, as they don't want the 5th discussion about this.
        • stepbeek 5y ago
          Hence “silly trolling.”
  • nonameiguess 5y ago
    I actually wonder where this came from. It seems like a few popular Spring Boot projects started putting "rest" somewhere in the url path of every http endpoint that returns a serialized data structure in the response body rather than browser-renderable markup, but were they the first to do this? I try to just call these things an "http API" when talking about it myself, just to mean an endpoint that is intended for consumption by other applications, not by humans, but I'm not gonna fight other people using language the way it works in practice, where words just mean whatever enough people agree they mean, regardless of what the very first user of the word meant.
• GoToRO 5y ago
  Don’t ask questions that can be answered with a web search.
  • drclau 5y ago
    > Don’t ask questions that can be answered with a web search. These days, that’s equivalent to saying “don’t ask questions about what the day to day job requires one to know”. Sites like stackoverflow contain answers to problems that people encounter in their day to day jobs, and if you eliminate those as potential questions, then what should you ask? And what is the value in asking some obscure question, other than making the interviewer feel smart and special?
    • EdwardDiego 5y ago
      Here's a question you can't properly answer with a web search for a data engineering role "I'm emitting 10TB of data a day with this schema {X} - it's produced in Avro. Currently we upload it into S3. But, instead, I want to stream into Apache Druid, but also want to make it available for ad-hoc analysis by BAs. What approach would you take?" Can't exactly google an answer to that.
      • jstx1 5y ago
        Your question turns into a question of "have you worked with Avro, S3, Apache Druid..." which will filter out competent people that don't have experience with the specific list of tools.
        • EdwardDiego 5y ago
          No it doesn't. The keywords there were "streaming" and "also ad-hoc analysis". Answering those questions requires no knowledge of Avro or Druid, but rather, how to build streaming pipelines, and also make the data available for a query engine. But that said, if you're in data engineering and are unaware of what Avro is, you're probably not at the level of knowledge I'd expect, and I'm happy to filter you out. Likewise, if you're unfamiliar with S3, why are you even applying for a data engineering role?
• lytefm 5y ago
  > “Yes, every programmer should know how their hardware works as one cannot write an efficient software without that knowledge 4, and I wouldn’t be able to do my job if I didn’t know anything about computer internals, yak, yak, yak…” I agree that you don't need to know anything about von Neumann Architecture and the likes in order to be a Web Dev. But I wouldn't want to hire someone who doesn't have basic knowledge about data structures and runtime complexity. It's just too easy to have something work fine in development, but choke in production due to accidentally quadratic behaviour.
  • AmericanChopper 5y ago
    Not knowing how databases work is a pretty common issue I come across with colleagues. Even basic things like normal forms (which take about 5 minutes to understand), and what transactions are. I think it’s why non-RDBMS datastores are so popular, because they generally just ignore all the problems RDBMS are trying to solve, so the developer isn’t inconvenienced by thinking about them.
    • guax 5y ago
      Non rdbms are popular because at scale everything that's nice about "classic" rdbms are what makes them ultra slow. edit: the features I refer to are stuff like foreign keys, cascades, dynamic fields, complex joins, etc. Once your stuff is spread out you loose some of these by definition and if you're still sticking to a single DB with massive stores you're not getting much humpf out of it anymore. I 100% agree there are way too many fools that think their DB is big and try non rdbms too early and waste too much time. But I still think their lack of recent popularity is due to their own limitations.
      • detaro 5y ago
        Except they are also popular with people that are not working "at scale" where that would matter.
      • Aeolun 5y ago
        Not really, they remain fast enough, there’s just no easy way to scale them past a certain point. Or there wasn’t anyway, I believe with spanner and CockroachDB we’re getting pretty close. But 99% of projects do not come even close to the scale where you need that.
• doctor_eval 5y ago
  If you’re writing database applications in a commercial environment then knowing what ACID means is part of your job. If you don’t know that, for example, debiting one account and crediting another needs to be done inside a transaction - or the converse, what you need to do if you don’t have access to transactions - then you shouldn’t be anywhere near a database. Fundamentals are actually important. You don’t have to know everything, but you should know the fundamentals of the field you work in.
  • heurisko 5y ago
    I dislike asking what acronyms mean, as even I can't always remember the letters, although I know about the necessity of transactions and how to implement them. Such as "I" - what is it again? "Isolation"? "Transactions are independent". Well--yes.
  • EdwardDiego 5y ago
    > you should know the fundamentals of the field you work in. ...I think that was the entire point of their post. > I guess we would be much happier if we dared to admit that one man’s fundamentals are another man’s trivia
  • fabian2k 5y ago
    The important part you need to know in that case isn't the definition of ACID, but the actual transactional properties of the database you're working with. And even among developers working with databases, it varies how well you actually need to understand transactions. And I would guess that many developers working with relational databases don't actually understand the more subtle differences between transaction isolation levels. I think asking backend developers to know the basics of transactions is reasonable. But e.g. knowing the exact difference between READ COMMITTED, REPEATABLE READ and SERIALIZABLE (and what your specific database actually implements there) might not be necessary in many cases. Though it certainly is good to be able to spot when you're about to enter territory where these differences might matter. I agree that a backend developer working with databases should know what transaction are. But I don't really need the definition of ACID, and you can really push this question into details that are not relevant for all developers.
• zcw100 5y ago
  "Yet, despite coming up with a distributed archiving system that works in production". The thing is, did he? Really? I know plenty of people who get things into production and by working they mean, doing something that appears like what it's supposed to do. I usually find these are the people who blame everything else for why it's not working. A red flag is usually the phrase, "X isn't ready for prime time". The translation for that is, "I found something that I couldn't figure out and probably will never figure out so you better let me choose something else". These are the people who habitually bounce around from framework to framework. Oddly the more cutting edge it is the better. That way they're on the cutting edge so you need to expect problems, better than everyone else, and because they're better than everyone else you need to listen to them when they tell you, "It's not ready for prime time."
  • EdwardDiego 5y ago
    > The thing is, did he? Really? Well, in the absence of evidence in the contrary, they probably did.
    • zcw100 5y ago
      Believing everything you read on the internet is true as long as you don't have contrary evidence isn't a good idea. I'm not saying he didn't, I'm saying you don't have any evidence, other than his own assertion, that he did. Considering the article is railing against learning "the fundamentals" his assertion is very self serving and should be taken with a bit of skepticism.
• lordnacho 5y ago
  Most of your time isn't spent in fundamentals though. I find a lot of my time is spent looking up some kind of best practice, or discovering what libs other people are using for a problem. Also, things may be fundamental, but not everything is built up from fundamentals. Maybe math is the best place to look at this. When you go to school, you just do it. Number lines, equations, calculus, matrices. Even through the engineering course I did, which had all sorts of advanced topics, nobody mentioned ZFC or Peano or Cantor or anything like that. And while it's true that if you dig under the stuff that you get taught there's a whole interesting world, it doesn't seem to stop anyone from using math. With coding, a lot of it is having the right attitude. Something's broken, I'm going to try to understand why and what other people have done to fix similar issues. There's a resourcefulness that beats classroom teaching in terms of usefulness. You want that person who is capable of understanding everything that might happen, what he needs to do to fix it, etc. That person is never going to know or have heard of everything to start with, but they can deal with things when they happen. But of course it's easier to test whether someone has heard of this or that thing. Perhaps this is why senior devs find it easier to get a job than junior ones, employers are more likely to think that they can work through issues.
  • gameswithgo 5y ago
    When you look up a best practice you often get conflicting opinions. Solid fundamentals may help you evaluate among them at times.
    • lordnacho 5y ago
      Very true. Also at times when you're looking stuff up you get told what the fundamentals are, pretty handy. Eg you are looking at data structures and the docs keep telling you what the Big-O is. So eventually you decide to look it up.
• xchaotic 5y ago
  Yes, you can write some storage solution or yet another database without knowing ACID terms but you will still end up somewhere in the CAP triangle. Using common terms like these makes it easier to communicate with other engineers and makes it more obvious that a lot of things have already been solved and perhaps there’s a library that you can use. In the same spirit you should not write your own cryptographic algorithm and for example you could develop an API that is not RESTful but it’s more interoperable when you are using standards and prior knowledge. I personally would not hire a guy to work databases if he insists on not having to learn about ACID.
  • helge9210 5y ago
    > you will still end up somewhere in the CAP triangle Drop P and you'll end up with both consistency and availability, right? Right? ("This is a trade-off we are ready to accept")
    • NovemberWhiskey 5y ago
      I'm somewhat ashamed to say that, when I interview, a lot of people who claim "distributed systems experience" get some variant of a line of questions that ends in the user experience of systems that do not aim for partition-tolerance.
    • ayende 5y ago
      How do you drop P?
      • helge9210 5y ago
        You just assume network partition is never happening. If calls are synchronous, assume they always reach other side and finish. If async, also assume successful outcome immediately after initiating the call. This "almost always" works.
      • perlgeek 5y ago
        That's the point, you can't. Put quite many people say "you cannot have all three of Conistency, Available, Partition Tolerance", which sounds like you can keep any two / drop one at will. But the right starting point is: "Partitions will happen. When they do, do you drop A or C?"
• ivanhoe 5y ago
  > It turns out my day to day work doesn’t require deep knowledge about database internals and I can mostly treat them as a black box with an API 2. Because of such attitude of the previous dev team my client ended up with DB integrity ruined. Previous guys somehow didn't know they should use transactions when updating/deleting stuff in the DB, because hey, it's just API you call, who cares of mambo-jumbo happening behind the curtains, right? I myself had a similar fuckup with MongoDB a decade ago, because I used it "because it's fast", but failed to read the small letters, and wasn't aware that it achieves that speed by buffering the data for async save, and so has no guarantees it will actually be saved at all. So I lost a lot of data when traffic suddenly jumped, and since those were affiliate clicks lots of people got very pissed about not getting paid, and it almost ruined both my client's business as well as my own, as it was our core client. Lack of understanding of (or even caring to know about) DB internals is also why like 90% of projects I've seen has wrong indices, or often no even a single index set at all. Because, hey, it's someone else's job to think about it, but in reality budgets are limited and team don't have a dedicated DBA or even a capable devops person to notice it, and it just ends up in the production like that. So, in summary: no you don't need to know every in-and-out of every technology out there, no one can do that, but there's a valid requirement that one has to be familiar to those that they actually use - at least those that can seriously bite one's ass and cost a lot of money. And all DB related stuff is very much like that, that is probably the most critical part of the whole system, so no, it's definitely not a black box.
  • kgeist 5y ago
    >Because of such attitude of the previous dev team my client ended up with DB integrity ruined Same thing here, our legacy codebase avoided using transactions, and to this day, after migrating to a new codebase, we still get reports from clients here and there about errors which stem from inconsistent data
    • jhgb 5y ago
      Damn, and I've always felt like I must have some kind of OCD whenever I'm getting a refresher on MVCC/MGA isolation levels and their guarantees and the associated auxiliary locking (say, select for update with lock in Firebird, for example) just to be sure I'm not writing something stupid. Simply not using transactions at all is something I can't even fathom. That's basically no better than blindly mutating shared in-memory data structures in a multi-threaded program. Who would write something like this?
• pkilgore 5y ago
  I mean sure, yes, there's also programmers out there who've been working for years and look at me like I'm speaking in tongues when I talk about closure. The author's casual arrogance about "pixel pushers" only caring about "hotdog stand colors" is just as damaging to the profession -- as it infects the hardest part of getting things right most of the time: teamwork.
  • deleted 5y ago
    [deleted]
  • gehatare 5y ago
    I think you misunderstood his point, I think what he's saying is that even good back end devs are horrible at designing UI and you need different people with different specialisations on a team.
    • lytefm 5y ago
      Yes the author was criticizing the kind of "I have deep CS knowledge, you are just pushing pixels" arrogance.
    • pkilgore 5y ago
      I'm horrible at designing UI too. That's simply not the job of building modern interfaces across multi-disciplinary teams. I care far, far more about data-structures, eventual-consistency, data-design, and types than CSS and divs. These days getting the design to look nice is my two-hour reward for nine days of data-stitching hell, writing backend-for-frontend lambda functions, and negotiating API contracts that actually support the product I've been asked to build. We need to stop assuming that just because a programmer works on client code, that they are in any way less capable that a programmer that works on server code. My point stands: It's absolutely toxic to collaboration, which is the key to success.
      • kragen 5y ago
        I think he was saying that the GUI programmer doesn't need to know how to use a profiler for their work to be valuable, and that if you're good at optimizing you don't need to know how to choose tasteful colors for your work to be valuable. My reading is the opposite of your reading.
• josephg 5y ago
  > not every programmer is dealing with performance issues as part of their job. Some has also specialized in writing GUIs and are more concerned with the user experience and making the user interfaces pretty. This is a really important point that we don’t talk about enough, because everyone gets uncomfortable and feels judged. But I can’t help myself, and I think there’s a lot more to dissect here. I think programming is slowly bifurcating. We’re growing into two disciplines. One discipline requires deep systems knowledge. A CS degree is recommended and if you can’t reverse a binary tree on a white board then you won’t be able to read our code base. Developers in this camp work on rendering engines, Vulcan drivers and schedulers. They spend lunch telling stories about that one time we wrote a game engine in J. Or arguing about type systems. The second group makes most of the software (measured by lines of code). And almost all the software humans actually interact with. They spend their time working around weird safari quirks, arguing about electron, and enjoying the sense of ease and mastery that comes from staying in a single ecosystem for a decade. Getting better at their job looks like getting better at talking to users and customers, making on point estimates and making sure the team releases on time. The part that gets all of us in trouble is that the first skill set is (arguably) harder - and thus much more prestigious. Everyone wants to be seen as an electrical engineer, not an electrician. So people write “software engineer” on their resumes. And then cry foul when they get assessed as a member of that first group. “I’ve never needed to know about red black trees in my career. It’s stupid for anyone to ask about it in an interview. Everyone just crams leetcode. JQuery isn’t flashy but it works and I can solve real problems with it. Hire me you fools, and I’ll show you!”. They’re sort of right. We’re just collectively confused about what sort of job they’re being hired for. I think this confusion hurts everyone. I once wore my fancy engineering hat at a normal consulting gig. I coded up a complex solution to a tricky problem they had and called it a day. After I left, nobody on the team could understand or maintain some of the code I wrote. That caused huge problems for my client after I left. I think they might have regretted bringing me on board at all. But we can’t even talk about this because we don’t have the language. We treat application developers like they’re just junior, in training versions of deep CS systems engineers. But practicing building kick-arse iOS apps doesn’t make you magically good at data structures. And vice versa - doing performance work doesn’t make you good at working with clients. (Ask me how I know). The majority of professional programmers do plumbing / user facing software. We need to destigmatise this stuff so people can be hired explicitly for these roles, based on the right set of skills.
• mmkhd 5y ago
  The author is talking about hiring interviews like it’s some kind of multiple choice test. Interviews should be more like essays. Of course it is not that important that the interviewee knows the exact definition of ACID but they should certainly know what it is about. Knowing about ACID and the problem space it comes from enables people to think about problems that let to the ACID concept as a solution to said problems. It shows that the interviewee might know enough to look things up and might be capable of selecting the right answer in the reference material/search engine results. Knowing the exact definition of ACID and nothing else means that somebody can memorize things which is useful but not useful on its own. You want people that can find a solution and have an somewhat informed opinion about it, not people who can just memorize things. So asking about ACID is a fine thing, but expecting a text book answer is silly. Edit: ivanhoe said it better in their post and I changed my phrasing to be less inflammatory. (My point of different hiring mind sets on different continents is not the point.)
  • throwaway9870 5y ago
    My take is that too many people are telling others how to interview. It is their money, their company, their job, their life. Let them do it the way they want as long as they follow the legal requirements. If you think you have a better way, tell us about it without passing judgement on others. Tell us why it works, how great it is, give us some qualitative and quantitative data. Most of all, enjoy your competitive advantage. But for god's sake, quit telling other people they are doing it wrong.
    • Koshkin 5y ago
      While I don’t disagree, the biggest problem I think is that some or even many interviewers just don’t care or not motivated enough to care whether the candidate can indeed be a great help to the company or the project and approach their interviews in a shallow and formal way.
      • throwaway9870 5y ago
        Then that is a great job for other unmotived people. For motivated people, the poor interview is a great signal to look for a different company.
• deleted 5y ago
  [deleted]
• 7thaccount 5y ago
  The fundamentals are important. In my field of engineering (not software) ignorance of the fundamentals means not knowing how to properly run studies, not being able to accurately make recommendations, not understanding proper cause and effect, not knowing the relevancy of the various settings of the industry standard software...etc etc. It's really hard to find that in new graduates and there is virtually no decent training material. It typically takes 5+ years for just minimum competency, but over a decade before someone begins seeing how everything fits together. Is that common elsewhere?
  • fkarg 5y ago
    I would be interested what field you're talking about - could be any rather specialized field, really
    • 7thaccount 5y ago
      Power grid operations. Things are enormously complex (business rules, standards, software stacks, processes, massive data sets, and of course the fundamentals). Yeah, maybe this is all fields, which is a shame.
• Koshkin 5y ago
  Knowing fundamentals is important. It is simply part of the professional culture, or part of what they sometimes call a degree of professional “maturity.” A programmer who is not aware of the fundamentals will always find a way to write bad code.
  • guax 5y ago
    Yes but there is a catch. I've seen some shit from some fundamental lover programmers. The fundamentals are important but not essential to every job, there is hardly a role they can't improve, but they're not guaranteed to give good outcomes. These days is more important to know how to compose high level components in a simple way than optimizing specific algorithms you can learn one from the other tho.
  • raxxorrax 5y ago
    A better question would be: ACID (after explaining it's meaning again) has competing concepts. Can you think of any?
    • Koshkin 5y ago
      I love these "higher order" questions. Every thinking person should have their doubts or opinions about what is thought of as common knowledge, "best practices," etc., be aware of their limitations, know about alternatives; and, in general, despise any sort of dogmatism - especially in fast developing areas such as programming.
  • kayodelycaon 5y ago
    It is... but the book knowledge version of fundamentals and their actual implementation are completely different when you start asking questions. Even more so when those "fundamentals" are implementation details you don't think about much in your day to day job. Actively recalling knowledge that has become part of your intuition and understanding of the world is hard. I know enough about many things to do basic implementations safely; everything else is paged out to google. The finer details of database transations? Usually not my job, but I used to know more about them and could relearn that information quickly if needed.
• sriku 5y ago
  The Feynman principle applies - it is important to know the thing and not as important to know it's name. In an interview, find out if the person knows them thing or can work it out.
  • TheFreim 5y ago
    > it is important to know the thing and not as important to know it's name Yes and no. For years I did little computer programming projects on my own. Built some neat things, for my purposes at least. But because I didn't have the words to describe things I wasn't able to build a concrete image in my head. When I finally took a CS course and had the words to describe concepts I'd used for so long it was like a switch had been flipped, allowing me to think about problems in a much better way. I knew what many things were but because I didn't have the concepts mapped to concrete terms they remained fuzzy.
  • globular-toast 5y ago
    Exactly. If someone does know what ACID compliance is that's great. We share a common language and that makes things easier. But if they don't, no big deal, but they should still know the concepts. There are people out there who don't know the difference between mongo and postgres. That's lacking the fundamentals.
  • scythmic_waves 5y ago
    Though he does admit [1] > So I had learned already that names don't constitute knowledge... That's caused me a certain trouble since because I refuse to learn the name of anything... What [my father] forgot to tell me was that the knowing the names of things is useful if you wanna talk to somebody else. I think an interview might count :) [1] https://www.youtube.com/watch?v=ga_7j72CVlc https://www.youtube.com/watch?v=ga_7j72CVlc
    • sriku 5y ago
      Yes indeed. The names are relevant for communication (i.e. to become a part of a "discourse community" [1]), but are not indicative of one's competence at a topic. They kind of go hand in hand often due to arranged education, but that's not essential. Names also come handy when you need to search for something and search engines are not powerful at taking your description of what you're searching for. [1] https://en.wikipedia.org/wiki/Discourse_community https://en.wikipedia.org/wiki/Discourse_community
• gigatexal 5y ago
  This is basically because interviewers need to properly advertise the level of depth they want in a role. It's unfair to ask for each engineer to be in the top 5% of engineers everywhere -- not every engineer can be -- but there are roles that don't require such depth. But interviewing in general is tough (I'd go so far as to say it's a shitshow) and there's lies on both ends -- companies and managers and folks on the inside just want the best of the best -- and candidates just want a chance to get in the door -- the incentive to embellish is too high.
  • BeFlatXIII 5y ago
    Interviews are creative fiction: the applicant pretends to be competent and the employer pretends not to be a toxic workplace environment. I’m increasingly convinced that this is not a solvable problem.
• tyingq 5y ago
  The interview style that requires lots of prep studying and leetcode memorization probably does produce the desired result. Workers that will spend non-work time on arbitrary company activities of questionable value.
• hnlmorg 5y ago
  I've found bad interview questions fall into one of three camps: 1. The interviewers aren't subject matter experts themselves but are hiring managers, so they've taken their questions from someone else. 2. The company gets far more good candidates apply than they can hire, so the process is less about removing bad candidates and more about having some arbitrary way of whittling down good candidates. 3. The interviewer is trying to prove how clever they are or the company is. Sometimes for their own ego but more often because they think it might make the company more attractive to work at. If there is a theoretical question I'd normally Google / DDG instead of memorise then I'd usually be honest in the interview and say "it's something like xyz but in truth this is something I double check these days as, pragmatically speaking, it is not a problem that comes up frequently. However it is something I have done before [cite example]". If the questions is asked because of reason 1 or 3 from above, then usually they're happy with that answer. If they ask it because of 2, well as much as I might disagree with their interview process, I'm still not the candidate they're looking for. So we still part of good terms.
  • akudha 5y ago
    In an interview, they gave me access to their codebase and asked me to fix an actual (small) bug. The interviewer showed me where the codebase was, how to replicate the bug, all of that took less than 10 mins. Then he left, told me to give a shout once I am done. Took me about half hour to do it, another 10 mins to explain what I did to fix the bug. There were no other questions - no white board stuff, no algorithm questions, no stupid questions like "where do you see yourself in 5 years?" etc. I still remember the interview nearly a decade later. Obviously this won't work for all jobs, but this will work surprisingly well for a large number of jobs, because most jobs are ordinary. One doesn't need to know complex algorithms to do these
    • Davidbrcz 5y ago
      And it rises legal issues in several countries
      • goto11 5y ago
• darkerside 5y ago
  Author is not completely wrong, but I don't like this attitude of celebrating ignorance. I agree we shouldn't judge others who happen not to know what we know, but IMO it's likely that knowing this concept at a deconstructed level will be helpful to most devs at some point in the future. The ones who don't know it won't even know it would have helped them, because that's how knowledge works. And that's why it's important to celebrate knowledge, not ignorance.
• NewEntryHN 5y ago
  In my experience there is not much to know about the ACD parts of ACID, because they're just guaranties that are obvious to want and which will naturally make your life easier. The I (Isolation) part is the one you'll need to understand whenever you scale up to a point where concurrency starts to become non trivial in your product, mainly because there are multiple levels of isolation, which each provides different guaranties, and you'll need to understand what level your database uses and what it means for your application. As for the overall point of the article, it's just a question of scale. The more you scale the more you need to cut through the abstraction to understand what the hell is going on. Hire accordingly.
  • nickkell 5y ago
    They may be obvious to you, but you'd be surprised at how many people out there are doing stuff without optimistic concurrency control, locking or transactions. I mean Mongo only added transactions for updating multiple documents relatively recently. Plus from what I remember they originally missed out the "D" due to only writing to disk intermittently.
• rockbruno 5y ago
  Oh for fucks sake, every month this topic comes back. It honestly doesn't matter if the fundamentals are useful or not. What gets me is that programmers want to be hired by top-tier companies and earn massive salaries without putting a single drop of effort into actually acquiring the knowledge that justifies that position. Can we just collectively swallow our privilege and stop whining that an employer is asking for proof that you've actually put the effort to be an engineer before they dump a river of money onto you? Look at how lucky you're before whining that the world is unfair, and shut the hell up about fundamentals. The interviews surely aren't perfect, but the constant whining is ridiculous. Why not just study it and be done with it already?
  • Clubber 5y ago
    >an employer is asking for proof that you've actually put the effort to be an engineer before they dump a river of money onto you? But that's the rub, knowing the acronym to ACID isn't proof of anything other than you read about it recently. Asking about the ACID test is like asking what Chipper Jones' batting average was in 1994 when interviewing to be a baseball player in 2021. 20+ years ago, I could recite all that shit from memory, but after building countless systems from the ground up which are still in use today, I can only remember reading about it but I can't recite the words of the acronym. Hiring in IT is fundamentally broken and has been for decades and probably will be for decades. This is an example of it, that is the discussion.
    • rockbruno 5y ago
      Sure, but my counter-point is: "who cares?" Why is it important for the process to the perfectly fair when there's a truck-load of money at play? As soon as you get hired you're set for life, so what's so terrible about having to spend some time learning about a couple of additional concepts? Even if you never use them again, you're still on the win by an unfathomable margin. Not to be disrespectful to anyone, but this "issue" is the personification of that gif with a man wiping his tears with 100 dollar bills. The tech community has become increasingly disconnected from the real world in the past 10 years.
• qwerty456127 5y ago
  To me non-ACID means you can never use any logical reasoning to have an idea of what there is recorded in your database at any given moment. ACID means you execute a piece of code in a transaction and if something goes wrong it fails altogether returning you to the pre-transaction state. Am I wrong?
  • baobabKoodaa 5y ago
    Yes, you are wrong. For example, the "I" in ACID stands for isolation, which offers some guarantees regarding concurrently running transactions. In particular, if you have 2 concurrently running transactions A and B, and A finishes before B, and B fails, then the database does not return to the pre-transaction state (if failing transaction B would cause transaction A to be rollbacked, the Isolation principle would be violated). Furthermore, many real-world databases do not fully provide ACID guarantees, and yet you can reason about the database anyway.
• pkrumins 5y ago
  All you need to know is the `if` statement. That's all.
• mcherm 5y ago
  I feel that this is a perfectly good interview question for a so-called "full stack developer": > Let's turn to databases now. Can you explain ACID to me? I'm not saying that the original article on RoyalSloth was wrong, exactly. It has to do with the way the interviewer approaches the question. For instance, for that full-stack developer I would be PERFECTLY satisfied with an answer that went like this: > Hmm. Well, I don't remember exactly what the letters stand for. Atomic, something something. But look -- some databases, like MongoDB, can sometimes lose data after it has been "committed". Other databases, like DynamoDB, can read just fine from one table but they can't guarantee some basic invariants when reading from multiple tables at once. And some others, PostgreSQL and most "relational databases" fit in this category, jump through hoops (I don't know quite how it works) to make certain that what you see is always consistent. If I were hiring someone JUST to do front-end web design then this wouldn't be relevant. If it's someone more junior then the above sentiment but without the ability to name specific examples would be fine. But I don't want to hire someone to work on interfacing with the database unless they understand it to at least this level. If I were hiring for a database specialist I would expect a much more detailed explanation.
• giantg2 5y ago
  I have 10 years experience and an MS. It's possible I would fail these fundamentals (I have in the past). At my company, we don't talk using big words for tech. This is mostly because we would just end up translating it for the business folks in the room.
• qwerty456127 5y ago
  > How many similarly vague “fundamentals” we have floating around us? Plenty: RESTful Hell yeah, I have hardly ever seen a correct REST API in the wild. People mostly consider any non-SOAP HTTP API RESTful.
• dkarl 5y ago
  > Yet, despite coming up with a distributed archiving system that works in production, I wouldn’t be able to explain from the top of my head what the ACID term means. You could probably talk about the important properties of interactions with a datastore well enough to please a reasonable interviewer. Why assume they aren't reasonable? I really hate the trope of, "XYZ came up in an interview, and therefore I assume the interviewer is making hiring decisions according to a such-and-such rigid criteria I imagined when I went home afterwards." (The conversation with "Joe" of course is imaginary, because you wouldn't already be started with interviews if you hadn't talked about how you were going to evaluate candidates. If this conversation happened in real life, the blog post would be about planning for interviews and not going rogue with your interview agenda when you're part of a team process.) Interviews are designed to figure out where a candidate is with their knowledge, all the way from "they don't know anything about databases" to "they can write a little bit of SQL with help" to "they have 10 years of experience with the database we use for our OLTP, and our expert had a great conversation with them about the technical details of a quirk that bit us in production last week." Depending on the position, these might all be acceptable levels of knowledge for a position, not to mention that companies are often hiring for multiple positions, not all of which have been publicized yet, and are often open to redefining a role for the right candidate. Every candidate has their own idiosyncratic mixture of strengths and weaknesses. Candidates have a hard time believing it, but a hard or unexpected question is usually probing for strength, not weakness. If interviewers only asked questions that a minimally qualified candidate can answer, they would miss your strengths and undervalue you as a potential hire.
• oxplot 5y ago
  Yeh, um, no thanks. I've had to deal with too many race conditions, random data loss and week-long-debugging of locks to brush off the "fundamentals" as nice-to-have. It doesn't matter if you're a frontender or writing a shell script to automate something. If you don't understand atomicity, race condition, locking, etc., not only are you going to shoot yourself in the foot and tear your hair out when shit breaks randomly, but you're going to subject the poor souls who come after you, to unnecessary suffering. One doesn't get good at these fundamentals by getting a Comp. Sci. degree. All of it can be learnt in a few days. What's important is to keep evaluating your code and design all the time against it to ensure you're not building on crooked foundation.
• allo37 5y ago
  I feel like the big issue in the provided example is not so much the fundamentals, but that the "fundamentals" in this case is just buzzword trivia. Maybe a better question would be to ask about atomicity and isolation specifically in the context of a DB? For example, to me a fundamental for C++ development is knowing the difference between an std::vector and an std::list. Can you really be an effective C++ programmer without knowing that? Yes the field is vast and lists and vectors can mean different things in different contexts, but you're applying to a C++ development job so I expect you to know some basics about C++ specifically...it doesn't seem that unreasonable to me.
• metamonster 5y ago
  This promulgation and advocacy of laziness and know-nothing-ism is frightening and all too commonplace nowadays. The ACID example was a bad one, granted, but everyone seems to be giving up after identifying that. I also think that this post is not about interviewing. I am much more concerned with the line the author takes about knowing how a digital computer work is even necessary. How have we arrived at this point? As an example, how seriously would you take an aircraft flight controls software engineer who willfully chooses to never learn how an airplane flies? What if they just claimed that their sole responsibility was to take flight requirements from “people who know how airplanes work” and implement code? Knowing how horrific the results of this attitude is in even low pressure business situations, would you get on the plane he designed the software for? People who live by and spread the idea that one only need know the things he or she is ‘required to know’ are dangerous for engineering organizations. When something goes horribly wrong, your mission critical system crashes, when you get dragged before the higher ups to explain the situation and fix it, the excuse ‘I don’t have to know how this works to do my job’ simply won’t fly. People have lost all respect for the pursuit of excellence. Ask yourself who you would like to have on your team: someone who stops at learning the bare minimum to get paid and inevitably ruins the integrity of a product or someone who continually pursues getting better at their job and accelerates the people around them? Would you rather work with someone who values knowledge or someone who doesn’t? I think it is drastically foolish to defend the toleration of those who aren’t even willing to learn basics like how a computer works in the name of inclusivity, utilitarianism, or egalitarianism. Furthermore, I know a slew of extremely bright, tenacious, and committed young people who are ruthlessly pursuing excellence in engineering. If given the chance and enough time they will easily outperform, outwork, and surpass anyone who adheres to these lazy practices. If you do think this way and don’t want these kids to take your job then I suggest you buckle down a bit and learn some basics.
  • throwawaysleep 5y ago
    > When something goes horribly wrong, your mission critical system crashes, when you get dragged before the higher ups to explain the situation and fix it, the excuse ‘I don’t have to know how this works to do my job’ simply won’t fly. At that point you just get another job and in the interview talk about how the company had bad practices that caused X bad thing.
• mikewarot 5y ago
  Once upon a time I was sitting in a chemistry class at Rose-Hulman, and the professor proceeded to use all the formulae we had learned through the trimester to explain how a semiconductor diode worked, then proceeded to explain transistors, from a purely chemical reaction rate basis. I was in awe... and for a while after that, I thought I understood the basics of electronics. Last year I learned how tubes work, especially when slightly gassy, and thus ignitrons, etc... turns out I didn't know how all electronics worked. There is always another layer to learn about. The ARP address layer of the network stack, for instance. The Unicode layer they added between my days as a Turbo Pascal programmer in MS-DOS, and the present. (Which apparently can be used to hide trojan horses) Always, always, always another layer. The best we can do is to try to understand all the layers that definitely affect us, and a layer or two more as insurance (or just because it's cool to know)
• goto11 5y ago
  Beginners tend to obsess about the precise definitions of terms. Possibly because a lot of teaching is about learning definitions (because it is easy to test) or perhaps because in subject like math the definition really is the meaning.
• mikewarot 5y ago
  I once failed a job interview because the Fortran complier they used handled errors differently than the one I was used to, so they assumed I didn't know what I was talking about.
• bo1024 5y ago
  I think this discussion contrasts two opposite types of "fundamentals". Some "fundamentals" sit at the base of a knowledge pyramid. If an OS developer doesn't know pointers, there's no easy fix for that. You want someone with years of experience building things on top of pointers. But other "fundamentals" are more like things that are used very commonly and thus one expects that experts would be familiar with them, but they sit on top of knowledge pyramids. It's not hard for experts to pick them up. I think this lens can help clarify a lot of these discussions!
• lbriner 5y ago
  I think the example is very poor, it sounds like a atraw man argument. Asking about fundamentals in an interview is, surely, a given? I don't necessarily need everyone to know everything about everything but if I met a dev who didn't know some software principles or a DBA who couldn't explain ACID to at least a basic level, why would I want to employ them? Because they tell me that they just work it out when necessary? I've cleaned up too much code from people who think "just use an array" or searching through a massive list because they don't know how dictionaries work. The interview questions sound more than reasonable and then the OP tries to destroy this by saying that not everyone knows all the details of everything which is not what most people would call questions on fundamentals.
• throwawaygal7 5y ago
  My company went public and was acquired, all while doing basic database shit hilariously wrong and just strapping in memory caches everywhere instead of using indexes. We have two caches and we really just needed to use the dB in a not criminally bad way. But the market didn't care and the people who did the abuse are now director or architects or manager level engineers at other (good) companies. There's some reality that knowing this stuff matters but it honestly doesn't for a huge number of tech startups, at least in this market.
• kragen 5y ago
  ACID is the kind of fundamental which can make the difference between easily constructing a reliable system and constructing an unreliable system with great difficulty. It's a mistake to class it with the MVC pattern (now diluted past all recognition) and SOLID just because they're all acronyms and your source of information about ACID was a shitty Wild Hog book by someone who wasn't clear about what it was either. You can build bridges that don't fall down without knowing the difference between stress and strain; you can build an audio amplifier without knowing the difference between voltage and current; and you can build a database-backed application without knowing what ACID means. But you shouldn't, except maybe as a learning exercise, because it's an enormous amount of effort to produce mediocre results. Understanding ACID allows you to treat a database as "a black box with an API" with enormously better results. I have no patience for the kind of glorification of ignorance in this post. Perhaps it's true that "the majority of programmers" think "something being RESTful means that you can feed it chunks of JSON over HTTP." The majority of audiophiles might think that oxygen-free copper will improve their sound quality, the majority of computer users might think that Google built the Internet, and the majority of people don't speak English. That has no bearing on the knowledge needed to actually build a working hi-fi system, debug an internet connection problem, or successfully converse in English, and neither does popular ignorance about REST (or ACID) have any bearing on the knowledge needed to successfully design a distributed system that works reliably in the face of constant partial failures. (Ivanhoe's post at https://news.ycombinator.com/item?id=29065438 https://news.ycombinator.com/item?id=29065438 is an excellent explanation of what can happen when you lack the understanding of these fundamentals but mistakenly think you can use the database as a black box anyway: "I lost a lot of data when traffic suddenly jumped, and since those were affiliate clicks lots of people got very pissed about not getting paid, and it almost ruined both my client's business as well as my own, as it was our core client.") If over 40 years you spend 83000 hours working, and you spend 10% of them on programming, that's 8300 hours. (If your job title is "software engineer" you probably spend more like 50% of them on programming, but maybe you're a web designer, a database administrator, a sysadmin, a mechanical engineer, or a biologist, so programming is a relatively minor part of your work.) The optimal fraction of that time spent on getting to know the fundamentals --- real fundamentals like ACID, not fake fundamentals like SOLID, though this presumes that you have someone to guide you who knows the difference --- is surely not 100%, because then you'll never get any work done. But it's not 0% either; you won't get much done that way either. It's probably in the range of 20% to 60%, which would be 1700-5000 hours. Learning in your bones what ACID is might take you 5 hours spread over a month or two, so it only takes up 0.3%-0.1% of that time.
• skyde 5y ago
  it’s true that database are lying about ACID and you only get true acid if you change database isolation level from default to “serializable” but on most database (that don’t use mvcc) you would get horrible performance. I still think any programmer using any database should know what “data consistency” you sacrificed for using “Read commited” instead of “serialisable” and how hacker can use it to steal million of dollar of your e-commerce company
• stjohnswarts 5y ago
  I have gotten to where is someone asks me to do a linked list or recursive tree search I just end the interview right there. Ask me their strengths or why a balanced tree is useful, awesome. It's fine I hope they have find the right candidate, but as an embedded person I haven't had to write those in decades and if I need to I'll look it up. Sorry I don't have everything a CS grad has fresh in his mind or something that you write daily but most of us don't
  • jlokier 5y ago
    I find that surprising. When I'm doing embedded work, explicit linked lists are common. Usually in C, sometimes in assembly language. sometimes even electronics on an FPGA. In many of my projects, rustling up a specialised list or tree based data structure comes up as a side effect of optimising performance, which is often required on smaller devices.
• dennis_jeeves 5y ago
  The person who deemed this interviewer capable of conducting a fair interview independently, should be fired in this case.
• mbrodersen 5y ago
  If you know more about the fundamentals than competing job applicants then you increase your chance of getting the job.