Threads for dylnuge

  1. 1

    http://de interestingly ends up on some advertising page. How does one take over such a page?

    1. 3

      It doesn’t resolve for me. Maybe you have some catchall DNS?

      1. 1

        Have you tried to add a dot ?

        1. 5

          There is no A record for de. You are behind a split-horizon resolver, most likely your ISP’s to inject advertisements.

          1. 2

            Creepy. That would explain why I got different results using my cell network.

      2. 1

        no luck for me either. I wonder if there’s something funky with my DNS. dig A de spits out

        de.			7155	IN	SOA 1623166346 7200 7200 3600000 7200
        1. 3

          That’s just the authority record (see the SOA instead of A) telling you which nameserver is authoritative for the query. There aren’t any A records listed on de as far as I can see.

      1. 15

        “It tests CS fundamentals.” “It tests reasoning through a new problem.” These answers are contradictory

        They aren’t really – they’re alternative answers to the same question, and they both describe a useful outcome. Put together, they give you an idea if the interviewee knows the CS fundamentals and/or can figure them out as they go along.

        Interview at one of the clients I work with involves implementing a binary tree (just the basics, here’s the API, implement adding a new element to it – not even lookups). People we interview generally know what a binary tree is, and usually they have no trouble implementing it – it’s trivial enough that you shouldn’t have a problem with it even if you last saw it at university 10 years ago. We recently had a candidate who was a self-taught programmer with a mathematics degree. We started off showing her a linear search function to code review. She described it well, suggested improvements. The list in the example was sorted, and we asked if the search could be improved somewhat given the patterns in example data. “Well, you could split the list into two halves…” and she described binary search. “Cool, that does algorithm have a name you’re familiar with?” “No, I don’t think so”. Okay then.

        So then there’s the binary tree. The looks at the drawing of it, describes the properties, the implements in in one go, correctly, calling the Node a Knot (translated to Polish they’re the same word). Again, she had no idea if this data structure had any specific name. Naturally she got the job.

        Linked lists may be useless in all applications nowadays (given that CPU caches generally make it an inferior choice in almost every scenario) (bad generalization, see comments below), but they do have a value on interviews imho: they tell you if the candidate knows what the data structures and algorithms lie beyond the APIs they use in their code every day, and if they don’t – even better! It’s easy enough figure it out and to write on the spot – and even if what you write isn’t fully correct, seeing the process and discussing their bugs is still valuable.

        That’s actually a bit offtopic from this article – which is well worth reading in full indeed, and makes sense if you think about it. I think the Spolsky quote actually nails it, even without the historical context – people would still prefer (or think that they’d prefer) to hire Real Programmers [tm] who can deal with pointers rather than “script jocks” who just copy code around.

        1. 20

          Linked lists may be useless in all applications nowadays (given that CPU caches generally make it an inferior choice in almost every scenario)

          This is not the first time I heard this (I recall a specific rust tutorial expressing this in particular), but this is such a weird take to me.

          I work on high-performance datapath in software-defined networking. Those are highly optimized network stack using the usual low-latency/high-io architectures. In all of them, linked-list were fundamental as a data structure.

          One example: a thoroughly optimized hash-table using cuckoo hash, with open addressing and concurrent lookup. It implements buckets as a linked-list of arrays of elements, each cell taking exactly one cache-line. The link-list is so fundamental as a construct there that arguably it is eclipsed by the other elements.

          Another example: a lockless list of elements to collect after the next RCU sync round. Either the RCU allocates arrays of callbacks + arguments to call once synchronized, or the garbage collector consist in a list of nodes embedded in other objects and the reclaiming thread will jump from object to object to free them. The array-based one has issues as each thread will need to reallocate a growing array of callbacks, requiring bigger and bigger spans of contiguous memory when attempting to free elements.

          Another example: when doing TSO on TCP segments, those are linked together and passed to the NIC to offload the merging. To avoid copying around segments of data during forwarding, they must be linked together.

          There are countless other examples, where the high-performance requirement makes the linked-list a good solution actually. It avoid allocated large swath of memory in contiguous chunks, and allows being much more nimble in how memory is managed.

          That being said of course, at the source of those elements (when new packets are received), everything must be done to attempt to pack the maximum of useful data for a fastpath in contiguous memory (using hugepages). But as you go higher in the stack it becomes more and more untenable. Then simple structures will allow building ancillary modules for specific cases.

          I don’t see how linked-list will ever become completely useless. Maybe I’m just too far gone in my specific branch of software?

          1. 11

            Software is full of rules of thumb, some of them are true. I’m pretty sure someone wrote an article years ago on mechanical sympathy where they pointed out that a CPU can chew through contiguous memory a bunch faster than it can chase unknown pointers and since then “everyone knows” that linked lists are slow.

            The reality is always more complicated and your experience optimizing real world systems definitely trumps the more general recommendations.

            1. 1

              I’m pretty sure someone wrote an article years ago

              Bjarne Stroustroup did!

            2. 6

              Linked lists make sense in reality because solutions to real problems are bigger than benchmarks. Complicated custom datastructures with linked lists threaded through them are everywhere, but nobody looks at them when they’re looking to make a blanket statement about how fast linked lists are. (Such statements seem to rest on shaky foundations anyway; linked lists aren’t a thing that is fast or slow, but a technique that is more or less applicable).

              I use linked lists mainly for bookkeeping where objects are only iterated occasionally, but created and deleted often, where they appeal mostly because they avoid headaches; their constant factors may not be great, but they scale to infinity in an uncomplicated way (and if I’m creating or deleting an object I’m allocating something in any event). I don’t often see linked list operations in flame graphs, and when I do it’s normally accidentally-quadratic behaviour, so I replace them with things that aren’t list-like at all.

              Final idle thought: not scientific at all, but I note that linked list nodes can live inside the element itself without problems, while array elements are often indirected through an extra pointer to deal with move issues. While it doesn’t absolutely have to, code using such arrays often looks like it suffers from the same data dependency issues linked lists tend to.

              1. 2

                People like to make performance claims without ever generating any numbers to backup their assertions.

                1. 2

                  True – same is true for “linked list are faster at insertions/deletions” though. I brought it up because I’ve heard it mentioned time and time again in my university days, and now time and time again at interviews etc, always at a scale where it doesn’t matter or is straight up incorrect. I’m sure they’ll always (or: for the foreseeable future) have their place, even if that place is not the common case. All the more reason to understand them even if you won’t often use them.

                  1. 1

                    There seems to be a long tradition of this kind of garbage. Decades ago I used to hear things like “malloc is slow” from my senior colleagues with nobody being able to explain to me (the young punk) what lead to the assertion.

                2. 7

                  people would still prefer (or think that they’d prefer) to hire Real Programmers [tm] who can deal with pointers rather than “script jocks” who just copy code around.

                  Real Programmers™ is already a fallacy though that tends to amplify the issues on teams by hiring a group of people with very similar strengths, flaws, and viewpoints.

                  Put together, they give you an idea if the interviewee knows the CS fundamentals and/or can figure them out as they go along.

                  This may be true for some questions, like your binary search example, but I don’t think it’s true of the majority of linked list and pointer type questions that are asked in an interview setting. Linked list cycle finding (i.e. tortoise and the hare) comes to mind—a lot of people in the early 2010’s were defending this as something that either tested if you knew fundamentals or if you could piece them together, but it’s been pointed out half to death by now that the algorithm itself wasn’t developed until years after cycle finding was a known problem with people trying to solve it—almost everyone who passed a tortoise and the hare question either knew it in advance or was given hints by the interviewer that led them there without the interviewer believing they’d given it away (which is a pretty fraught and unnormalized thing).

                  In general, I think this is a high ideal that is really hard to build for and people convince themselves they have solved for it at far too high a rate. When I first started interviewing for software jobs (~2010), I learned quickly that if you knew the answer or had seen the question before, the right thing to do was to pretend you hadn’t and perform discovering the answer. This is a problem with nearly all knowledge-based interview questions; there will always be a degree to which you’re testing if the candidate is connected enough to know what the questions will look like ahead of time and what kinds of things will be tested.

                1. 4

                  Great analysis and exploration, and it makes a lot of sense that these questions emerged from an era where they were actually practical and common concerns!

                  I do think that Spolsky and Cracking the Coding Interview probably have less influence here than the overall power of inertia does; it’s the classic answer of “I ask the interview questions I already learned to ask, which happen to be ones that I’m familiar with anyways because I was asked them.” People move around in the tech industry and bring their questions and interview training with them, and startups often have a lot to think about and “how do we design an interview process” is an easy thing to put on a back-burner: just use the one you already learned at Google (it was good enough for Google). Spolsky’s article feels more like a rationalization of an existing behavior than a push to change or introduce a new one.