5 ms·

Every time the topic of algorithmic questions in interviews come up I am left wondering if these questions are really as hard as they are made out to be. I wou

Every time the topic of algorithmic questions in interviews come up I am left wondering if these questions are really as hard as they are made out to be. I would expect most programmers who are not just plumbing together existing technology to be able to implement push,pop,... for linked lists without having to study. You have to do harder things as part of regular programming. > take "determine if a linked list has a cycle in it." I do think that this question if asked without any support if they get stuck is a bad question. You would be relying on the interviewee to either be aware of that research, require that they have the spark of insight, or allow a very suboptimal program. That said, just being aware of the general solution (two pointers moving at different speeds) is enough for me to be confident I could make a solution.

shados 7y ago
> I am left wondering if these questions are really as hard as they are made out to be It's not really about how hard they are, and more about: "Ive never once in my career had to use this on the job, why is it asked in an interview, thats stupid!". That's usually the answer you'll get. But I think that answer contains a lot more info than what we can gather from it at first glance. First, good places will give you hints about what the interview might contain long before you show up. If it's for one of the well known big techs, the questions are all over the internet. They know this. The question essentially amounts to: "Can you make sure you know something about computer science if we ask you to know it". If your answer is "No, that's not worth my time, I'm better than this!", well, I can see why someone wouldn't hire you. The second part, is that it is a self fulfilling prophecy. 20 years ago, a typical team was mostly CS majors, with the occasional odd one out who didn't (I was one of those odd ones out). That means if you didn't know it, it didn't really matter. You could just turn around and bounce it off one of your colleagues. If you made a mistake, they'd catch it. Today however, especially in fields like frontend development, its extremely likely ZERO person in the team has a CS background, or the 1-2 people who did don't remember anything from their college years. That means some problems quickly fall in the category of "This isn't worth trying, let's use a 3rd party solution or wait until the one expert in the company does it for us". Thus, self fulfilling prophecy: you don't need to know these things because the industry punted on the problems you'd need these things to solve, or deferred them to other departments. Web apps, for example, are often very animation light, or low on more advanced graphics, because no one knows the math to make these things happen anymore aside from using a library to make a pretty chart. Since your competitors are in the same boat, there's no pressure to change that. And then those folks feel its dumb to ask these questions in interviews (They don't need it!), and the cycle keeps going. "Why would I need these if Im building forms in javascript all day!". Well, maybe if more people in the team knew how to do more than build forms, we could try and build something fancier than forms.
- ajross 7y ago
  I think there's some of that, but... no, part of it is because straight logic problems are... hard. And lots of candidates, even solid candidates who have held jobs in software engineering, can't write code with simple-yet-non-trivial logic requirements reliably. "Write a linked list" won't tell you someone is a genius. But it will weed out a lot of people who can do "development" but can't hack. And if you have a job that needs hackers (not all do!), these questions make for cheap filters that save everyone time.
- deleted 7y ago
  [deleted]
- pytester 7y ago
  >Thus, self fulfilling prophecy: you don't need to know these things because the industry punted on the problems you'd need these things to solve, or deferred them to other departments. Web apps, for example, are often very animation light, or low on more advanced graphics, because no one knows the math to make these things happen anymore aside from using a library to make a pretty chart. Since your competitors are in the same boat, there's no pressure to change that. And then those folks feel its dumb to ask these questions in interviews (They don't need it!), and the cycle keeps going. I've heard a lot of post-hoc rationalizations for why the "google style academic interviewing fetish" is more rational than "ask interviewee to perform tasks or answer questions relevant to their job" but using it a justification for continuing the tradition of wheel reinvention in the javascript ecosystem has to be the best. >"Why would I need these if Im building forms in javascript all day!". Well, maybe if more people in the team knew how to do more than build forms, we could try and build something fancier than forms. Sadly for the aspiring academic fetishist, building non-fancy forms all day is what a lot of businesses want.
- im3w1l 7y ago
  > complex animations & advanced graphics No please don't. I'm very happy with everyone just building normal boring predictable easy-to-use forms.
- scarface74 7y ago
  This isn't worth trying, let's use a 3rd party solution You act as if this is bad thing. The last thing I want is another bespoke logging solution or ORM. You can’t imagine the times I gladly ripped out my own bespoke solution for a third party one after finding one was available. No sane company hires experienced developers to “develop”. They hire developers to have a breadth of industry knowledge to know when to build and when to outsource the “undifferentiated heavy lifting”. During the last few years, both companies I’ve worked for both in an architect level positions have never blinked at solutions that cost money over costing developer time in both development and maintenance. Web apps, for example, are often very animation light, or low on more advanced graphics.... Well, maybe if more people in the team knew how to do more than build forms, we could try and build something fancier than forms. Again you act like this is a bad thing. I came into a company where the dev leads were younger and relatively fresh CS grads and even the manager of the department was relatively young. He was the founder of the company before it got acquired. They had so many ideas about the “right” way to do things and spent so much time arguing about how many angels can dance on the head of a pin they couldn’t ship software for crap. You see the same thing at Google. After two decades, billions of dollars, untold cancelled projects and with all the smart people they have, almost all of their revenue still comes from advertising. I saw so many head scratching overengineered custom developed systems that could have been done a lot simpler if they had had any real world experience. On the opposite end, I was hired two years ago with a mandate partially to migrate all of the bespoke, complicated systems and use managed services/use third party packages where ever possible.
erikpukinskis 7y ago
In my opinion, it doesn’t matter what they ask at all. Give me a question about Kubernetes deploys for a shader programming job if you want. I’m a programmer, my job is to solve coding problems both inside and outside my sphere of knowledge. If you “get stuck”, what are you going to do when you bump up against your limitations at work? Part of the job is getting yourself unstuck. If you can show you have ways of making progress when you are out of your depth then you aced the interview, even if you were nowhere near the correct solution.
- umanwizard 7y ago
  +1. I 100% agree and this is a great way of putting it. Being able to think through how you would approach something is infinitely better than having memorized some details (although job-specific details are important too).
  - kiliancs 7y ago
    Programming problems are not solved in about 30 minutes, which is a very typical amount of time in my experience.
- thethirdone 7y ago
  I agree that "getting yourself unstuck" is part of the job, but interviews also try to get an idea of how well you will do on average. So a previous graphics driver implementer may be a great fit for the shader programming job, but be beat in Kubernetes deployment by someone who has done multiplayer web based 3dgames.
- pcwalton 7y ago
  > If you “get stuck”, what are you going to do when you bump up against your limitations at work? If I got stuck on finding whether a linked list had a cycle in it, I would Google for "how to determine whether a linked list has a cycle in it". Ironically, that's the one thing I'm not allowed to do in a coding interview. In fact, trying to invent something from first principles as you're theoretically supposed to do in an interview would be a waste of my employer's time.
Animats 7y ago
"determine if a linked list has a cycle in it." That's only hard if you can't put a depth count field in each list node, and can't use much memory outside the list. If you can do either of those things, it's easy. Many of the classic list algorithms assume that memory is expensive but random access is free. Today, memory is cheap but random access to a lot of it is expensive.
- Kiro 7y ago
  Easy is relative. I've don't even know what a linked list is, much less able the implement one and I've been programming for 10 years.
  - GGfpc 7y ago
    You've never used a linked list in 10 years?
  - mruts 7y ago
    That says a lot more about you than the interview question.

shados 7y ago

> I am left wondering if these questions are really as hard as they are made out to be It's not really about how hard they are, and more about: "Ive never once in my career had to use this on the job, why is it asked in an interview, thats stupid!". That's usually the answer you'll get. But I think that answer contains a lot more info than what we can gather from it at first glance. First, good places will give you hints about what the interview might contain long before you show up. If it's for one of the well known big techs, the questions are all over the internet. They know this. The question essentially amounts to: "Can you make sure you know something about computer science if we ask you to know it". If your answer is "No, that's not worth my time, I'm better than this!", well, I can see why someone wouldn't hire you. The second part, is that it is a self fulfilling prophecy. 20 years ago, a typical team was mostly CS majors, with the occasional odd one out who didn't (I was one of those odd ones out). That means if you didn't know it, it didn't really matter. You could just turn around and bounce it off one of your colleagues. If you made a mistake, they'd catch it. Today however, especially in fields like frontend development, its extremely likely ZERO person in the team has a CS background, or the 1-2 people who did don't remember anything from their college years. That means some problems quickly fall in the category of "This isn't worth trying, let's use a 3rd party solution or wait until the one expert in the company does it for us". Thus, self fulfilling prophecy: you don't need to know these things because the industry punted on the problems you'd need these things to solve, or deferred them to other departments. Web apps, for example, are often very animation light, or low on more advanced graphics, because no one knows the math to make these things happen anymore aside from using a library to make a pretty chart. Since your competitors are in the same boat, there's no pressure to change that. And then those folks feel its dumb to ask these questions in interviews (They don't need it!), and the cycle keeps going. "Why would I need these if Im building forms in javascript all day!". Well, maybe if more people in the team knew how to do more than build forms, we could try and build something fancier than forms.

ajross 7y ago
I think there's some of that, but... no, part of it is because straight logic problems are... hard. And lots of candidates, even solid candidates who have held jobs in software engineering, can't write code with simple-yet-non-trivial logic requirements reliably. "Write a linked list" won't tell you someone is a genius. But it will weed out a lot of people who can do "development" but can't hack. And if you have a job that needs hackers (not all do!), these questions make for cheap filters that save everyone time.
deleted 7y ago
[deleted]
pytester 7y ago
>Thus, self fulfilling prophecy: you don't need to know these things because the industry punted on the problems you'd need these things to solve, or deferred them to other departments. Web apps, for example, are often very animation light, or low on more advanced graphics, because no one knows the math to make these things happen anymore aside from using a library to make a pretty chart. Since your competitors are in the same boat, there's no pressure to change that. And then those folks feel its dumb to ask these questions in interviews (They don't need it!), and the cycle keeps going. I've heard a lot of post-hoc rationalizations for why the "google style academic interviewing fetish" is more rational than "ask interviewee to perform tasks or answer questions relevant to their job" but using it a justification for continuing the tradition of wheel reinvention in the javascript ecosystem has to be the best. >"Why would I need these if Im building forms in javascript all day!". Well, maybe if more people in the team knew how to do more than build forms, we could try and build something fancier than forms. Sadly for the aspiring academic fetishist, building non-fancy forms all day is what a lot of businesses want.
im3w1l 7y ago
> complex animations & advanced graphics No please don't. I'm very happy with everyone just building normal boring predictable easy-to-use forms.
scarface74 7y ago
This isn't worth trying, let's use a 3rd party solution You act as if this is bad thing. The last thing I want is another bespoke logging solution or ORM. You can’t imagine the times I gladly ripped out my own bespoke solution for a third party one after finding one was available. No sane company hires experienced developers to “develop”. They hire developers to have a breadth of industry knowledge to know when to build and when to outsource the “undifferentiated heavy lifting”. During the last few years, both companies I’ve worked for both in an architect level positions have never blinked at solutions that cost money over costing developer time in both development and maintenance. Web apps, for example, are often very animation light, or low on more advanced graphics.... Well, maybe if more people in the team knew how to do more than build forms, we could try and build something fancier than forms. Again you act like this is a bad thing. I came into a company where the dev leads were younger and relatively fresh CS grads and even the manager of the department was relatively young. He was the founder of the company before it got acquired. They had so many ideas about the “right” way to do things and spent so much time arguing about how many angels can dance on the head of a pin they couldn’t ship software for crap. You see the same thing at Google. After two decades, billions of dollars, untold cancelled projects and with all the smart people they have, almost all of their revenue still comes from advertising. I saw so many head scratching overengineered custom developed systems that could have been done a lot simpler if they had had any real world experience. On the opposite end, I was hired two years ago with a mandate partially to migrate all of the bespoke, complicated systems and use managed services/use third party packages where ever possible.

erikpukinskis 7y ago

In my opinion, it doesn’t matter what they ask at all. Give me a question about Kubernetes deploys for a shader programming job if you want. I’m a programmer, my job is to solve coding problems both inside and outside my sphere of knowledge. If you “get stuck”, what are you going to do when you bump up against your limitations at work? Part of the job is getting yourself unstuck. If you can show you have ways of making progress when you are out of your depth then you aced the interview, even if you were nowhere near the correct solution.

umanwizard 7y ago
+1. I 100% agree and this is a great way of putting it. Being able to think through how you would approach something is infinitely better than having memorized some details (although job-specific details are important too).
- kiliancs 7y ago
  Programming problems are not solved in about 30 minutes, which is a very typical amount of time in my experience.
thethirdone 7y ago
I agree that "getting yourself unstuck" is part of the job, but interviews also try to get an idea of how well you will do on average. So a previous graphics driver implementer may be a great fit for the shader programming job, but be beat in Kubernetes deployment by someone who has done multiplayer web based 3dgames.
pcwalton 7y ago
> If you “get stuck”, what are you going to do when you bump up against your limitations at work? If I got stuck on finding whether a linked list had a cycle in it, I would Google for "how to determine whether a linked list has a cycle in it". Ironically, that's the one thing I'm not allowed to do in a coding interview. In fact, trying to invent something from first principles as you're theoretically supposed to do in an interview would be a waste of my employer's time.

Animats 7y ago

"determine if a linked list has a cycle in it." That's only hard if you can't put a depth count field in each list node, and can't use much memory outside the list. If you can do either of those things, it's easy. Many of the classic list algorithms assume that memory is expensive but random access is free. Today, memory is cheap but random access to a lot of it is expensive.

Kiro 7y ago
Easy is relative. I've don't even know what a linked list is, much less able the implement one and I've been programming for 10 years.
- GGfpc 7y ago
  You've never used a linked list in 10 years?
- mruts 7y ago
  That says a lot more about you than the interview question.