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

311–320 of 323 posts

Re: They don't even know the fundamentals

#311

Post by wizzwizz4 »

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…

Anecdotal evidence: I didn't know what ACID meant, but I know each of the things:

• the transaction is the minimal (atomic) unit, and must never be split up;

• all transactions (and everything else too) must map valid states to valid states;

• parallel database transactions should be viewed as a directed asynchronous graph over valid states (like Git)

• store stuff on the hard drive rather than RAM (i.e. the hard part of making databases; filesystems are horrible!)

I have fairly deep understanding of these things; I just didn't know the cool acronym mnemonic. (Database engine devs don't tend to use it in their blog posts about the internals of SQLite or Postgres.) “If they didn't learn how I learnt, they don't know anything” is one of my pet peeves.

Re: They don't even know the fundamentals

#312

Post by sriku »

scythmic_waves wrote: post #225
sriku wrote: post #101

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.

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

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

Re: They don't even know the fundamentals

#313

Post by sriku »

scythmic_waves wrote: post #225
sriku wrote: post #101

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.

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

It's been sort of 18 years since I started using another heuristic - if you can google for something, don't bother requiring a candidate to know it. Not an exact principle, but somewhat like that .. in that I'm more curious about how a person thinks in an interview than what he/she knows.

This change in me was triggered when a candidate came in for a dev interview and we were doing the usual whiteboard problem thing back then. Someone on the panel asked "what would you do if you faced this problem on the job" and he said "I'd google for the solution". I recall not being able to make up my mind about whether to hire him right there or send him away :) .. but that was something I hadn't realized back then so the issue was not with him but with me. The lesson stayed.

So .. on the topic, if the candidate didn't know ACID .. an opportunity to google followed by a detailed discussion on it would work for me.

Re: They don't even know the fundamentals

#314

Post by nostrebored »

marcosdumay wrote: post #270
nostrebored wrote: post #73

Earlier quoted context omitted.

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.

If you can’t remember the details or understand what makes the problem hard I doubt it would’ve been fine even given a whole day.

I’ve interviewed a _lot_ of people. The people who gripe the loudest about algorithms haven’t had a chance just from answers to situational questions.

Re: They don't even know the fundamentals

#315

Post by bigbizisverywyz »

protomyth wrote: post #242
vbezhenar wrote: post #171

Earlier quoted context omitted.

> this query is pretty slow, maybe I should look into adding an index because I know that speeds things up On my current work database is riddled with indices over various status columns. Those indices are not selective and basically useless. Worse of all: it's not immediately obvious that those indices are bad, because inserts/updates are fast enough, but they slow system down as they accumulate and there's no easy…

Sadly, a good DBA would be able to give you information on these things, but the DBA like system admins is a fading "not needed" position. I know HN hates stored procedures, but having an application use stored procedures instead of on-the-fly queries allows a team to do the proper optimizations. Databases evolve with use and added records, and few teams devote resources to stay ahead of the changes.

I personally love stored procedures, and Postgres, MSSQL, Sybase and Oracle all provide pretty good languages to implement them in.

In my experience the most reliable and long living projects treat the DB as its own separate product, whose interface to data mutation is via stored procs. The db can then be sanely designed with good data integrity rules (foreign keys, unique indexes and data column constraints).

Then external callers use the stored procs as their API, and then mostly don't have to worry about the internals. You can easily create a web based client, REST calls or a native GUI app that all work directly off the same db.

However they do have to worry about : -connection timeouts -query timeouts -deadlocks

But that's the same for all distributed systems.

Re: They don't even know the fundamentals

#316

Post by marcosdumay »

kragen wrote: post #273
marcosdumay wrote: post #252

Earlier quoted context omitted.

> This doesn’t sound correct to me. Yet the GP says exactly the same thing as you said. He just ignored that the property belongs to the base class.

The GP said "usable interchangeably", which is vague enough to admit a wide variety of interpretations, including the more rigorous one Koshkin posted.

Yet he got unambiguously declared wrong...

Re: They don't even know the fundamentals

#317

Post by jlokier »

stjohnswarts wrote: post #302

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

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.

Re: They don't even know the fundamentals

#318

Post by maximus-decimus »

jb1991 wrote: post #291
nostrebored wrote: post #258

Earlier quoted context omitted.

I mean… it literally is all there is to it

Well, the requirements I faced were to implement the tree such that nodes were inserted with the standard ordering you would expect. Walking the tree to find the best place to insert them, etc.

Again, that's stupidly easy. Right is bigger, left is smaller.

If the current node is a leaf, insert left if smaller and right if bigger.

If not a leaf nods, run the method recursively on the left it it's smaller, on the right if it's bigger.

If they asked you to write a self-balancing binary tree it's one thing, but there's nothing tricky about writing a normal ordered binary tree.

Re: They don't even know the fundamentals

#319

Post by what_is_orcas »

humen99 wrote: post #304
what_is_orcas wrote: post #259

Earlier quoted context omitted.

> 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? It's easy to make an imbalanced binary tree. I once decided that building a binary tree based only on a friend's explanation of how they worked; it seemed like it would be a good learning exercise for myself (I don't have a CS degree). It was like 10 minutes of coding to get it minimally working…

Binary search tree is more difficult than a binary tree. A BST is a BT but a BT is not a BST. So making a normal BT is just pointing nodes.

Huh... TIL, as they say.

Re: They don't even know the fundamentals

#320

Post by lbayes »

Arch-TK wrote: post #106
lbayes wrote: post #57

Earlier quoted context omitted.

There's also an argument here about having (and signalling) respect for one's peers, craft and tools. The keyboard is a tool. To me, it feels disrespectful for a person to expect these high wages when they don't even make the moderate effort involved in learning to use this tool efficiently. In my experience, this usually signals that a person isn't actually interested in continuously improving, feels overly entitled…

Would you say I am being disrespectful because when I learned to type at the age of 12 I wasn't following any official guide and learned to touch type with only ~6 fingers? I type at around 120 WPM on average. Is it just the speed, or do I have to conform to some specific definition of "touch typing?"

Of course the particular technique is irrelevant (to me at least).

I most enjoy working with people who care deeply about their work, and in my experience, those people are often (not always), people who also care about being efficient. In fact, if you're writing code at 120 wpm, maybe you've found a technique worth sharing and teaching! :-)

Post reply on HN