Algorithms Interviews: Theory vs. Practice

For example, I was asked this question once: Given N points and 3 squares of side length L, what's the minimum L that allows you to cover all N points with the 3 squares?

I think this question is fairly unreasonable as an interview question, if you weren't given hints. In the context of an interview, however, I think it could be reasonable.

I say that as someone who has gotten a job offer from every interview I've been interviewed, and done maybe 100 on the interviewer side of the table. I put far more weight onto pair programming and anything that resembles a work sample than anything else. And even then you don't really find out what people are like until like the tenth pull request or so.

I remember a blog post which was ranting about the current culture at trendy big tech companies (has since been deleted [0], probably the author still wanted a career at such a company) in which a quote resonated with me a lot: 'we're not problem solvers, we're problem endurers'.

Someone solving hundreds of leetcode problems to prepare for an interview just signaled that they are willing do do basically any tedious piece of work you throw at them.

EDIT: [0] Found it: https://web.archive.org/web/20160308032127/https://medium.co...

As a manager, I want people who are hardworking, sure, but how I can I know that they're working on their assigned tasks instead of studying up for interviews and trying to jump ship? Also, I want to work with people who are creative, empathetic and collaborative (the latter is a hugely important trait perhaps even more important than raw algorithmic interviewing ability in a highly teamwork driven discipline like Software Engineering) - none of which these kinds of interviews help with. Or maybe I want a mixture of people with different strengths and weaknesses, like a team with an algorithms expert paired with a creative problem solver that can figure out new approaches to business problems. Applying a uniform standard involving mostly rote memorization and practice of the same set of interview puzzles to everyone is in my view antithetical to building a strong engineering organization. But you're right that it works "well enough" and no one has found alternative solutions that work better so it is unlikely to change in the near future.

There is no objective criteria for the next “level”, despite the fact that corporations pretend otherwise. Level is more related to years of experience than actual skill from what I’ve observed. Working extremely hard for a promo and then being compensated far less than external hires who can barely code but managed to pass the leetcode interviews is a real morale killer. And that’s if you get lucky and get promoted instead of passed up for promo, since promos tend to be given for exaggerating impact “metrics” instead of actual total impact which is unmeasurable.

From a director-level perspective it probably makes sense to have one or two of your best people on each team, rather than some wholly excellent teams and some wholly mediocre teams.

Perhaps that is true at start ups, but in my career as a developer at very large corporations this has been almost never true. Most of my career has been waiting around wasting time or working on side projects to do my job for me. That time waste is due to any of the following:

* Unnecessary build jobs, such as a build job that takes 90 minutes. In that extreme example Java was the center-piece technology at a web travel company even though Java is not a web technology. As a front-end developer if I wanted to make a code change and test it in the browser I would need to rebuild and wait 90 minutes, because the front-end code that the Java developers don't care about is at the end of the funnel. No incentive to hurry and certainly no maximum value extraction.

* When I was working as a strategy consultant to a different giant web travel company I was there because they sucked. Let's be honest, if they were awesome they wouldn't be spending huge bags of money on an outside consultant for advise. Because the most sucky developers there were supremely insecure and their management was at war with another department they didn't really want me to do work. I really tried to justify the money they were paying to my employer for my time there, but it was really just an exhaustive exercise in keeping busy so I wouldn't be bored all day. Eventually that faded away and I just started taking long walks out of the office. No value extraction there either.

* A more common scenario I have experienced is death by process. Its like bleeding out from a thousand tiny paper cuts such that you are in agony forever, but there is no light at the end of the tunnel. I have reasoned this madness occurs because the organization lacks a qualified architect and the wrong personalities were put in charge of the technology decisions. In nearly all cases management looked around and said to themselves "who here mindlessly works themselves to death" and then that person gets put in charge and now everybody is working themselves to death but nothing is being produced. Nothing says working hard like running as fast as you can on a mouse wheel. In these cases there is need to be constantly in a hurry, but nothing gets done and everybody knows it and morale is destroyed.

* The most common failure I encounter is fear of writing original code. As a front-end developer there are only 2 APIs on the front-end: DOM and the Web APIs. Instead of writing a fast performing solution in the fewest possible instructions you typically need to write the code to conform to a very specific, though not documented, code style on top of a giant monster framework with a 1000 dependencies. Then you need to compile the code more than once just for good measure. Even though the problem could be solved slowly in 30 minutes with an additional hour for testing in multiple applications/environments it will likely take a week or more in the framework. Sometimes people claim there is a great hurry to ship product changes, but as a developer working on a framework made out of toothpicks and duct tape the hurry is clearly somebody's self-serving imagination.

* I think everybody's favorite value destroyer is death by JIRA. So, JIRA is an Agile planning and assignment tool that the corporate world has fallen in love with. When everything is a story point and nothing else matters your personal goal becomes completing story point assignments and then doing nothing else.

Perhaps the only times I have ever experienced a big corporate employer making any attempt to extract the maximum amount of value from me is when work used the old waterfall methodology, because the work was constantly coming in without regard for schedule cycles or administrative nonsense. The time I was most most valued is when I was told to go as fast as possible as the A/B test engineer for Travelocity and all restrictions were on productivity, aside from Q/A and defect resolution, were eliminated.

---

> 1. Aware of the value you produce 2. Know how to sell it

I, and most people I have worked with, have spent so much time undervalued that we clearly had time to really and continuously sell ourselves like a product on a shelf, but nobody almost wants to. The people that spend the most energy selling themselves instead of writing code or solving problems tend to use charisma as for bad self-promotion. If developers wanted to spend the majority of their energy in marketing they wouldn't waste time solving hard technology problems. It reminds me of end of year evaluations that most developers dread.

Do you think this is important even if one is already satisfied with one's compensation and mainly cares about the positive impact that they're making for end-users of the company's software?

My standard response was "The most distinguishing property of Microsoft (Google) is they have a monopoly, copy that part first".

It’s an age screen. People in their 40s don’t have time to prep for those kinds of questions. Nor do people with children who might need a work life balance.

That is you see a lot of talk about this because "the system" isn't working. Some companies are trying new things, but you have to find them among all the ones who don't spend the time to try to find a better way.

Those "I made the company X" arguments are only interesting if it was an action/idea that you were uniquely responsible for. If it's something most equally qualified people would have done in that role, it's not that interesting.

Profit sharing works by trying to make employees feel connected to the success of the business, but they don't make sense based on any kind of effort/impact/reward calculus.

I think the best course is anxiety management. But unfortunately, some people get dependent on drugs just to calm their nerves before something important. I know people that can't hold meetings or presentations without taking beta-blockers and the likes.