3 ms·

> insist so much on grad level things such as complexities, basic algorithms etc Because they matter. Basic level complexities, algorithms, data structures, ar

by mabbo 6y ago

> insist so much on grad level things such as complexities, basic algorithms etc Because they matter. Basic level complexities, algorithms, data structures, are all important for being a developer. That's why it's part of the undergraduate curriculum! You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. > open 'the Linux programmer interface' at a random page and shoot Yeah, the heck with that interviewer. I mean, if you're interviewing for a low level systems dev job then I can see making sure the dev has some basic familiarity with important functions, but it's hard to see that making sense on a general developer interview. I hope that wasn't my company.

mrbgty 6y ago
> You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. That one time a year when it's critical, I would want someone who is likely to engage on the rest of the team to come up with a solid solution together and spend at least a day thinking about it. This isn't how interviews work so if you think you're selecting for that one time a year when its critical at the expense of the rest of the year, I don't think you're getting what you think you are. For quick workarounds to deal with a critical error while allowing time to solve it properly, I think an experienced person may have an edge.
- mabbo 6y ago
  I see your point, but interviews are tame compared to the real world. It's not about "Can the candidate solve this mission critical problem we'll spend a week on, in an hour?". It's more like "Can the candidate recognize a graph problem?". If they can't even tell that this is a graph problem, how are they going to know that today is the day we need to ask someone for help, and think about this very hard? An example: Many times I've asked something like Word Ladder[0] to a candidate, and they can't tell that this is a shortest path problem, nor use the common tools to solve such things. Even with hinting and helping as much as I can, sometimes they just don't have those tools in their toolbox. And my job is to find out whether they do or not. [0]https://leetcode.com/problems/word-ladder/ https://leetcode.com/problems/word-ladder/ and no, I don't use this exact question.
  - mrbgty 6y ago
    I honestly doubt that a team of diverse engineers (young and old) would have a hard time figuring out whether it is a graph problem in a reasonable amount of time with the internet at their disposal under normal working conditions. The interview isn't set up that way and introduces non-natural pressures that can easily alter the way a good engineer responds to such a question. I would think younger candidates have likely been more recently immersed in problems such as graph problems and tend to be more aware that they need to spend time training on leetcode or hackerrank in order to pass an interview but I don't know. You could always still get lucky or be making decisions for reasons you aren't aware of.
underdeserver 6y ago
Exactly. "I'm a really good developer, shipped software, why do I need to know how to invert a binary tree on a whiteboard?" Well, first of all, it's all out there, and you have all the time in the world to prepare. Know how to invert a binary tree. Aside from that, the things you actually need to know for these interviews (from my experience interviewing at several FAANGs) are basic dynamic programming, BFS, DFS, and basic tree algorithms. Nobody's going to ask you to implement Edmonds-Karp from memory. This is something a smart non-academic who learned ReactJS should be able to easily learn. Theory matters. If you care about theory, and applying theory to problems you face, you care about making your abstractions correct, which leads to code that has fewer edge cases and is more maintainable.
- driverdan 6y ago
  > Well, first of all, it's all out there, and you have all the time in the world to prepare. Know how to invert a binary tree. I downvoted you because this is terrible reasoning. If you don't use knowledge on a regular basis you have no reason to remember it, and won't. Interviews shouldn't require studying. They should test the knowledge you're expected to use on the job. I don't spend hours every week studying comp sci in the off chance I might need it at work. If I need to do something I don't remember or never learned I look it up. Theory matters if you're deeply involved in complex comp sci problems. If you're building simple web and mobile apps like 90% of programmers theory is irrelevant. Again, ask interview questions directly relevant to the position.
  - underdeserver 6y ago
    > I downvoted you because this is terrible reasoning. Well, that's just like, your opinion, man. > If you don't use knowledge on a regular basis you have no reason to remember it, and won't. I don't expect you to remember it. I expect you to study and be ready for it in the interview. > Interviews shouldn't require studying. They should test the knowledge you're expected to use on the job. A significant part of a software engineer's job is studying. Take your job in the last 3 years. Could you have 100% predicted, 3 years ago, what knowledge you'd need? I sure couldn't. > I don't spend hours every week studying comp sci in the off chance I might need it at work. You don't need to do it every week, only before you interview. > If I need to do something I don't remember or never learned I look it up. Looking it up is definitely important but I'm talking about the basics. If you don't understand the basics and the way of thinking about algorithmic tradeoffs, you won't learn it in 10 seconds from a Stack Overflow answer. > Theory matters if you're deeply involved in complex comp sci problems. If you're building simple web and mobile apps like 90% of programmers theory is irrelevant. I disagree that 90% of programmers do that, or we disagree on what "simple" means. I can guarantee you less than 10% of programmers in FAANGs just build no-logic CRUD mobile/web apps. > Again, ask interview questions directly relevant to the position. Theory is directly relevant to the position. I use it every day.
driverdan 6y ago
> You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. I downvoted you because it's unreasonable to expect people to memorize something they use once a year. Learn it, understand it, then look it up again when you need it. Interviews should reflect the experience and knowledge you expect a candidate to use on a regular basis. Asking comp sci questions they don't need to know to do their job biases your hiring process to new grads rather than experienced industry veterans.
nonines 6y ago
That was an interview for SRE role. One of the big ones. SRE btw has come to mean "you must know everything...in order to do on-calls" but that deserves a whole post in itself. --- I'm OK with complexities, etc. I get why they're so popular in interviews. I don't agree but I get it. They were an annoyance to review and keep in my RAM since I don't really use them in day-to-day work but I swallowed that pill.

by mabbo 6y ago

mrbgty 6y ago

> You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. That one time a year when it's critical, I would want someone who is likely to engage on the rest of the team to come up with a solid solution together and spend at least a day thinking about it. This isn't how interviews work so if you think you're selecting for that one time a year when its critical at the expense of the rest of the year, I don't think you're getting what you think you are. For quick workarounds to deal with a critical error while allowing time to solve it properly, I think an experienced person may have an edge.

mabbo 6y ago
I see your point, but interviews are tame compared to the real world. It's not about "Can the candidate solve this mission critical problem we'll spend a week on, in an hour?". It's more like "Can the candidate recognize a graph problem?". If they can't even tell that this is a graph problem, how are they going to know that today is the day we need to ask someone for help, and think about this very hard? An example: Many times I've asked something like Word Ladder[0] to a candidate, and they can't tell that this is a shortest path problem, nor use the common tools to solve such things. Even with hinting and helping as much as I can, sometimes they just don't have those tools in their toolbox. And my job is to find out whether they do or not. [0]https://leetcode.com/problems/word-ladder/ https://leetcode.com/problems/word-ladder/ and no, I don't use this exact question.
- mrbgty 6y ago
  I honestly doubt that a team of diverse engineers (young and old) would have a hard time figuring out whether it is a graph problem in a reasonable amount of time with the internet at their disposal under normal working conditions. The interview isn't set up that way and introduces non-natural pressures that can easily alter the way a good engineer responds to such a question. I would think younger candidates have likely been more recently immersed in problems such as graph problems and tend to be more aware that they need to spend time training on leetcode or hackerrank in order to pass an interview but I don't know. You could always still get lucky or be making decisions for reasons you aren't aware of.

underdeserver 6y ago

Exactly. "I'm a really good developer, shipped software, why do I need to know how to invert a binary tree on a whiteboard?" Well, first of all, it's all out there, and you have all the time in the world to prepare. Know how to invert a binary tree. Aside from that, the things you actually need to know for these interviews (from my experience interviewing at several FAANGs) are basic dynamic programming, BFS, DFS, and basic tree algorithms. Nobody's going to ask you to implement Edmonds-Karp from memory. This is something a smart non-academic who learned ReactJS should be able to easily learn. Theory matters. If you care about theory, and applying theory to problems you face, you care about making your abstractions correct, which leads to code that has fewer edge cases and is more maintainable.

driverdan 6y ago
> Well, first of all, it's all out there, and you have all the time in the world to prepare. Know how to invert a binary tree. I downvoted you because this is terrible reasoning. If you don't use knowledge on a regular basis you have no reason to remember it, and won't. Interviews shouldn't require studying. They should test the knowledge you're expected to use on the job. I don't spend hours every week studying comp sci in the off chance I might need it at work. If I need to do something I don't remember or never learned I look it up. Theory matters if you're deeply involved in complex comp sci problems. If you're building simple web and mobile apps like 90% of programmers theory is irrelevant. Again, ask interview questions directly relevant to the position.
- underdeserver 6y ago
  > I downvoted you because this is terrible reasoning. Well, that's just like, your opinion, man. > If you don't use knowledge on a regular basis you have no reason to remember it, and won't. I don't expect you to remember it. I expect you to study and be ready for it in the interview. > Interviews shouldn't require studying. They should test the knowledge you're expected to use on the job. A significant part of a software engineer's job is studying. Take your job in the last 3 years. Could you have 100% predicted, 3 years ago, what knowledge you'd need? I sure couldn't. > I don't spend hours every week studying comp sci in the off chance I might need it at work. You don't need to do it every week, only before you interview. > If I need to do something I don't remember or never learned I look it up. Looking it up is definitely important but I'm talking about the basics. If you don't understand the basics and the way of thinking about algorithmic tradeoffs, you won't learn it in 10 seconds from a Stack Overflow answer. > Theory matters if you're deeply involved in complex comp sci problems. If you're building simple web and mobile apps like 90% of programmers theory is irrelevant. I disagree that 90% of programmers do that, or we disagree on what "simple" means. I can guarantee you less than 10% of programmers in FAANGs just build no-logic CRUD mobile/web apps. > Again, ask interview questions directly relevant to the position. Theory is directly relevant to the position. I use it every day.

driverdan 6y ago

> You don't need to think about graphs or runtimes every day- but that one time each year or so that you do need to know it, it's critical that you do. I downvoted you because it's unreasonable to expect people to memorize something they use once a year. Learn it, understand it, then look it up again when you need it. Interviews should reflect the experience and knowledge you expect a candidate to use on a regular basis. Asking comp sci questions they don't need to know to do their job biases your hiring process to new grads rather than experienced industry veterans.

nonines 6y ago

That was an interview for SRE role. One of the big ones. SRE btw has come to mean "you must know everything...in order to do on-calls" but that deserves a whole post in itself. --- I'm OK with complexities, etc. I get why they're so popular in interviews. I don't agree but I get it. They were an annoyance to review and keep in my RAM since I don't really use them in day-to-day work but I swallowed that pill.