Live data from Hacker News

They don't even know the fundamentals

blog.royalsloth.eu

111–120 of 323 posts

Re: They don't even know the fundamentals

#111
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…

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

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.

Re: They don't even know the fundamentals

#112

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…

I would be interested what field you're talking about - could be any rather specialized field, really

Re: They don't even know the fundamentals

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

Re: They don't even know the fundamentals

#114
post #17

Earlier quoted context omitted.

Do someone really needs to learn touch typing? It comes naturally when you are using computer daily.

What comes naturally when using a computer daily is usually bad touch typing, i.e. not having to look at your fingers, but typing with only four or maybe six of them using weird, possibly unhealthy, techniques.

I can't stand those supposedly ergonomic keyboards that have been chopped in half, and I didn't understand why anyone would want one until I recalled people learned touch typing.

My naturally acquired typing style involves me holding my hands hands in just about the same angle as those "ergonomic" keyboards, but just using a regular keyboard. Fingers rest on LShift, A, W, D, and K, O, P, Ø with both thumbs on Space.

Should be noted that's on a "105-key" Nordic keyboard with US layout when not writing Norwegian, so the Ø becomes '.

For me this has worked quite fine for over 20 years. I haven't bothered measuring my typing speed because it's never the limiting factor.

Re: They don't even know the fundamentals

#115
post #82
post #59

Earlier quoted context omitted.

>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

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…

> Who would write something like this? Many, many people.

Re: They don't even know the fundamentals

#116
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…

Putting althe modification resulting from an API call within a transaction doesn't do anything bY itself.

Re: They don't even know the fundamentals

#117
post #91
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…

You're right but you or more precisely that interviewer is also wrong. Understanding the way your storage works is crucial, yes. But you ensure people understand it not by asking "Explain ACID to me" but by asking to design a certain system and observing them figuring out requirements and asking questions. You then ask follow up question about consistency and reliability, you probably even can ask about benefits of u…

> I totally fail to parse any written explanation of liskov substitution principle

Off the top of my head, "all child classes should be usable interchangeably when dealing with an interface/base class". I guess that's too imprecise to qualify as "written explanation"?

Re: They don't even know the fundamentals

#118
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…

> 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?

There's a difference between knowing the internal implementation, and the pros/cons of different usage patterns. What you're talking about is having mastery over an interface. This is distinct from knowing the internal implementation.

As someone who used to work as a hardware engineer, I can assure you that there's a tremendous amount of hardware internal-implementation-details that you're ignorant of. But that doesn't get in the way of you being you a great developer, as long as you spend some time understanding the interface and the recommended ways to use the hardware black-box. The same applies to what the OP is describing.

Re: They don't even know the fundamentals

#119
post #99

Earlier quoted context omitted.

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.

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…

Except they are also popular with people that are not working "at scale" where that would matter.

Re: They don't even know the fundamentals

#120
post #5

> 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. Plea…

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.

Post reply on HN