Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

They don't even know the fundamentals

blog.royalsloth.eu

Post reply on HN
Print view View original

261–270 of 323 posts

Re: They don't even know the fundamentals

#261

Post by chousuke »

ratww wrote: post #156
ivanhoe wrote: 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…

> 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? Sure, you're right, but I'd argue that transactions are is hardly "database internals". Transactions are day 2 of "using a database 101". You don't have to know what ACID means or how transactions are implemented to…

I get the feeling that many people do not even know what problems databases solve. It seems to be common to treat them as an extension to the application's memory that somehow isn't lost between restarts, and the properties, operational caveats and other capabilities of the database are not even considered.

Re: They don't even know the fundamentals

#262

Post by tchalla »

smallerfish wrote: post #229
magicalhippo wrote: post #208

Earlier quoted context omitted.

For me the point would be that a no-frills binary tree is simple enough that any dev qualified for such a position should be able to figure out what needs to be done from the specification, without needing to regurgitate anything. If they can't recall how balancing is done that would be fine with me, as long as they mention it.

Exactly. And that's the reason you'd probably layer the question with some more complex asks after the initial answer. If somebody has memorized the algorithm but then can't explain further, it's obvious they've "regurgitated" without really having a deep understanding of the problem being solved with the data structure. By contrast, a good candidate may not be able to immediately repeat the algorithm, but can reason…

> By contrast, a good candidate may not be able to immediately repeat the algorithm, but can reason their way there pretty quickly.

I know dozens of good candidates who can't get there pretty quickly but are really good. I also know dozens of good candidates who can get there pretty quickly but won't be good enough on the job.

Re: They don't even know the fundamentals

#263

Post by cultofmetatron »

ivanhoe wrote: 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…

> 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 would consider transactions part of the api. I use them all the time in postgres and I'd hardly call myself an expert in the low level details

Re: They don't even know the fundamentals

#264

Post by tchalla »

akudha wrote: post #236
ramraj07 wrote: post #228

Earlier quoted context omitted.

I did something similar and loved it but a friend pointed out That he will fall over with an anxiety attack in such a situation. I always thought the best case would be to offer a choice to the candidate among 2 or 3 different ways to do the interview.

I don't understand why this would give someone anxiety attack - it would suck if the interviewer sat next to me and watched my every keystroke, it wasn't that in my case. He just set me up and left to do his job. I was on my own, until I finished and called him over to show the bugfix. I have anxiety issues when an interviewer asks me some obscure syntax option for grep command or some b-tree stuff that I learned in…

> I don't understand why this would give someone anxiety attack

What can you do to understand why this happens?

Re: They don't even know the fundamentals

#265

Post by jimbokun »

ZephyrBlu wrote: post #90
ivanhoe wrote: 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…

The author says, "I wouldn’t be able to explain from the top of my head what the ACID term means" . I think there is a big difference between not knowing something off the top of your head and being completely unaware of it. If you have awareness of something, you can make decisions based on that awareness without necessarily having a deep understanding. When you have no awareness is when the big issues arise. For ex…

> For example, with your MongoDB fuckup if you had even a vague idea about the underlying behaviour you might have been able to consider the failure scenario ahead of time and prevent it from occurring.

This is going to require being conversant with the terms in that ACID acronym.

> A deep understanding of how MongoDB works probably wasn't required to prevent this incident.

That deep understanding is exactly what was required. If you don't understand how Mongo works, you don't understand the ways it can fail to do what you think it will do.

> If you're aware of them, you can trigger the thought process of "this query is pretty slow, maybe I should look into adding an index because I know that speeds things up".

So why not add an index for everything ahead of time, then every query will be fast, right?

Or maybe you need to have a sense of the cost of adding an index, then. Which may require knowing the different kinds of indexes and what the speed/cost tradeoffs are.

I think in all these cases, not every developer has to understand these things, but if you don't have anyone in your organization that understands them and is thinking about them, things can blow up for you at unexpected times that make your customers very unhappy. And then you might need to hire someone who understands them to fix the mess.

Re: They don't even know the fundamentals

#267

Post by tootie »

ivanhoe wrote: 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…

I don't think use of transactions or any other query or modeling hygiene are "internals". You can just as easily consider SQL to be an API (or really a DSL) for the black box of DB internals. In most cases, you're better off not looking inside the box because DB vendors only guarantee behavior at the API level. You can always identify and improve bottlenecks if/when they actually impact application function. I can write a load of crummy queries, expose them in an API and then just apply some clever caching and the DB will just never be a bottleneck no matter how little I understand it.

Re: They don't even know the fundamentals

#268

Post by smallerfish »

tchalla wrote: post #262
smallerfish wrote: post #229

Earlier quoted context omitted.

Exactly. And that's the reason you'd probably layer the question with some more complex asks after the initial answer. If somebody has memorized the algorithm but then can't explain further, it's obvious they've "regurgitated" without really having a deep understanding of the problem being solved with the data structure. By contrast, a good candidate may not be able to immediately repeat the algorithm, but can reason…

> By contrast, a good candidate may not be able to immediately repeat the algorithm, but can reason their way there pretty quickly. I know dozens of good candidates who can't get there pretty quickly but are really good. I also know dozens of good candidates who can get there pretty quickly but won't be good enough on the job.

Maybe they'd be really good at other engineer positions, but if they can't get to a binary tree algorithm reasonably fast I wouldn't hire them for backend positions that require CS reasoning.

Re: They don't even know the fundamentals

#269

Post by theamk »

ZephyrBlu wrote: post #90
ivanhoe wrote: 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…

The author says, "I wouldn’t be able to explain from the top of my head what the ACID term means" . I think there is a big difference between not knowing something off the top of your head and being completely unaware of it. If you have awareness of something, you can make decisions based on that awareness without necessarily having a deep understanding. When you have no awareness is when the big issues arise. For ex…

Well, the interviewer did not complain about getting answer partially wrong, they complained about getting a blank stare back. The interviews are not like school exams, they are not graded by the number of exactly correct answer.

I don't remember what each letter of acronym means either. But if I was interviewee in this situation, I'd just start talking about transactions from user perspective -- how they either completeley pass or completely fail, and how even with power failure, you are not going to see partial data.

If I were interviewer, I'd accept this answer. No one cares about hearing exact words (0), "user will never see only a part of transaction" is good enough even if person never said the word "atomicity"

(0) According to some sources, Google runs scripted interviews where interviewer is non-technical, and grades answers against a checklist.

Re: They don't even know the fundamentals

#270

Post by marcosdumay »

nostrebored wrote: post #73
jb1991 wrote: post #55

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.

Because an implementation of a binary tree is dead simple.

The fact that you didn't even think about asking if it's balanced or not, and just went into declaring stupid everyone that considers the problem hard is annoying.

I wouldn't want to have an interview with you, or you selecting people for a team I'm on.

Post reply on HN