Live data from Hacker News

They don't even know the fundamentals

blog.royalsloth.eu

231–240 of 323 posts

Re: They don't even know the fundamentals

#231
post #85

Earlier quoted context omitted.

> you will still end up somewhere in the CAP triangle Drop P and you'll end up with both consistency and availability, right? Right? ("This is a trade-off we are ready to accept")

How do you drop P?

That's the point, you can't.

Put quite many people say "you cannot have all three of Conistency, Available, Partition Tolerance", which sounds like you can keep any two / drop one at will.

But the right starting point is: "Partitions will happen. When they do, do you drop A or C?"

Re: They don't even know the fundamentals

#232
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.

There are loads of simple tasks, there should be a bit more reasonaing as to why this is a good filter relevant to the job's day to day.

For example I think writing some logic to filter datapoints or timespans is much better and more practical. But it takes more effort than just opening and pocking binary tree.

Re: They don't even know the fundamentals

#233
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.

That was probably a question to determine basic competency in coding, simple data structures and simple algorithms. I.e. if he can do this, that means he's at least minimally competent. if he can't, then we don't have to waste any more time.

Re: They don't even know the fundamentals

#234
post #215

Earlier quoted context omitted.

In an interview, they gave me access to their codebase and asked me to fix an actual (small) bug. The interviewer showed me where the codebase was, how to replicate the bug, all of that took less than 10 mins. Then he left, told me to give a shout once I am done. Took me about half hour to do it, another 10 mins to explain what I did to fix the bug. There were no other questions - no white board stuff, no algorithm q…

I did something similar and loved it but a friend pointed out That he will fall over with an anxiety attack in such a situation. I always thought the best case would be to offer a choice to the candidate among 2 or 3 different ways to do the interview.

>I did something similar and loved it but a friend pointed out That he will fall over with an anxiety attack in such a situation.

I might, too, but I frankly might do the same to an even more extreme degree for a particularly challenging real-time 1-on-1 interview question from someone staring at me.

All things considered, I think I'd prefer being left alone in a room where I don't feel them over my shoulder while constantly wondering what they might be thinking with each passing second. I can take a few minutes to relax a little, look over the code, and try to figure it out.

Re: They don't even know the fundamentals

#235
post #195

Earlier quoted context omitted.

To add to that, a binary tree is often not really "implemented" but simply encoded in an array. That is, the children of any given node i are 2i and 2i+1 in the array. So depending on the actual exercise/interview question you might able to just show that, especially of you have to use pseudo code.

Correct me if I'm wrong, but isn't this exactly the case where you don't want an unbalanced tree? A degenerate tree is bad enough; a degenerate tree implemented as an array in this way is catastrophic. So it seems to me that if you're refining the topic further in some sort of talk, the topic of balancing should precede the topic of physically representing the tree as an array.

It all depends on the specific topic. If I just want to store my data in binary tree structure without the possibility of deletes and just with an insertion-order requirement, then the tree is automatically balanced and using an array like that is totally fine. The use-cases are probably rare (I can't think of a situation from the top of my head), but binary tree doesn't have to mean search tree.

The self-balancing part is usually added after the search part as balance is trivial/unimportant when the order/position of the elements has no constraints.

Re: They don't even know the fundamentals

#236
post #215

Earlier quoted context omitted.

In an interview, they gave me access to their codebase and asked me to fix an actual (small) bug. The interviewer showed me where the codebase was, how to replicate the bug, all of that took less than 10 mins. Then he left, told me to give a shout once I am done. Took me about half hour to do it, another 10 mins to explain what I did to fix the bug. There were no other questions - no white board stuff, no algorithm q…

I did something similar and loved it but a friend pointed out That he will fall over with an anxiety attack in such a situation. I always thought the best case would be to offer a choice to the candidate among 2 or 3 different ways to do the interview.

I don't understand why this would give someone anxiety attack - it would suck if the interviewer sat next to me and watched my every keystroke, it wasn't that in my case. He just set me up and left to do his job. I was on my own, until I finished and called him over to show the bugfix.

I have anxiety issues when an interviewer asks me some obscure syntax option for grep command or some b-tree stuff that I learned in college decade ago (and never used in real life).

Re: They don't even know the fundamentals

#237
This promulgation and advocacy of laziness and know-nothing-ism is frightening and all too commonplace nowadays.

The ACID example was a bad one, granted, but everyone seems to be giving up after identifying that. I also think that this post is not about interviewing. I am much more concerned with the line the author takes about knowing how a digital computer work is even necessary. How have we arrived at this point?

As an example, how seriously would you take an aircraft flight controls software engineer who willfully chooses to never learn how an airplane flies? What if they just claimed that their sole responsibility was to take flight requirements from “people who know how airplanes work” and implement code? Knowing how horrific the results of this attitude is in even low pressure business situations, would you get on the plane he designed the software for?

People who live by and spread the idea that one only need know the things he or she is ‘required to know’ are dangerous for engineering organizations. When something goes horribly wrong, your mission critical system crashes, when you get dragged before the higher ups to explain the situation and fix it, the excuse ‘I don’t have to know how this works to do my job’ simply won’t fly.

People have lost all respect for the pursuit of excellence. Ask yourself who you would like to have on your team: someone who stops at learning the bare minimum to get paid and inevitably ruins the integrity of a product or someone who continually pursues getting better at their job and accelerates the people around them? Would you rather work with someone who values knowledge or someone who doesn’t?

I think it is drastically foolish to defend the toleration of those who aren’t even willing to learn basics like how a computer works in the name of inclusivity, utilitarianism, or egalitarianism.

Furthermore, I know a slew of extremely bright, tenacious, and committed young people who are ruthlessly pursuing excellence in engineering. If given the chance and enough time they will easily outperform, outwork, and surpass anyone who adheres to these lazy practices. If you do think this way and don’t want these kids to take your job then I suggest you buckle down a bit and learn some basics.

Re: They don't even know the fundamentals

#238
post #195

Earlier quoted context omitted.

To add to that, a binary tree is often not really "implemented" but simply encoded in an array. That is, the children of any given node i are 2i and 2i+1 in the array. So depending on the actual exercise/interview question you might able to just show that, especially of you have to use pseudo code.

Correct me if I'm wrong, but isn't this exactly the case where you don't want an unbalanced tree? A degenerate tree is bad enough; a degenerate tree implemented as an array in this way is catastrophic. So it seems to me that if you're refining the topic further in some sort of talk, the topic of balancing should precede the topic of physically representing the tree as an array.

Yes, you are of course correct. I was thinking of a heap, which is a complete binary tree.

Re: They don't even know the fundamentals

#239

I mean sure, yes, there's also programmers out there who've been working for years and look at me like I'm speaking in tongues when I talk about closure. The author's casual arrogance about "pixel pushers" only caring about "hotdog stand colors" is just as damaging to the profession -- as it infects the hardest part of getting things right most of the time: teamwork.

I think you misunderstood his point, I think what he's saying is that even good back end devs are horrible at designing UI and you need different people with different specialisations on a team.

I'm horrible at designing UI too. That's simply not the job of building modern interfaces across multi-disciplinary teams.

I care far, far more about data-structures, eventual-consistency, data-design, and types than CSS and divs.

These days getting the design to look nice is my two-hour reward for nine days of data-stitching hell, writing backend-for-frontend lambda functions, and negotiating API contracts that actually support the product I've been asked to build.

We need to stop assuming that just because a programmer works on client code, that they are in any way less capable that a programmer that works on server code. My point stands: It's absolutely toxic to collaboration, which is the key to success.

Re: They don't even know the fundamentals

#240

Oh for fucks sake, every month this topic comes back. It honestly doesn't matter if the fundamentals are useful or not. What gets me is that programmers want to be hired by top-tier companies and earn massive salaries without putting a single drop of effort into actually acquiring the knowledge that justifies that position. Can we just collectively swallow our privilege and stop whining that an employer is asking for…

This isn't about studying and going through it once - you have to study it, go through it with most companies you interview with, and then re-study it once you've not done it in your job for a while.

It isn't about putting in the effort. It's that even after you've provably put in the effort, they still don't believe that you've put in the effort, and so they constantly test you to make sure that you've put in the effort.

Post reply on HN