[deleted]
They don't even know the fundamentals
71–80 of 323 posts
Re: They don't even know the fundamentals
#72> 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…
Thank you, ivanhoe!
When I read that sentence, I gasped and thought the same thing.
I've spent a career writing thousands of lines of application code that would have never been needed if the database had been designed properly. But it wasn't because the deployer didn't think they needed "deep knowledge" that day.
We stand on the shoulders of giants who figured out the fundamentals just for us.
The worse the violation (different data types in the same column, ugh!), the more application code (10X) will be needed.
The more code written, the more more maintenance (another 10X) needed.
And none of it ever gets replaced, just migrated to something else years later (if we're still in business).
ASIDE: As for the interview question, I would never ask what "ACID" meant. I'm more interested in understanding than recall. I would just give the candidate a poorly designed database and ask what they would do to fix it.
Re: They don't even know the fundamentals
#73I 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.
Re: They don't even know the fundamentals
#74> “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…
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.
Re: They don't even know the fundamentals
#75Don’t ask questions that can be answered with a web search.
So the onsite interview should be a one day phd program?
This is kind of thinking is why people hire all these leetcode jockeys who can't write working software, and won't stay beyond a few months anyway.
Re: They don't even know the fundamentals
#76Earlier quoted context omitted.
> Don’t ask questions that can be answered with a web search. These days, that’s equivalent to saying “don’t ask questions about what the day to day job requires one to know”. Sites like stackoverflow contain answers to problems that people encounter in their day to day jobs, and if you eliminate those as potential questions, then what should you ask? And what is the value in asking some obscure question, other than…
Here's a question you can't properly answer with a web search for a data engineering role "I'm emitting 10TB of data a day with this schema {X} - it's produced in Avro. Currently we upload it into S3. But, instead, I want to stream into Apache Druid, but also want to make it available for ad-hoc analysis by BAs. What approach would you take?" Can't exactly google an answer to that.
This is basically saying "Ive worked on this issue for days/weeks, but please solve this in a few minutes and impress me".
Re: They don't even know the fundamentals
#77The 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 advantage. But for god's sake, quit telling other people they are doing it wrong.
Re: They don't even know the fundamentals
#78> There is another fundamental that is ignored by a lot of computer users. I think everyone who spends a lot of time behind a computer should learn how to touch type, since typing is still the main way of interacting with your computer. I sort of agree, but anyone typing out code at 120WPM isn't programming, they're writing. Programming is an intellectual activity, not a physical one so learning to touch type is wort…
I've seen this argument before and I don't think I agree. Surely there's a lot of times when I program that are heavy into thinking, but there's also a lot of mechanical work. Refactoring? Typing speed will help you. Going to try out a new approach? Typing speed will help you to see whether it's true or not. Everything else being equal, typing speed will help you try out stuff faster.
Way too many times I have seen fast typers who would spend as much time adding text as immediately deleting it after that and typing something else in its place, over and over. (Maybe that’s the way they think, I don’t know.)
Re: They don't even know the fundamentals
#79> There is another fundamental that is ignored by a lot of computer users. I think everyone who spends a lot of time behind a computer should learn how to touch type, since typing is still the main way of interacting with your computer. I sort of agree, but anyone typing out code at 120WPM isn't programming, they're writing. Programming is an intellectual activity, not a physical one so learning to touch type is wort…
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 noticed the output of someone because they type slowly.
And to be honest, I really couldn't care. Can they code? can they keep to a deadline? are they nice to work with?
if the answer to all three is yes, then I couldn't give a shit about how they type.
> but can't work a hammer efficiently would be ridiculed on a job site.
Only if they need to use a hammer effectively though. If they are laying veneer, carving, using a screwdriver like a sensible person, then a hammer is only rarely needed.
This all smacks of gatekeeping to me.
Re: They don't even know the fundamentals
#80> 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…
Thank you, ivanhoe! When I read that sentence, I gasped and thought the same thing. I've spent a career writing thousands of lines of application code that would have never been needed if the database had been designed properly. But it wasn't because the deployer didn't think they needed "deep knowledge" that day. We stand on the shoulders of giants who figured out the fundamentals just for us. The worse the violatio…
And that's why you have senior engineers and junior ones.
If you are trying to hire, expecting every junior dev to know all this stuff means you'll skip a lot of candidates who can contribute a lot to your business.
They shouldn't be trusted with writing things from scratch. But if your codebase is mature enough, getting db connections, making endpoints atomic and stuff like that already should have a convention so your junior engineer wouldn't have to do it on their own.