1. 34
  1. 29

    Oh man have I ever seen this before. Like, four or five times.

    This is what can happen when a mid-level developer, who has been living in a dysfunctional organization long enough without supervision, begins having the misplaced belief that the passage of time has made them a senior, but still has an internal lack of confidence, fear of being displaced, and imposter anxiety. I know that sounds oddly specific, but it happens like clockwork just about everywhere. In an earlier life, it happened to me.

    The result is that they feel like they have to design an interview like the big boys do, but they design it to impress the target that they are serious professional engineers, with limited regard for the question’s relevance, expressivity, or value. Often it’s cargo culted from other sources, even other languages. And almost never is it a question which the interviewer has taken the time to answer completely themselves.

    In earlier-me and their defense, the composition of a valid interview process is not covered in any CS schooling, and is itself an incredibly complicated psychological, legal, and technical minefield that even dedicated, caring, focused teams in high-functioning organizations (e.g. Google) fuck up for years.

    What we need is a trusted certification authority.

    1. 8

      I absolutely agree that the world of professional programmers would benefit from a trusted certification authority, but I’d like to take it a bit further, to something more akin to what doctors and lawyers have. In both of those professions, we recognize the possibility of real harm to innocent people if the job is done poorly, and so practitioners of those professions are not only certified by a central organization (the American Medical Association and American Bar Association, in the US), they are answerable to that organization. These organization set out rules of ethics for their membership, in addition to certifying that members meet minimum standards of quality. I would argue that the quality certification is doubly important for programming giving that a sizable portion of the field’s population is composed of largely self-taught individuals.

      1. 7

        Do see the previous discussion about this, a month ago.

    2. 13

      Question to lobste.rs here: Is it necessary for a Ruby developer to know how to implement a linked list at all?

      To me that sounds like a weird thing to test for in an application developer since practically all application languages have their own list object.

      1. 11

        Actually, I have an interesting data point there. I just had a friend join me at Google, after they’d spent more than a decade at a large defense contractor well-known for both software and hardware. Google’s interviews are famous for involving algorithm questions - slightly more complicated than linked-list implementation, but it would be hard to pass them without knowing it as background knowledge. The other company’s are not.

        According to my friend, many of the highly productive programmers they know from the other company will cheerfully talk about how glad they are to leave their undergrad algorithms courses in the past and forget everything from them. Googlers… have a contrasting attitude, which was a large factor in coming here for this friend, and for myself.

        My conclusion is that whether data structures and algorithms knowledge is important to programmers depends on the nature of the work, and is also a culture question. It would be a surprise here to meet a coworker who wasn’t at least interested in discussing algorithms topics, even though they are only occasionally of direct importance.

        1. 7

          Depends on the work you’re doing. Plenty of developers can do their jobs perfectly well without understanding fundamental data structures.

          It would seem impossible to do effective performance analysis & many other tasks without understanding how basic data structures & algorithms work, though.

          1. 9

            That is to say: is it necessary in order to develop? No.

            Is it necessary in order to be successful long term? Almost certainly.

            1. 5

              Depends wildly on what you mean by successful, and what you’re working on in the day to day. Does seem like a waste of money to take a bunch of algorithms/programming classes and still be unable to implement a linked list.

              1. 4

                There’s an implicit assumption here that the primary goal of a college education is to be marketable. For many I would imagine that becoming marketable is not in fact their primary goal, and is superceded by things ranging from fulfilling the desires of some real or imagined societal or familial pressure, to broadening their cultural and intellectual horizons through interaction with people of varying backgrounds and fields. That’s not to say that being marketable isn’t important (I think it is quite important for long term happiness, as much as we’d like to imagine we can all be happy making low wages working with a non-marketable degree), but that we in professional STEM fields may overestimate the degree to which others value the marketability of their degree.

          2. 7

            It’s important to know how it’s implemented, so that in the event you find yourself using one (even if it’s fundamental as in erlang or in a stdlib somewhere), you understand its characteristics. Actually performing the implementation is, however, as you say, utterly pointless now, just like implementing any sort or any tree.

            1. 7

              I think its also important to know from a communication perspective. When I’m working with other developers I expect some basic fluency with the fundamental data structures and algorithms. I wouldn’t expect someone to implement a linked list but I would expect them to understand when the business problem can be well modeled like a linked list or tree and be able to communicate the idea using those terms.

              Writing a simple version of either is a easy way to demonstrate that understanding.

              1. 3

                I don’t know about ‘utterly pointless’ – understanding how different trees or sorts are implemented is valuable in recognizing other datastructures you have to build that are near-copies. It’s perhaps not super relevant to CRUD-building, but if you’re doing anything nontrivial behind that CRUD (for instance, many of the applications I’ve worked on have had very nontrivial business layers, involving stuff like decision support trees, etc). Understanding how to structure those trees effectively relied heavily on my understanding of abstract datastructures.

                I’m certainly not saying it’s the most important thing, but ‘utterly pointless’ is maybe a bit overzealous. This goes for things like knowing how to implement depth-first vs. breadth-first search, too – or understanding the complexity of a custom merge-and-balance operation vs. implementing a self-balancing tree (the aforementioned decision support tree program involved a fair amount of theory in how to effectively implement, whether via a M&B approach, or an online/self-balanced approach).

                1. 5

                  I agree you need to know how to use trees, and communicate about their use; and that some stdlibs don’t have exactly the right tree types for every possible use case. But the context here is what questions you’d ask in a developer interview. Asking for a de novo implementation of an online red-black tree implementation merely tests whether the interviewee has recently completed an algorithms course in college.

                  1. 5

                    Ah – that I totally agree with. I’m not sure I could give you a de novo implementation of a red-black tree without the aid of a few pots of coffee and a couple of algorithms books. Much less on the fly in an interview.

                    1. 6

                      As you say, the setting and the time constraint make even simple things much harder. “Implement this data structure” is NOT a good interview challenge, because it takes a few hours to do properly, even with reference materials at hand.

              2. 4

                As just one data point, I am a Ruby programmer of 4 years now and I do not know how to implement a linked list.

                1. 2

                  That’s awesome. I bet there are a very large number of python and php programmers who have the same experience, and i bet most of you folks can go to your graves with fulfilling careers and lives without that ever being an issue. All of those languages are mutable and strongly prefer arrays and hash tables/dictionaries over linked lists anyway in their stdlibs.

                2. 0

                  If the answer is “no”, should they know how to implement anything? On the other hand, it seems really strange they asked for it to be implemented in Java.

                  I wouldn’t expect them to know all the details off the top of their head, but it’s not a very difficult problem at all. Even if they’ve never heard of linked lists before, they should be able to code it up once they know it’s a series of linked nodes. It’s not like they’re asking for some exotic balanced tree with tons of pointer juggling.

                  That said, 30 minutes to implement the whole List API for a junior developer is a little tight. Hearing it was 25 public methods sounded unreasonable, but looking at the docs, most of them are just wrappers around some variation of a while(…) loop, so it ends up not being too bad. If I had to use it as an interview question I’d probably bump it up to 60 or 90 minutes, though.

                  I’d be interested in seeing the code the author and his co-workers came up with. 6 hours seems like a really long time to not get the whole thing working.

                3. 12

                  For the last couple of years, I’ve settled on an interview question that seems to work well for developers with different ranges of experience:

                  Inspired by bitly, we’d like to implement a service that shortens urls.
                  Ex: https://www.google.com/maps in, https://bid.ly/{abcdef} out.
                  You’re expected to provide two HTTP endpoints:
                  1. POST /shorten, which given a “long” url, returns a shorter one.
                  2. GET /{short_url} redirects to the matching long url.
                  Bonus points for:
                   * implementing a trivial hash function
                   * choosing a data store to implement persistence
                  Programming language doesn't matter, pseudo code is fine, using well known libraries/frameworks encouraged.
                  Time: 45 minutes.

                  It seems to have both practical aspects (handling HTTP req/resp), tiny little bit of theoretical work ( what makes a good hash function?) and also depth when it come to choosing a datastore.

                  I’d love to hear if someone thinks this could be improved, too vague, too difficult…

                  1. 2

                    Are you saying that the hash function should be implemented by hand for bonus points? What would be the problem with using md5 and then checking for collisions?

                    1. 13

                      Bonus points for refusing to implement your own hash function :-)

                      1. 4

                        md5 output might be larger than input, so you’d have to truncate the output, increasing collisions.

                        Most canditate start with the most basic hash function:

                        def my_hash_fn(input):
                           count = 0
                           for char in input:
                              count += ord(char)
                           return count

                        We then discuss how to reduce collisions, or whether we can use a different approach: base64(auto_increment id) in RDMS. Then we discuss which characters might break not work well and usually agree that using a slightly more restrictive base might be a better solution, if less efficient.

                        It’s all about solving a problem, expressing tradeoffs and having a good time.

                        1. 1

                          That actually sounds like a great interview process, and it reminds me of the one I went through to get my current job. I really like that your bottom line was

                          It’s all about solving a problem, expressing tradeoffs and having a good time.

                          Because it seems like a lot of companies think the interview process is the time that they get to feel good about being better than you, and then proceed to hire you based on whether they think you will fit into their clique.

                    2. 11

                      I’m surprised the article never mentioned the most glaringly obvious fact - the interviewer clearly had no real idea what it took to implement List<T>!! I imagine it played out like this in their head:

                      1. What’s a good simple data structure question?
                      2. I know - let’s have them implement a linked list!
                      3. Maybe that’s too vague?
                      4. I know - Java has a List interface; having them implement that should make it nice and concrete

                      or alternatively

                      .3. Maybe that’s too trivial?

                      .4. I know, let’s also see if they can follow some sort of industry standard while doing so!

                      1. 6

                        Or perhaps the interviewer knew, and was looking for someone who would also know, and could clarify the question with “List<t> is pretty big, which parts of it are most important for you?”.

                        Because in the real world people ask you to do things they don’t actually need with an unreasonable timetable all the time, and being able to go back and forth to figure out what is important to them is a very important skill.

                        1. 3

                          Depends … If the question is “implement.the basics in a way compatible with List and fill in as many other methods as you get around to” that’s probably a good exercise in document wrangling and writing failing tests.

                          1. 1

                            The plus side is that the author’s friend got to avoid that job. sigh

                          2. 4

                            My personal experience in interviewing junior developers is that it’s much better to just give them a small take-home project that can be completed in a couple of hours and is at least reasonably analogous to the actual work they’d be doing if hired. And if possible, the person evaluating the sample should do so before talking to the candidate so that it doesn’t get biased.

                            1. 1

                              Do you pay them for their time?

                              1. 5

                                We don’t, though that’s an excellent suggestion. We do, however, give several days to send back the project so that it doesn’t place an undue burden on them. Between that, relatively short interviews (just a couple of hours total), and no whiteboard problems, I think the interviewing process is pretty reasonable.

                                Note: This reflects my experience in my part of the organization, but may not hold for the entire company.

                                1. 1

                                  Do you think you would need to? Not leaning one way or the other, just thinking about lots of those jobs that are the “solve this riddle that gives you the email address to apply for the job” type places.

                                  1. 7

                                    The problem with not paying them for their time is that you implicitly introduce bias in favor of those who can work some number of hours without pay, and against those who can’t. Let’s say I am applying for the job, and I currently work several jobs to support my family. I can’t give up several hours of paid time for the possibility of a job. It’s a miniature version of one of the major problems with unpaid internships, that they can only really be done by people with enough money to afford the unpaid time.

                                    1. 3

                                      Good point, but many jobs (including my own) involved a couple different interviews. Isn’t that the same problem? I’m spending (potentially) several (unpaid) hours for the potential of having a job. Do we pay people for that? Or do we have a shorter interview process (and perhaps not be as comfortable in our knowledge of someone)?

                                      1. 2

                                        There is a difference between a shorter interview process and shorter interviews. Shorter interviews (1 or 2 hours, rather than an all day thing) can still be fruitful in determining whether or not someone is worth hiring. If you have 2+ interviews of this type, possibly with some sort of short-term paid contract work, you should be able to get a reasonable handle on the quality of the person you’re hiring.

                                      2. 2

                                        Does that hypothetical person actually exist? How many software engineers do you know that fit that description?

                                        If all goes perfectly (they stick around for a productive >4yrs), a mid-level SWE will likely be receiving upwards of $1M of stock, benefits, and salary in return for even more value added to the company. If things go south, it can suck the time / productivity of a lot of very highly compensated employees. I think that’s worth a few hours of doing something similar to their job to figure out the difference.

                                        1. 3

                                          By “that hypothetical person” I am going to assume you mean “a person who can’t afford to give up X hours (let’s say 8, a full-day interview) for an interview, and is applying for a junior-level software engineering job.” Yes, I am aware of people that fit this description: recently graduated students applying to jobs who are currently working non-computing jobs to pay rent and basic living expenses.

                                          I would also like to add that what they stand to make if they get the job doesn’t matter if they can’t afford the financial cost of interviewing. Furthermore, the cost of interviewing is even higher than it would otherwise be if the interview demands some form of long-distance travel, even if the travel is paid for by the company doing the interviewing.

                                          I agree with you that it is important to make sure you are hiring a qualified person who will be at the company for some minimum amount of time to make their worthwhile, and that’s why I suggested in my response to cwill that companies use short-term paid contract work and/or shorter interviews in greater number as an alternative to multiple lengthy unpaid interviews.

                                2. 4

                                  The rationale I often hear w.r.t. algorithm interview questions is “well, sure, you’d never do this if you get hired, but I want to see how you think”. Is implementing an algorithm the best way to figure out if I can solve problems? Are the problems you need solved best represented by implementing a power-set method? [Real life example.]

                                  Interviews that I give are much more on the “here’s some code that does almost everything, but needs one more feature”. Then another feature, and then another feature. Often figuring out what the problem is can be the hardest part, not the actual implementation.

                                  1. 1

                                    but I want to see how you think

                                    Developers are barely good enough to think through their own issues, so I always laugh when I hear this crap. As if some programming junky could even be remotely good at accurately figuring out someone else’s thinking process.

                                    1. 1

                                      I always laugh when I hear this crap

                                      I actually told the interviewer that I didn’t think this was a good way to go, but pushed on anyway. I’m tempted to turn down their desire to move forward to an on-site interview because they’ve already proven they’re not good at it.

                                      Not to mention that my work at Google, and the 9 years of work at my current company apparently don’t count for anything.

                                  2. 4
                                    • Implementating a linked list is a good whiteboard exercise.

                                    • Doing List from Java is a lolno.

                                    I’m a super fan of CS degrees, and generally prefer them over all other candidates. I’ve been burnt more by non CS people than otherwise. It’s particularly fun when they disrespect proven academic results, then suffer for it. Following that, I’d actually prefer the non bootcamp self taught person, because they will have self initiative.

                                    In general I believe that we have to separate out software engineer from software tech: one requires a degree and maybe certification, one doesn’t. One designs scalable systems, one writes CRUD apps in Rails.

                                    1. 3

                                      A little late to the discussion, but I haven’t seen any input from any actual ‘junior’ developers, so I’ll throw some of my thoughts here. I did a programming bootcamp 2.5 years ago and have been programming professionally since then.

                                      At the time, I was the first programming bootcamp graduate that most of the companies had talked to. Even so, there was a significant bias against my background. After all, how much can someone know about producing software after just 3 months? Despite the bootcamp education, I was pretty good at programming-interview-style problems; since I enjoy puzzles, I had been doing coding challenges online during my free time for the duration of the bootcamp.

                                      Even so, it was apparent which interviews I would pass, and which I would fail within just a few minutes of starting the interview. Depending on the biases of my interviewer, I was either given extra leeway/guidance when I stumbled, or my whiteboarded code was picked apart for something very trivial. I even had a couple of what I would call “perfect” interviews, where I had no problem going through everything thrown at me and had a good rapport with the interviewer, but was not passed onto the next interview because of my experience level (assuming someone higher-up cared more about my resume than my interview result). I even had one instance where I impressed the CTO of a company by solving a fairly difficult Project Euler problem that I had never seen before in a short amount of time, and then was not given an offer after failing a technical interview with the CEO when I blanked on test syntax.

                                      Of the four job offers that I received, only two had more than trivial “solve this programming challenge” problems, and I felt like I performed quite poorly on both of those. “Implement a linked list” isn’t a bad challenge, even to someone who’s never seen one before. But someone biased against junior developers, for any reason, is going to err very hard on the side of rejecting a candidate over passing one on. Just as a single book review says more about the reviewer than the book, a single programming interview and its result says more about the interviewer than the interviewee. Interviewing junior developers the right way is less about asking the perfect question, and more about putting aside biases when evaluating a candidate.

                                      If something is unclear, or if anyone has questions I’m happy to respond.

                                      1. 2

                                        For what it’s worth, if you ever need to do this for real (ie for your job, not in an interview), you can do this pretty easily using AbstractSequentialList.

                                        1. 1

                                          In my opinion interviewing is a highly random process. It seems like we make decisions based on very little data, which we take to be more significant than it is.

                                          And it bothers me that this randomness filters out many good candidates. I say this because I’ve been rejected before by application processes that I’ve felt didn’t really test my ability to do the job - tests that just seemed myopic and capricious.

                                          Maybe uncertainty is instrinsically unpleasant, psychologically speaking, and we adapt by telling ourselves stories and creating these rituals.

                                          I’ve had the experience a couple times where I was in an interview and the interviewer just asked me a bunch of really basic questions. At the end I said, “is that it?” They said “you’d be surprised how many people don’t get these right.”

                                          So my goal these days, when I have to interview someone, is just to perform a “sanity” check.

                                          For a senior JavaScript position, I’ve asked “what is CSS margin?” “If you wanted to create a Person object with a first and last name, how would you do it?”

                                          I’ve indeed been surprised by how many people don’t have good answers for these kinds of questions.

                                          On the other hand, other folks will chuckle, then describe all the ins and outs of the fundamental I asked about. Which is always kind of a nice thing to have happen in an interview.

                                          1. 1

                                            Is the author going to be as happy with this interview process when people who are hired based on being “open to learning, good at communicating, and people we’d like to work with every day” are fired after a few months because they’re not delivering?

                                            1. 11

                                              No one I’ve ever hired based on that criteria has been let go. They usually last longer than I do.