9 ms·

> I'm a kick-ass get-things-done full-stack web engineer. And modest, too. If an engineer gave me your answer ("I never learned the principle because I never h

by hashkb 10y ago

> I'm a kick-ass get-things-done full-stack web engineer. And modest, too. If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team.

cauterized 10y ago
But I did learn the principle, back in school. I've just never needed to use it.
bigtimeidiot 10y ago
>If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?
- hashkb 10y ago
  No, it's the attitude. Saying "I don't know depth first search" is fine, saying "I'll never need this and by asking it you've revealed what a terrible company you are" is sour grapes.
  - logfromblammo 10y ago
    Not revealed as a terrible company, perhaps, but as a terrible interviewer. If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries. That is, before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index, which is likely what I would be doing at most companies. Part of development is figuring out not just the answers to the questions, but also figuring out "Of all the questions I could have been asked, why was I asked that question?" A disappointingly large fraction of the time, the answer to "why did you ask that question?" is "we noticed a correlation, confused it for causation, and built an entire strategy around it".
    - joshuamorton 10y ago
      "Perhaps you won't, but since we don't know yet exactly what you'll be working on, we might know broadly what PA or even project, but we can't know what problems you will encounter or what direction it will take to debug any problems that arise, we want someone with a broad base of skills who can at the very least recognize performance problems and solve them in a simple case. We expect that if you can solve this relatively simple problem in an environment with no resources, that with the aide of documentation, profiling tools, and teammates to lean on, you'll be able to address much more complex issues that arise. On the other hand, if it takes you documentation and teammates to solve this simple case, who knows what kinds of tools it will take you to solve real world problems that arise." "Correlation does not imply causation" doesn't imply that correlation never implies causation.
      - skj 10y ago
        I think you mean to say that correlation and causation correlate.
    - quacker 10y ago
      > need to roll their own new solutions in the face of so many well-established libraries I'm not defending interview quiz-time, but it isn't (or shouldn't be) about rolling your own solution. It's about understanding concepts. Understanding the basics of time/space complexity are pretty fundamental when designing systems. Developers frequently encounter hashing and (probably less-often) trees, so I don't see an issue with asking something like "Why/how/when is a hash-based lookup faster <in some situation> than a tree-based lookup?" (as one question during an interview). If a person can give a good answer to this, they'll pretty easily be able to understand the performance tradeoffs of hash vs btree indexes when using mysql (and this same tradeoff in a variety of other situations).
      - logfromblammo 10y ago
        If you're measuring my design ability in the interview, you had better give me an opportunity to use that ability after being hired. Too many times have I been asked questions that shaped my expectations of the job, only to be disappointed later on. The worst offender in this respect put me through a technical screen that could only reasonably be passed by someone with a bachelor's degree in CompSci or equivalent work experience, only to later tell me that the code I write "should be understandable by a kid fresh out of high school" (actual quote). I applied to 12 different job postings that night. The interview led me to believe that I was being hired for my expertise, and the job expectation was actually to be a warm, brainless body in a formerly empty seat. That's why I don't like questions that act as proxies for some other metric. The questions you ask me are telling me about you as much as my answers tell you about me. When you cargo-cult interview procedures from another company, you are actually misrepresenting the nature of your own company as being like the company you stole your interviews from.
  - kafkaesq 10y ago
    Saying "I don't know depth first search" is fine, No, it most definitely is not "fine". Even momentarily hesitating on question like "Would you use BFS or DFS in this case?" is more than enough to merit a quick transition to the "Do you have any questions for me?" phase, in many a modern, "As hire As, Bs hire Cs, you know" interview session, these days.
- jorgemf 10y ago
  As an engineer you should be able to see the global picture and know other things. Because you wont be able to use something to solve your problem if you don't know it in advance. I mean, you don't need to know the details, but you need to know how things works. For example, you might not need an AVL tree in your daily job, but if one day you need it to use it, you wont be able to notice if you don't know what is an AVL tree and what is its advantages over other trees. Another example, you don't need to know http1 and http2 differences for your daily work. But if you know them you will change how you do web pages and you will see a leap in terms of performance and scability. And that knowledge also includes some knowledge about TCP, UDP, cache and other stuff.
  - pseudalopex 10y ago
    Knowing when to use an AVL tree is orthogonal to being able to write one under pressure on a whiteboard. But as long as someone knows that different trees have different performance characteristics, I care more about how they decided what to optimize and why they recommend a lookup-optimized tree over a cache.
    - jorgemf 10y ago
      Yes, this is what I meant
  - FLUX-YOU 10y ago
    The amount of things we need to know is not commensurate with salaries for companies that lazily copy someone else's interview. Most of us are not practitioners that get to dictate a lot of the technical decisions. We're just told we need to know what an AVL tree is before we can work on CRUD app #4272095. If you work really hard, learn all of this stuff, and do a really good job and save your company a bunch of trouble by knowing all of this, you won't get a dime for it, and that's the problem. You get a pat on the back and you feel slightly less like an imposter for a few days. People are arguing that we should offer quality for free. This is what open source is for. I would argue security is more important than performance knowledge, but there is virtually zero focus on this that I've heard from the technical interview rabble-rousing that goes on in these threads.
- khedoros1 10y ago
  No, we should learn the basic algorithms and data structures (and their performance and storage characteristics) because they're the building blocks of everything else we use. You're using some API? OK, cool. Knowing some about its internal workings means that when you've got some wonky performance issue, you've got a basis to start reasoning from, to find and fix the cause of the problem.
  - throwaway9475 10y ago
    Never once has knowing about the performance of linked lists or hashmaps been necessary to fix an API issue. 99% of your API issues will be "this doesn't work for X reason", not "this API response is slow because weren't using X instead of Y data structure".
    - khedoros1 10y ago
      You sound like you've worked with significantly different code than I have. Your "never once" is my "almost always", and my "X reason" is often because I'm working with an immature, unreleased library developed by another team at my employer.
      - throwaway9475 10y ago
        What's more likely: that everyone needs to know intimate details about basic data structures or that the world is held together with duct tape and Perl and 95% of code is written by people not in Silicon Valley who need it to just work?
deleted 10y ago
[deleted]
rebootthesystem 10y ago
I think you are looking at this wrong. I have zero problems with someone presenting themselves this way and would definitely consider hiring the person. Here's reality: Someone who knows their stuff is able to dive into details of their work in a way that an impostor can't. My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it. I want to see code, documentation, examples of trade-offs and a discussion of the reasoning, challenges, what could be made better, what should not be touched and why, project history, etc. A conversation with someone who knows what they are doing and is very actively involved in their work is very different from a conversation with someone who might be trying to bullshit you or simply doesn't know enough. I hate puzzles. All I learn from them as an employer is that someone might have devoted a month to memorizing a whole bunch of them for the interview. I would imagine that at the scale of a company like Google, resorting to puzzles as a first filter might be an inevitable reality. If you have to interview people en masse you almost have no choice. It's like Stanford having to filter through 40,000 applications a year to accept 2,000 students. You have no choice but to go algorithmic on that problem.
- bskap 10y ago
  The problem with your approach is that it excludes anyone who spends most of their time writing code for a business. I legally can't provide you with the code that I have written over the last several years. You're limiting your applicant pool to people who have been paid to work on open source, freelance web developers, and people with very little life outside of work. I agree that puzzles aren't all that great of a measure of ability, but at least anyone can do them without writing about thorny legal issues over IP or spending all of their free time on spare projects.
  - pc86 10y ago
    > You're limiting your applicant pool to people...with very little life outside of work. Imagine that. If your company exists solely to write CRUD apps in whatever JavaScript framework came out in March, you don't need to spend hours doing a deep dive into someone's side project todo list app. Unless, of course, you're looking for someone who will work 16 hours a day, 6 days a week, for one tenth of one percent.

by hashkb 10y ago

cauterized 10y ago

But I did learn the principle, back in school. I've just never needed to use it.

bigtimeidiot 10y ago

>If an engineer gave me your answer ("I never learned the principle because I never had to") I would know they aren't a fit for my team So we should learn all the things, ahead of time, just in case we get an interview question at some point in life?

hashkb 10y ago
No, it's the attitude. Saying "I don't know depth first search" is fine, saying "I'll never need this and by asking it you've revealed what a terrible company you are" is sour grapes.
- logfromblammo 10y ago
  Not revealed as a terrible company, perhaps, but as a terrible interviewer. If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries. That is, before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index, which is likely what I would be doing at most companies. Part of development is figuring out not just the answers to the questions, but also figuring out "Of all the questions I could have been asked, why was I asked that question?" A disappointingly large fraction of the time, the answer to "why did you ask that question?" is "we noticed a correlation, confused it for causation, and built an entire strategy around it".
  - joshuamorton 10y ago
    "Perhaps you won't, but since we don't know yet exactly what you'll be working on, we might know broadly what PA or even project, but we can't know what problems you will encounter or what direction it will take to debug any problems that arise, we want someone with a broad base of skills who can at the very least recognize performance problems and solve them in a simple case. We expect that if you can solve this relatively simple problem in an environment with no resources, that with the aide of documentation, profiling tools, and teammates to lean on, you'll be able to address much more complex issues that arise. On the other hand, if it takes you documentation and teammates to solve this simple case, who knows what kinds of tools it will take you to solve real world problems that arise." "Correlation does not imply causation" doesn't imply that correlation never implies causation.
    - skj 10y ago
      I think you mean to say that correlation and causation correlate.
  - quacker 10y ago
    > need to roll their own new solutions in the face of so many well-established libraries I'm not defending interview quiz-time, but it isn't (or shouldn't be) about rolling your own solution. It's about understanding concepts. Understanding the basics of time/space complexity are pretty fundamental when designing systems. Developers frequently encounter hashing and (probably less-often) trees, so I don't see an issue with asking something like "Why/how/when is a hash-based lookup faster <in some situation> than a tree-based lookup?" (as one question during an interview). If a person can give a good answer to this, they'll pretty easily be able to understand the performance tradeoffs of hash vs btree indexes when using mysql (and this same tradeoff in a variety of other situations).
    - logfromblammo 10y ago
      If you're measuring my design ability in the interview, you had better give me an opportunity to use that ability after being hired. Too many times have I been asked questions that shaped my expectations of the job, only to be disappointed later on. The worst offender in this respect put me through a technical screen that could only reasonably be passed by someone with a bachelor's degree in CompSci or equivalent work experience, only to later tell me that the code I write "should be understandable by a kid fresh out of high school" (actual quote). I applied to 12 different job postings that night. The interview led me to believe that I was being hired for my expertise, and the job expectation was actually to be a warm, brainless body in a formerly empty seat. That's why I don't like questions that act as proxies for some other metric. The questions you ask me are telling me about you as much as my answers tell you about me. When you cargo-cult interview procedures from another company, you are actually misrepresenting the nature of your own company as being like the company you stole your interviews from.
- kafkaesq 10y ago
  Saying "I don't know depth first search" is fine, No, it most definitely is not "fine". Even momentarily hesitating on question like "Would you use BFS or DFS in this case?" is more than enough to merit a quick transition to the "Do you have any questions for me?" phase, in many a modern, "As hire As, Bs hire Cs, you know" interview session, these days.
jorgemf 10y ago
As an engineer you should be able to see the global picture and know other things. Because you wont be able to use something to solve your problem if you don't know it in advance. I mean, you don't need to know the details, but you need to know how things works. For example, you might not need an AVL tree in your daily job, but if one day you need it to use it, you wont be able to notice if you don't know what is an AVL tree and what is its advantages over other trees. Another example, you don't need to know http1 and http2 differences for your daily work. But if you know them you will change how you do web pages and you will see a leap in terms of performance and scability. And that knowledge also includes some knowledge about TCP, UDP, cache and other stuff.
- pseudalopex 10y ago
  Knowing when to use an AVL tree is orthogonal to being able to write one under pressure on a whiteboard. But as long as someone knows that different trees have different performance characteristics, I care more about how they decided what to optimize and why they recommend a lookup-optimized tree over a cache.
  - jorgemf 10y ago
    Yes, this is what I meant
- FLUX-YOU 10y ago
  The amount of things we need to know is not commensurate with salaries for companies that lazily copy someone else's interview. Most of us are not practitioners that get to dictate a lot of the technical decisions. We're just told we need to know what an AVL tree is before we can work on CRUD app #4272095. If you work really hard, learn all of this stuff, and do a really good job and save your company a bunch of trouble by knowing all of this, you won't get a dime for it, and that's the problem. You get a pat on the back and you feel slightly less like an imposter for a few days. People are arguing that we should offer quality for free. This is what open source is for. I would argue security is more important than performance knowledge, but there is virtually zero focus on this that I've heard from the technical interview rabble-rousing that goes on in these threads.
khedoros1 10y ago
No, we should learn the basic algorithms and data structures (and their performance and storage characteristics) because they're the building blocks of everything else we use. You're using some API? OK, cool. Knowing some about its internal workings means that when you've got some wonky performance issue, you've got a basis to start reasoning from, to find and fix the cause of the problem.
- throwaway9475 10y ago
  Never once has knowing about the performance of linked lists or hashmaps been necessary to fix an API issue. 99% of your API issues will be "this doesn't work for X reason", not "this API response is slow because weren't using X instead of Y data structure".
  - khedoros1 10y ago
    You sound like you've worked with significantly different code than I have. Your "never once" is my "almost always", and my "X reason" is often because I'm working with an immature, unreleased library developed by another team at my employer.
    - throwaway9475 10y ago
      What's more likely: that everyone needs to know intimate details about basic data structures or that the world is held together with duct tape and Perl and 95% of code is written by people not in Silicon Valley who need it to just work?

deleted 10y ago

[deleted]

rebootthesystem 10y ago

I think you are looking at this wrong. I have zero problems with someone presenting themselves this way and would definitely consider hiring the person. Here's reality: Someone who knows their stuff is able to dive into details of their work in a way that an impostor can't. My response to the above would be to have the person bring in some of their work and take an hour or two to take a deep dive into it. I want to see code, documentation, examples of trade-offs and a discussion of the reasoning, challenges, what could be made better, what should not be touched and why, project history, etc. A conversation with someone who knows what they are doing and is very actively involved in their work is very different from a conversation with someone who might be trying to bullshit you or simply doesn't know enough. I hate puzzles. All I learn from them as an employer is that someone might have devoted a month to memorizing a whole bunch of them for the interview. I would imagine that at the scale of a company like Google, resorting to puzzles as a first filter might be an inevitable reality. If you have to interview people en masse you almost have no choice. It's like Stanford having to filter through 40,000 applications a year to accept 2,000 students. You have no choice but to go algorithmic on that problem.

bskap 10y ago
The problem with your approach is that it excludes anyone who spends most of their time writing code for a business. I legally can't provide you with the code that I have written over the last several years. You're limiting your applicant pool to people who have been paid to work on open source, freelance web developers, and people with very little life outside of work. I agree that puzzles aren't all that great of a measure of ability, but at least anyone can do them without writing about thorny legal issues over IP or spending all of their free time on spare projects.
- pc86 10y ago
  > You're limiting your applicant pool to people...with very little life outside of work. Imagine that. If your company exists solely to write CRUD apps in whatever JavaScript framework came out in March, you don't need to spend hours doing a deep dive into someone's side project todo list app. Unless, of course, you're looking for someone who will work 16 hours a day, 6 days a week, for one tenth of one percent.