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

121–130 of 323 posts

Re: They don't even know the fundamentals

#121

Post by gruez »

bsenftner wrote: post #29
eussg wrote: post #8

I like the Zoho strategy of just hiring high school kids and training them - https://m.timesofindia.com/india/this-man-is-also-driving-on...

I've worked at visual effects studios working on feature films, and in that industry (where proprietary workflows rule) there is always an education department. Even if one used to work there, being gone for a year is enough to make one useless as the workflows change radically, VFX technologies move fast. When I spent time consulting at web shops, I was dismayed at the undocumented and loose workflows, plus no proce…

>I get the sense the web is the worse of modern tech exploitation work practices.

Web work is exploitative because... the workflow is undocumented? If it pays well, who cares?

Re: They don't even know the fundamentals

#122

Post by MauranKilom »

smallerfish wrote: post #87
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 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.

Sorry, but regurgitating binary tree operations is not "coming up with efficient algorithms".

Re: They don't even know the fundamentals

#123

Post by guax »

Koshkin wrote: 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.

Yes but there is a catch. I've seen some shit from some fundamental lover programmers. The fundamentals are important but not essential to every job, there is hardly a role they can't improve, but they're not guaranteed to give good outcomes. These days is more important to know how to compose high level components in a simple way than optimizing specific algorithms you can learn one from the other tho.

Re: They don't even know the fundamentals

#124

Post by josephg »

mqatrombone wrote: post #88
josephg wrote: post #61

> not every programmer is dealing with performance issues as part of their job. Some has also specialized in writing GUIs and are more concerned with the user experience and making the user interfaces pretty. This is a really important point that we don’t talk about enough, because everyone gets uncomfortable and feels judged. But I can’t help myself, and I think there’s a lot more to dissect here. I think programmin…

The best programmers are better at talking to users and customers, because that is the harder skill. Programming isn’t a solo activity - at the very least the programmer is working with their past and future selves. Which of Linus’s projects have had the bigger impact - Linux or git?

> The best programmers are better at talking to users and customers, because that is the harder skill.

Uh, what? Most humans find social skills much easier to learn than crunchy engineering skills. Good social skills are way more common in society than, say, deep knowledge of algorithms and data structures.

But it’s not a competition. As you say, programming is rarely a solo activity. Our projects can fail due to a lack of teamwork. Or a lack of technical skill. Or a lack of empathy with our users. Or a lack of leadership. Or a dozen other things.

We need (and need to value, depending on the project) all of this stuff.

Re: They don't even know the fundamentals

#125

Post by tinco »

p2t2p wrote: post #91
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…

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…

Exactly, the acronyms should be viewed as tools for the interviewer, not as trivia for the interviewee to know. Asking the interviewee to explain ACID or SOLID is fine, but if they don't know the acronyms that shouldn't be an instant fail, it just means the interviewer has to put in a little more effort. The interviewer should go deeper and say "Given we're using this data to do this, which of the options of the MongoDB insert should we use?" or for SOLID, show them a piece of code and ask "What criticism do you have for this code? How would you refactor it?".

Given how some people study for these interviews, you might be better off going deep either way, to avoid getting rehearsed answers on these trivia questions.

Re: They don't even know the fundamentals

#126

Post by Aeolun »

guax wrote: post #99
AmericanChopper wrote: post #52

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…

Not really, they remain fast enough, there’s just no easy way to scale them past a certain point. Or there wasn’t anyway, I believe with spanner and CockroachDB we’re getting pretty close.

But 99% of projects do not come even close to the scale where you need that.

Re: They don't even know the fundamentals

#127

Post by AmericanChopper »

guax wrote: post #99
AmericanChopper wrote: post #52

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…

There are very few RDBMS usecases where scale is a legitimate performance concern. Index scans scale to a very, very high cardinality.

There are use cases that aren’t best suited to an RDBMS at any scale, like managing a collection of denormalized documents, or a graph. But in my experience, considering these factors isn’t what’s motivating adoption of Mongo, or Dynamo. Your key lookups will always be fast (until you get a hot shard), but when you cram a highly relational set into a document db, eventually you’re forced to realize that there’s a lot of mutations and access patterns that you simply can’t implement, because you chose the wrong tool for the job.

Either that or you’ll decide that it’s a good idea to implement your own concurrency control mechanism on top of your document database. Which I’ve personally seen at least 3 people try and do.

Re: They don't even know the fundamentals

#128

Post by smallerfish »

p2t2p wrote: post #100
smallerfish wrote: post #87

Earlier quoted context omitted.

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.

It's a fine way of doing it, although certainly it shouldn't be the only algorithms question.

It's a simple data structures / algorithms question. Can you think in terms of how data is stored in memory? Do you understand the tradeoffs of storing data in one form or another? Can you work with recursive algorithms? Given a challenge of having to think about data in a form you haven't recently, can you wrap your mind around the characteristics of that data structure?

If you're getting asked all this for a ReactJS UI building job, then the interviewer is probably off-base. But otherwise, make sure you're applying for jobs you're suited for. If you don't want a job where coming up with efficient algorithms is important, that's fine - there's plenty of others out there.

Re: They don't even know the fundamentals

#129

Post by thingsgoup »

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.

I asked this once as a take home for an interview. First, I copied the first hit for “implement binary tree in C” from google. I made sure it compiled and then deleted the implementation of the insert method. That was the take home. I wanted to know that the applicant could reimplement this one missing function and compile the project and not get immediately stuck.

Re: They don't even know the fundamentals

#130

Post by joshspankit »

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…

Came here to address his part of the article.

My statement is that it was a terrible example, but the core principle stands. Yes, we should all definitely understand how the storage layer works (and anything else that could corrupt data) but no one needs to have the laundry list of acronyms memorized.

Post reply on HN