4 ms·

Since I started interviewing applicants, my two favourite questions are: a) What's the difference between an array and a set? b) Describe how a hash table wor

by galbar 5y ago

Since I started interviewing applicants, my two favourite questions are: a) What's the difference between an array and a set? b) Describe how a hash table works. The reasons are: a) It is important to know the difference between ordered and unordered collections and I don't want to be in a position where I don't trust that my teammate will use the right data structure in their PR. b) a hash table works with the same principles on which scalable services are built: database sharding, traffic loadbalancing (with stickiness), kafka stream processing, etc. In my experience, those two questions are a good indicators on how the interviewee will perform in the rest of the interview.

nathias 5y ago
Whats so terrible about telling someone to use an ordered collection in their PR?
- galbar 5y ago
  Depending on the usage and how core it is to the problem we are solving, the architecture of the subsystem may be affected negatively by the wrong choice of data structure. It is also not hard at all to learn and understand the difference of these two fundamental data structures.
  - nathias 5y ago
    It could (probably not) be affected negatively by the wrong choice of a data structure, but what harm is it if the coder doesn't know, is then informed of it as part of peer review and that's that?
Aeolun 5y ago
When hiring for frontend developers, I don’t think there’s any point to those questions. If someone is not using the right data structure in their PR, that’s something we can remedy by means of a short discussion. Same for a hash table. Describing why it is better for some things is quick. The goal of the interview is mostly that I trust that someone will understand (and listen) when I explain things like this. Not whether they know already.
- mtberatwork 5y ago
  > When hiring for frontend developers, I don’t think there’s any point to those questions. Why not? Array and Set are both part of JavaScript.
- galbar 5y ago
  >When hiring for frontend developers, I don’t think there’s any point to those questions I've been at a company in which the website had very slow performance because the FE did not know the differences between those data structures and did a O(n*m) algorithm to match elements from two collections (`listA.forEach(i -> listB.indexOf(i.foo))`). The backend returned JSON objects with the keys ready to be queried correctly and the FE converted it to arrays for some reason. Nobody in the FE team realized this was a bad idea until someone complained about how slow the site was. >The goal of the interview is mostly that I trust that someone will understand (and listen) when I explain things like this. Not whether they know already. It hugely depends on the expected experience of the role for which the candidate is being interviewed. I would absolutely expect a mid-level engineer to know those concepts.
  - mewpmewp2 5y ago
    Doesn't mean they were incompetent for this reason in particular. First good FE should be able to notice when site is performing badly. This has nothing to do with data structures. Whether by themselves, or knowing how to add tools that automatically diagnose issues like that. The same way they should be able to notice other UX frustrations/issues. UX designer can't think of every little detail ahead of time/give a screen for every edge case, so FE should be able to use their experience, to understand some common best UX practices on how to display errors for an input, when to validate etc --- on blur, on type, the fact that modal should close when you click on the darkened background, etc. Then they should be able to debug why it's taking that much time, by using developer tools, seeing where the bottleneck lies, then common sense can be used to determine that this is the algorithm causing the issue. In FE, 99% of the time there would be performance issues unrelated to this type of situation. It could be for example when using React and causing unnecessary calculations and re-renders, potentially using some library in invalid more or dev mode, so to figure that out in most cases it's just most straight forward to use the tools, that will point out where the issue lies and then solve it. I bet more often it would be some small component, triggering re-render of whole page when typing something to an input, or for instance react-hooks causing unnecessary re-renders. Learning data structures won't prepare you for this. Your time is better spent on other items. There's way more important things around FE that are way more important to know whether eng knows about or is experienced with those. So rather than asking about data structures, create an existing front end project, where there is some bad code used which causes bad performance and see how they go about debugging and discovering the underlying issue. Or maybe, just if they notice the issue at all. This is what we are doing in our interview processes. We provide an existing mock project, maybe including both backend and frontend, where we ask the interviewee to either fix something, add some new feature and/or suggest improvements to the code/UI, frontend in general. Simulating the real world work as closely as possible. You can't do 1,000 hours of leetcode for that, you need actual FE skills and experience. You can understand that double .forEach over a large list of items is a bad thing without ever having to know about big O notation. This is also much better than asking obscure questions on about how JavaScript hoisting, object inheritance and other things you really don't think about when writing ES6 and adhering eslint practices work. Whenever we have asked candidates at the end what they thought of this exercise the feedback has been positive, of course maybe they were lying to not step on any toes, but they seemed sincere to me. Secondly I would never be confident that someone is good/experienced with FE after them being able to just answer some data structure questions and not seeing them actually try to solve some FE related problem.
ManlyBread 5y ago
I have been working as a programmer since 2015 and I'm not sure if I could answer these questions.
- ZephyrBlu 5y ago
  Why aren't you sure? These seem like straightforward questions for people with a little experience.
  - michaelt 5y ago
    An experienced programmer in Python or Java would certainly know the difference between an array and a set. But someone doing embedded C programming, where a mere printf function is an extravagant luxury? You could program for years and not encounter a set.
    - LorenPechtel 5y ago
      At that level it doesn't have the label "set" but bit flags are a form of set.

by galbar 5y ago

nathias 5y ago

Whats so terrible about telling someone to use an ordered collection in their PR?

galbar 5y ago
Depending on the usage and how core it is to the problem we are solving, the architecture of the subsystem may be affected negatively by the wrong choice of data structure. It is also not hard at all to learn and understand the difference of these two fundamental data structures.
- nathias 5y ago
  It could (probably not) be affected negatively by the wrong choice of a data structure, but what harm is it if the coder doesn't know, is then informed of it as part of peer review and that's that?

Aeolun 5y ago

When hiring for frontend developers, I don’t think there’s any point to those questions. If someone is not using the right data structure in their PR, that’s something we can remedy by means of a short discussion. Same for a hash table. Describing why it is better for some things is quick. The goal of the interview is mostly that I trust that someone will understand (and listen) when I explain things like this. Not whether they know already.

mtberatwork 5y ago
> When hiring for frontend developers, I don’t think there’s any point to those questions. Why not? Array and Set are both part of JavaScript.
galbar 5y ago
>When hiring for frontend developers, I don’t think there’s any point to those questions I've been at a company in which the website had very slow performance because the FE did not know the differences between those data structures and did a O(n*m) algorithm to match elements from two collections (`listA.forEach(i -> listB.indexOf(i.foo))`). The backend returned JSON objects with the keys ready to be queried correctly and the FE converted it to arrays for some reason. Nobody in the FE team realized this was a bad idea until someone complained about how slow the site was. >The goal of the interview is mostly that I trust that someone will understand (and listen) when I explain things like this. Not whether they know already. It hugely depends on the expected experience of the role for which the candidate is being interviewed. I would absolutely expect a mid-level engineer to know those concepts.
- mewpmewp2 5y ago
  Doesn't mean they were incompetent for this reason in particular. First good FE should be able to notice when site is performing badly. This has nothing to do with data structures. Whether by themselves, or knowing how to add tools that automatically diagnose issues like that. The same way they should be able to notice other UX frustrations/issues. UX designer can't think of every little detail ahead of time/give a screen for every edge case, so FE should be able to use their experience, to understand some common best UX practices on how to display errors for an input, when to validate etc --- on blur, on type, the fact that modal should close when you click on the darkened background, etc. Then they should be able to debug why it's taking that much time, by using developer tools, seeing where the bottleneck lies, then common sense can be used to determine that this is the algorithm causing the issue. In FE, 99% of the time there would be performance issues unrelated to this type of situation. It could be for example when using React and causing unnecessary calculations and re-renders, potentially using some library in invalid more or dev mode, so to figure that out in most cases it's just most straight forward to use the tools, that will point out where the issue lies and then solve it. I bet more often it would be some small component, triggering re-render of whole page when typing something to an input, or for instance react-hooks causing unnecessary re-renders. Learning data structures won't prepare you for this. Your time is better spent on other items. There's way more important things around FE that are way more important to know whether eng knows about or is experienced with those. So rather than asking about data structures, create an existing front end project, where there is some bad code used which causes bad performance and see how they go about debugging and discovering the underlying issue. Or maybe, just if they notice the issue at all. This is what we are doing in our interview processes. We provide an existing mock project, maybe including both backend and frontend, where we ask the interviewee to either fix something, add some new feature and/or suggest improvements to the code/UI, frontend in general. Simulating the real world work as closely as possible. You can't do 1,000 hours of leetcode for that, you need actual FE skills and experience. You can understand that double .forEach over a large list of items is a bad thing without ever having to know about big O notation. This is also much better than asking obscure questions on about how JavaScript hoisting, object inheritance and other things you really don't think about when writing ES6 and adhering eslint practices work. Whenever we have asked candidates at the end what they thought of this exercise the feedback has been positive, of course maybe they were lying to not step on any toes, but they seemed sincere to me. Secondly I would never be confident that someone is good/experienced with FE after them being able to just answer some data structure questions and not seeing them actually try to solve some FE related problem.

ManlyBread 5y ago

I have been working as a programmer since 2015 and I'm not sure if I could answer these questions.

ZephyrBlu 5y ago
Why aren't you sure? These seem like straightforward questions for people with a little experience.
- michaelt 5y ago
  An experienced programmer in Python or Java would certainly know the difference between an array and a set. But someone doing embedded C programming, where a mere printf function is an extravagant luxury? You could program for years and not encounter a set.
  - LorenPechtel 5y ago
    At that level it doesn't have the label "set" but bit flags are a form of set.