181–190 of 323 posts
Earlier quoted context omitted.
Probably pick a different hill to die on. The meaning of "REST" in common parlance is now just HTTP+JSON, nothing more. At best, the url might represent a noun.
I'm not going to die on that hill, but I will gleefully call an API "RPC-over-HTTP" as a kind of silly trolling when this style of JSON-over-HTTP RESTful is equated with cool.
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…
> 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…
I think in many cases, it's that even just having a vague awareness of something prompts you to double-check more often or to do something about it when you aren't really sure.
As an example, I find myself reading about the pros and cons of various PostgreSQL index types over and over again. It isn't really all that important for me to retain every detail about them for immediate recall but knowing that there's enough of a difference motivates me to read the documentation or run a quick web search before shooting myself in the foot.
I tend to think that testing people on this kind of deep knowledge isn't really helpful nor is it indicative of how developers really operate. What you need to test them on is what steps they would take when they aren't really sure and how they learn from it.
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 implore you get to a state where this isn't hard for you, it will make you capable of more.
Earlier quoted context omitted.
You mean a naive one, that is, a useless one...or a practical one? Such as, at least something like LLRB?
A binary tree is just a tree data structure where each node has at most two children. And that's dead simple and every programmer should be able to implement that when aksed. Note that it doesn't even have the search (i.e. sorted) requirement and much less the self-balancing one. You can work your way towards that with the right questions and that would be an acceptable way to structure an interview. Start with somet…
So depending on the actual exercise/interview question you might able to just show that, especially of you have to use pseudo code.
> 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…
> But, that’s only because you are a noob and you don’t deal with the things that I have deal with.
> Someone on the internet
In conclusion: not all software problems require the same implementation.
I don’t run a DB for some deterministic applications I have that can regenerate the same outputs such I don’t need to store it all. I could, in theory, regenerate an entire data set with a seed. Maybe app developers are ignorant and lazy for not designing systems that do that!
What does your one story have to do with “software engineering” as a field?
Sounds like people are conflating problem solving and personal career demands.
Earlier quoted context omitted.
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.
If you really can't, you should get familiar with how data can point to other data, it is fundamental and done all the time.
> 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…
But… I’d like to say this is the kind of problem these quick-boot coding schools fall short on. Sure one can learn programming language X, but that doesn’t mean one has any sort of fundamentals in algorithms, data structures or general database technology.
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.
Yeah I agree that there is no need to go overly academic in interviews. I wouldn't ask about the different O-Notations and what they mean. But if I give a code sample that has three nested for loops over some array and doing string comparisons, the candidate should at least have a vague idea that this might be problematic and could better be solved using sets or maps.
Earlier quoted context omitted.
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.
People who make this comment, I generally don't believe you, or don't believe you have done any programming. If I put a gun to your head and give you an hour, you can't make a node that points to two other nodes of the same type? If you really can't, you should get familiar with how data can point to other data, it is fundamental and done all the time.