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

171–180 of 323 posts

Re: They don't even know the fundamentals

#171

Post by vbezhenar »

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…

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

Re: They don't even know the fundamentals

#172

Post by mcherm »

I feel that this is a perfectly good interview question for a so-called "full stack developer":

> Let's turn to databases now. Can you explain ACID to me?

I'm not saying that the original article on RoyalSloth was wrong, exactly. It has to do with the way the interviewer approaches the question. For instance, for that full-stack developer I would be PERFECTLY satisfied with an answer that went like this:

> Hmm. Well, I don't remember exactly what the letters stand for. Atomic, something something. But look -- some databases, like MongoDB, can sometimes lose data after it has been "committed". Other databases, like DynamoDB, can read just fine from one table but they can't guarantee some basic invariants when reading from multiple tables at once. And some others, PostgreSQL and most "relational databases" fit in this category, jump through hoops (I don't know quite how it works) to make certain that what you see is always consistent.

If I were hiring someone JUST to do front-end web design then this wouldn't be relevant. If it's someone more junior then the above sentiment but without the ability to name specific examples would be fine. But I don't want to hire someone to work on interfacing with the database unless they understand it to at least this level.

If I were hiring for a database specialist I would expect a much more detailed explanation.

Re: They don't even know the fundamentals

#173

Post by kayodelycaon »

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.

I have a computer science degree from 10 years ago and I couldn't tell you how to implement one. I vaguely know the general principles but I'd have to sit down and start from scratch on how to implement one.

Why? The only time I knowingly used them is with database indices. For everything else I do, they are an unnecessary implementation detail. It doesn't matter what Ruby's Set uses.

Re: They don't even know the fundamentals

#174

Post by littlecranky67 »

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 with several companies that tried that, in the end once the juniors became experienced and skilled enough, they took offers from other companies with a much higher salary.

The issue is that training/skilling juniors or fresh university graduates costs you money and slows you down (as you need to assign senior engineers/mentors to assist them). It is not unlikely that a newly joined junior employees only costs you money and decreases throughput/value for your company in the first 6-12 months, but you still pay them a (decent) salary. So once you got them skilled, you as a company would probably need to raise the salary to market/senior level to keep them - given the mass amount of recruiter approaches we in IT get. In that case, you could just start off hiring seniors only in the first place.

This is an issue I see everywhere, nobody wants to hire freshly graduated and everybody is only shopping around for seniors.

Re: They don't even know the fundamentals

#175

Post by sushsjsuauahab »

smcl wrote: post #152
sushsjsuauahab wrote: post #74

Earlier quoted context omitted.

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.

That's true to some extent, but I am quite sure even the worldest-of-class engineers have tripped up on a question or two and went on to get a rejection. If such people truly are talented then they'll have no trouble getting hired elsewhere and the companies in question would be blissfully unaware what they missed out on.

Such companies deserve to fail if so, as the supply of such engineers is limited and allegedly they need such engineers to survive :)

Think Sears vs Amazon-- which company would know what gold was if they fell into a pile of it?

Re: They don't even know the fundamentals

#176

Post by sinsterizme »

dan-robertson wrote: post #145
smcl wrote: 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.

Just say everything is O(2^N) and you’ll be technically correct most of the time. If the interviewer says that it’s wrong, they don’t know their fundamentals.

Can you explain? I clearly forgot the fundamentals :p

Re: They don't even know the fundamentals

#177

Post by only_as_i_fall »

doctor_eval wrote: post #22

If you’re writing database applications in a commercial environment then knowing what ACID means is part of your job. If you don’t know that, for example, debiting one account and crediting another needs to be done inside a transaction - or the converse, what you need to do if you don’t have access to transactions - then you shouldn’t be anywhere near a database. Fundamentals are actually important. You don’t have to…

I think the takeaway from. The article is that if this I'd the case then interviews should drop all the meaningless jargon and just ask a candidate to sketch out a solution to a problem where they would have to think about atomization of DB operations.

Re: They don't even know the fundamentals

#178

Post by giantg2 »

I have 10 years experience and an MS. It's possible I would fail these fundamentals (I have in the past). At my company, we don't talk using big words for tech. This is mostly because we would just end up translating it for the business folks in the room.

Re: They don't even know the fundamentals

#179

Post by Arch-TK »

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?

Being able to work with another skilled programmer (be that yourself in the future or someone you're working on a kernel with) is not the same kind of skillset as being able to talk to an end user about what the pain points are in their day to day work and trying to actually sympathise with them and understand what problems they're encountering without making the rookie mistake of taking everything the user said at face value and designing a system around it.

These are disparate skillsets and both of them are difficult to master. Claiming one is harder than the other is really quite shallow. Some people are going to naturally have an easier time picking up one skillset while other will have a naturally easier time picking up the other skillset. I think rather than trying to pretend like people should stop focusing on hard skills and start focusing on soft skills, we could realise for a moment that it does nobody any good to take people who are good at one task and insist that they must retrain for another when there are already plenty of people who are good at the other task.

It would make more sense to get these groups of people to learn just enough of the opposite person's skillset so that they can effectively communicate and as a result form a well functioning two-sided system where one group of people talks to users and analyses their requirements and the other group of people actually works off of these more concrete better defined requirements to actually implement the software.

If you think that "soft skills" are harder than "hard skills" it's probably because they're harder for you, that doesn't mean they're harder for everyone, and instead of pretending like this is some kind of major flaw in your own professional development, you could treat it as a gap which could be filled by people who have the opposite view of difficulty.

Post reply on HN