3 ms·

The companies who ask these questions do so because their engineers deal with these kinds of scaling challenges every day I'm skeptical of that statement. Som

The companies who ask these questions do so because their engineers deal with these kinds of scaling challenges every day I'm skeptical of that statement. Some of the engineers at, say, Google, deal with code complexity and scaling every day. Most probably don't. Certainly, most at the non-Googlish companies hardly ever deal with this. Yet the majority of interviews I've gone to over 12+ years have involved significant questioning about algorithmic complexity. I agree with your statement about awareness of Big-O, but often companies seem to be looking for over-stressed obsession, even for jobs which don't utilize it.

rguzman 15y ago
People ask algorithms questions not because they are relevant, but because they are a good proxy for your abilities. Well, at least they are perceived to be a good proxy ...
- georgieporgie 15y ago
  Right, that's my point. It become sort of a cargo cult of candidate selection by people who don't actually understand what they want or need.
  - lars8128 15y ago
    I suspect a "cargo cult" for hiring is not what rguzman meant. Rather, algorithm skills are one of the best signals you can extract from a short interview. I've always found them to be much better at predicting a candidate's ability to do the job than anything else I could ask in 45 minutes. That may mean I'm a poor interviewer, but until I can figure out better questions to ask, I'm happy to use this signal since in my experience it works well.
    - georgieporgie 15y ago
      That may mean I'm a poor interviewer Not at all. It means that humans are complex and ranking them is extremely difficult. My issue is with the fact that I've met too many very smart people who can prattle on about Big-O and optimal architectures for hours, but when it comes time to get dirty and finish a job, they lose interest, produce unmaintainable, over-engineered nightmares, and/or turn out not to actually understand the platform well enough to execute a clean solution.
angelbob 15y ago
I've worked at a long series of companies that deal with these at least every week or so. Maybe not daily. But I'm writing code where it matters most days. Maybe I'm unusually hardcore? I'm definitely not all about the algorithms, but I work on a lot of systems programming. The other thing is that often you don't realize that what you're doing requires thinking of this until somebody else has to go fix what you wrote. The fix will even look very simple. The insight going into the fix isn't as simple, though.
- georgieporgie 15y ago
  I've worked at a long series of companies that deal with these at least every week or so And I've worked at a long series of companies that don't. That's the thing: different strokes for different folks, as it were. Maybe I'm unusually hardcore? I think it's less about degree-of-core-ness and more about platform and domain knowledge. Personally, if I were hiring for what I consider to be a fairly typical company, I would be looking mostly for ability to consistently get functional, bug-free code running. I would likely seek stronger algorithmic knowledge in some small ratio of employees. I guess I feel strongly about this because I think it's fundamentally disrespectful to all coders, and ignores the tremendous variety of tasks and skills out there. A self-taught hacker who can get a great product going in a short time may be just as important and valuable to a company as the algorithm-strong coder who catches scaling problems before they come up. When it comes down to it, the goal is to create product and value, and that happens in many, many different ways. The fix will even look very simple. The insight going into the fix isn't as simple, though. That's true of the majority of bugs I've written or come across, whether its related to performance, crashing, or unpredictable behavior. In fact, looking at fixes that coworkers make to your own code can be a tremendously enlightening (and humbling) experience.
  - jimbokun 15y ago
    My preference would be that any developer for any job should be able to write functional, and (fairly) bug-free code. Then I would hope they have a good sense of usability, if they are writing user facing code. And I would hope they have a good sense of algorithms and other aspects of scalability, if they are writing server side or systems code.
haberman 15y ago
> I'm skeptical of that statement. Some of the engineers at, say, Google, deal with code complexity and scaling every day. Most probably don't. I am an engineer at Google, and basically all of the engineers I work with have to scale their software in least one dimension such that big-O complexity is a significant (and daily) concern. What I mean by "daily concern" is that the check-ins are happening on a daily basis would be noticeably inefficient if they used an O(n^2) algorithm instead of an O(n) algorithm, for example. > Certainly, most at the non-Googlish companies hardly ever deal with this. My main experience is Google and Amazon, so I couldn't say. I was meaning to talk mainly about Google/Amazon/Facebook/Twitter-like companies. I'm betting Palantir is also one such place.
- rluhar 15y ago
  And financial companies, banks, hedge funds etc. Even the most "boring" financial companies (actuaries, insurance companies) process huge amounts of data where performance becomes critical. We have a data base that gathers about a 5GB of market data a day and we have to run algorithms to analyse the data and analyse the behaviour of our system. Efficient algorithms become very important.

rguzman 15y ago

People ask algorithms questions not because they are relevant, but because they are a good proxy for your abilities. Well, at least they are perceived to be a good proxy ...

georgieporgie 15y ago
Right, that's my point. It become sort of a cargo cult of candidate selection by people who don't actually understand what they want or need.
- lars8128 15y ago
  I suspect a "cargo cult" for hiring is not what rguzman meant. Rather, algorithm skills are one of the best signals you can extract from a short interview. I've always found them to be much better at predicting a candidate's ability to do the job than anything else I could ask in 45 minutes. That may mean I'm a poor interviewer, but until I can figure out better questions to ask, I'm happy to use this signal since in my experience it works well.
  - georgieporgie 15y ago
    That may mean I'm a poor interviewer Not at all. It means that humans are complex and ranking them is extremely difficult. My issue is with the fact that I've met too many very smart people who can prattle on about Big-O and optimal architectures for hours, but when it comes time to get dirty and finish a job, they lose interest, produce unmaintainable, over-engineered nightmares, and/or turn out not to actually understand the platform well enough to execute a clean solution.

angelbob 15y ago

I've worked at a long series of companies that deal with these at least every week or so. Maybe not daily. But I'm writing code where it matters most days. Maybe I'm unusually hardcore? I'm definitely not all about the algorithms, but I work on a lot of systems programming. The other thing is that often you don't realize that what you're doing requires thinking of this until somebody else has to go fix what you wrote. The fix will even look very simple. The insight going into the fix isn't as simple, though.

georgieporgie 15y ago
I've worked at a long series of companies that deal with these at least every week or so And I've worked at a long series of companies that don't. That's the thing: different strokes for different folks, as it were. Maybe I'm unusually hardcore? I think it's less about degree-of-core-ness and more about platform and domain knowledge. Personally, if I were hiring for what I consider to be a fairly typical company, I would be looking mostly for ability to consistently get functional, bug-free code running. I would likely seek stronger algorithmic knowledge in some small ratio of employees. I guess I feel strongly about this because I think it's fundamentally disrespectful to all coders, and ignores the tremendous variety of tasks and skills out there. A self-taught hacker who can get a great product going in a short time may be just as important and valuable to a company as the algorithm-strong coder who catches scaling problems before they come up. When it comes down to it, the goal is to create product and value, and that happens in many, many different ways. The fix will even look very simple. The insight going into the fix isn't as simple, though. That's true of the majority of bugs I've written or come across, whether its related to performance, crashing, or unpredictable behavior. In fact, looking at fixes that coworkers make to your own code can be a tremendously enlightening (and humbling) experience.
- jimbokun 15y ago
  My preference would be that any developer for any job should be able to write functional, and (fairly) bug-free code. Then I would hope they have a good sense of usability, if they are writing user facing code. And I would hope they have a good sense of algorithms and other aspects of scalability, if they are writing server side or systems code.

haberman 15y ago

> I'm skeptical of that statement. Some of the engineers at, say, Google, deal with code complexity and scaling every day. Most probably don't. I am an engineer at Google, and basically all of the engineers I work with have to scale their software in least one dimension such that big-O complexity is a significant (and daily) concern. What I mean by "daily concern" is that the check-ins are happening on a daily basis would be noticeably inefficient if they used an O(n^2) algorithm instead of an O(n) algorithm, for example. > Certainly, most at the non-Googlish companies hardly ever deal with this. My main experience is Google and Amazon, so I couldn't say. I was meaning to talk mainly about Google/Amazon/Facebook/Twitter-like companies. I'm betting Palantir is also one such place.

rluhar 15y ago
And financial companies, banks, hedge funds etc. Even the most "boring" financial companies (actuaries, insurance companies) process huge amounts of data where performance becomes critical. We have a data base that gathers about a 5GB of market data a day and we have to run algorithms to analyse the data and analyse the behaviour of our system. Efficient algorithms become very important.