Live data from Hacker News

They don't even know the fundamentals

blog.royalsloth.eu

211–220 of 323 posts

Re: They don't even know the fundamentals

#211
post #43

> 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 be…

When I read it, my first thought was that "an API" in this case was SQL.

Understanding why we should use database transactions is not the same, to my mind, as understanding database internals. When the author said they can treat the database as a "black box", my thinking was the they didn't necessarily need knowledge of the database's implementation. People can understand how to effectively work with a database in the general sense (i.e. use transactions) without a deep knowledge of every implementation.

When we start talking about MongoDB, I think that's really interesting because it is so different from our traditional, SQL-first databases like PostgreSQL, Oracle, etc. Our understanding of SQL-first databases isn't all that useful when we try to apply it to MongoDB.

At that point I think we are in agreement: it's unreasonable to think we can treat a MongoDB database as a black box if our base knowledge is only SQL and SQL-first databases. We probably do need someone who has already dug in and dealt with the implementation, how MongoDB really gets things done.

Re: They don't even know the fundamentals

#212
post #26

"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 tran…

> The thing is, did he? Really? Well, in the absence of evidence in the contrary, they probably did.

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.

Re: They don't even know the fundamentals

#213
post #95

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.

A better question would be: ACID (after explaining it's meaning again) has competing concepts. Can you think of any?

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.

Re: They don't even know the fundamentals

#214
post #70

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 probl…

Interviews aren't even like school exams at all. School exams are designed to try to ensure that you learn a certain set of material that was covered in a class. If you missed a bunch of it, that's bad. If at the same time you did independent research in a topic that wasn't covered in the class, it's not the business of an exam to discover that.

School exams are supposed to be fair, in the sense that they only cover the topics covered in class, and only to the level of detail and difficulty covered in the class. They test for weaknesses relative to that standard. When a school exam asks a question, it's because you're supposed to know the answer.

If someone takes the school exam definition of fairness into job interviews, they are going to feel terrified and aggrieved. Interviewers talk to candidates from vastly diverse backgrounds. Other candidates didn't go to your school, maybe didn't go to school in the same country as you, maybe didn't go to college at all. There is no fair, agreed-upon set of standard knowledge. If interviewers restrict themselves to "standard" topics, they will undervalue a lot of people who have unique backgrounds and experience. Not only that, but job interviews can't just measure a candidate's weaknesses against a set standard. It isn't even really a matter of "strengths" and "weaknesses" but wanting to discover a candidate's full capabilities. You don't want to miss a candidate's depth of knowledge in an area simply because you failed to ask any harder questions that would have revealed it. When an interviewer asks a surprising question, it's often not because you're supposed to know but because you might know and they don't want to undervalue you because they didn't ask.

Re: They don't even know the fundamentals

#215

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 interviewe…

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

Re: They don't even know the fundamentals

#216
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.

Re: They don't even know the fundamentals

#217

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…

>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 tha…

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.

Re: They don't even know the fundamentals

#218
post #215

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 interviewe…

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 q…

And it rises legal issues in several countries

Re: They don't even know the fundamentals

#219
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.

Re: They don't even know the fundamentals

#220

Earlier quoted context omitted.

I have a computer science degree from 10 years ago and I couldn't tell you how to implement one. I vaguely know the general principles but I'd have to sit down and start from scratch on how to implement one. Why? The only time I knowingly used them is with database indices. For everything else I do, they are an unnecessary implementation detail. It doesn't matter what Ruby's Set uses.

People who make this comment, I generally don't believe you, or don't believe you have done any programming. If I put a gun to your head and give you an hour, you can't make a node that points to two other nodes of the same type? If you really can't, you should get familiar with how data can point to other data, it is fundamental and done all the time.

It isnt the knowledge itself, it is making sure it works and is tested, etc, all in <45m. It serves as a worse fizzbuzz imo.
Post reply on HN