Live data from Hacker News

They don't even know the fundamentals

blog.royalsloth.eu

91–100 of 323 posts

Re: They don't even know the fundamentals

#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 using transactions but I wouldn't because there's plenty of databases that can be used reliably that don't have transactions.

Life is more complex than ACID, that's it. Investigate if person understands life, not that they were able to memorise bunch of magic acronyms.

For the life of me I don't remember what SOLID is and I totally fail to parse any written explanation of liskov substitution principle but whenever I see code that violates those I immediately go "please don't do this, that'll cause problems in the future".

Re: They don't even know the fundamentals

#92

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.

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.

Re: They don't even know the fundamentals

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

Re: They don't even know the fundamentals

#94
post #54

Earlier quoted context omitted.

I think the main thing we want to avoid here is situations like the following: - interviewer asks candidate to determine the complexity of some algorithms - candidate is nervous, has a minor brain-fart and flubs a couple of them - interviewer evaluates candidate as lacking basic CS knowledge you learn in 1st year of any CS course Ok in this case we're talking about big-O, but it could really be anything.

I think it should depend on how much money you are intending to pay the candidate and how desperate your company is to hire. By my experience, some companies need a competent body in the seat ASAP, and some are looking for world-class engineers.

But if they’re not competent, then you’ll be stuck debugging/rewriting 6 months of the the incompetent engineer’s work

Re: They don't even know the fundamentals

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

Re: They don't even know the fundamentals

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

> The keyboard is a tool. Yes, but one of many. > If you can't type, you're going to waste a lot of people's time and they may be too polite to say anything, but it's frustrating for everyone around you. I don't think in my career I have ever been alerted to anyone's typing speed being slow. Yes, I've heard endless noise about "the perfect keyboard" and the ins and outs of spring types and junk. But I've never notice…

> But I've never noticed the output of someone because they type slowly.

I do, when I'm pairing with someone, or in any synchronous meeting environment. It may not effect the 'output' of delivered code (for a developer) but it can hinder their ability to pair effectively.

Re: They don't even know the fundamentals

#97

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]

Re: They don't even know the fundamentals

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

You mean a naive one, that is, a useless one...or a practical one? Such as, at least something like LLRB?

Re: They don't even know the fundamentals

#99
post #14

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

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

Re: They don't even know the fundamentals

#100
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 sometimes the requirement is that the engineer being hired is able to come up with efficient algorithms. You don't have to be able to create the textbook binary tree algorithms, but you should be able to derive a reasonably performant algorithm with simple data structures if it matters to the position you're being hired for.

> requirement is that the engineer being hired is able to come up with efficient algorithms.

Coding binary tree is not the way to discover that.

Presenting a task and observing people solving it and explaining computation complexity behind their solution and the thinking behind their solution is how you do that.

Post reply on HN