131–140 of 323 posts
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...
> “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…
Usually I had funny but opposite experience when doing consulting for performance optimizations. At some points either teams converged to people without basic knowledge of data structures or they rushed with something that works (when N in O(N) was small) then scaled up. They get used to lower performance slowly like boiled frog. Then someone is tasked with optimization, but instead of attacking data structure at han…
While academic algorithm astronauts write papers which include Greek math symbols and can be proven correct, most people do... something else.
Optimising the something else would be a huge benefit to the industry. But no one even looks at it. It's just a thing that happens, and there's no research into fixing it or making it better.
> 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…
I think the article also touches on the fact that when you look up the definition of ACID you get a rough description of the acronym and then a description of how it is mostly a marketing term and all the ways real systems can deviate from it. So really the deep knowledge is not so much what ACID means as what it doesn’t.
The article is basically complaining that knowing what ACID stands for is not really a fundamental and that knowing how to use a database is. So I don’t think you really disagree with the OP much either.
> 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…
In the modern workplace there is often quite a bit of communication via a text chat system. A chat where everyone types at 120 WPM is about as fast as the low end of normal conversation speed (120-150 WPM). A chat with several people only doing 40 WPM is much less pleasant.
Email doesn't have the quick back and forth of chat, so slow typing usually won't be directly noticeable to your colleagues, but it can take up a lot of your time.
Someone else already mentioned documentation.
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.
Sorry, but regurgitating binary tree operations is not "coming up with efficient algorithms".
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.
If you audition for the New York City ballet, they don’t expect you to ice skate.
Earlier quoted context omitted.
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?
Nobody talked about implementing a specific variant of a red-black tree when the general topic of self-balancing binary search tree hasn't even be mentioned.
The Feynman principle applies - it is important to know the thing and not as important to know it's name. In an interview, find out if the person knows them thing or can work it out.
Yes and no. For years I did little computer programming projects on my own. Built some neat things, for my purposes at least. But because I didn't have the words to describe things I wasn't able to build a concrete image in my head. When I finally took a CS course and had the words to describe concepts I'd used for so long it was like a switch had been flipped, allowing me to think about problems in a much better way. I knew what many things were but because I didn't have the concepts mapped to concrete terms they remained fuzzy.
> 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…
If you’re implementing interactions with a fairly new database (let’s face it. 10 years ago MongoDB was basically experimental) then it is indeed incumbent on you to understand in greater details what you’re doing.
But if you’re building a CRUD web app, that’s maybe only used internally by your company and backed by SQL Server you probably have to never give it a thought.
Either way, lack of knowledge of a particular acronym, one which is described as basically meaningless in texts that describe it, is not a deal breaker of any sort. And it doesn’t apply just to ACID but most acronyms in tech today, such as REST/SOLID, etc like the author points out.
1. The interviewers aren't subject matter experts themselves but are hiring managers, so they've taken their questions from someone else.
2. The company gets far more good candidates apply than they can hire, so the process is less about removing bad candidates and more about having some arbitrary way of whittling down good candidates.
3. The interviewer is trying to prove how clever they are or the company is. Sometimes for their own ego but more often because they think it might make the company more attractive to work at.
If there is a theoretical question I'd normally Google / DDG instead of memorise then I'd usually be honest in the interview and say "it's something like xyz but in truth this is something I double check these days as, pragmatically speaking, it is not a problem that comes up frequently. However it is something I have done before [cite example]".
If the questions is asked because of reason 1 or 3 from above, then usually they're happy with that answer. If they ask it because of 2, well as much as I might disagree with their interview process, I'm still not the candidate they're looking for. So we still part of good terms.