3 ms·

Would a better way to interview be questions like: 1) I have an array of 1000 integers, which of these would be the best way to sort them a) quicksort b) bubbl

Would a better way to interview be questions like: 1) I have an array of 1000 integers, which of these would be the best way to sort them a) quicksort b) bubblesort... 2) what sort of structure would you use to store a list of numbers and strings 1) dictionary/hash 2) two arrays ... and so on. These would give you the certainty that they know which is which, you could ask give reasons to see if they mention O() and so on. IRL it's very seldom that you write one of these structures, but you use them all the time and need to know which one to use when.

Clubber 10y ago
I second that. It's good to know what tools to use and why, but not necessary to know how to make the tools.
yason 10y ago
Certainly. Of course, you should know how they work to the extent that you could write a (trivial) implementation if ever needed, but that very rarely happens. However, occasionally you do need to write specialised implementations tailored to your particular usecase and chosen data structures. Hash tables in particular come to mind. For example, I once had to write a statically allocated (fixed-size) hash table with O(1) lookups. A lot of tradeoffs enter the picture at that point so you had better know a dozen different types of hash tables to hash out a suitable implementation for the particular usecase.
vickychijwani 10y ago
I like the fact that this tests understanding of certain trade-offs. It can be improved in 2 ways though: 1. It doesn't allow the candidate to map out the available options for themselves, which is an equally important skill in software dev. When I'm working, I often have to spend a good chunk of time exploring the space of solutions, and only then can I move on to assess the trade-offs involved. 2. Another important skill is being able to question assumptions. You could (for example) intentionally under-specify the problem and let the candidate ask follow-up questions to root out assumptions/constraints. Example problem: You have an array of integers, how would you decide on an algorithm to sort it? Expected clarifying questions: (a) is there any relation/pattern in the integers stored? If they're all from a small set (say, 1-1000) then a simple counting sort works best, (b) how large is the array? If it doesn't fit in memory, a disk-based merge sort could be the best option.

Clubber 10y ago

I second that. It's good to know what tools to use and why, but not necessary to know how to make the tools.

yason 10y ago

Certainly. Of course, you should know how they work to the extent that you could write a (trivial) implementation if ever needed, but that very rarely happens. However, occasionally you do need to write specialised implementations tailored to your particular usecase and chosen data structures. Hash tables in particular come to mind. For example, I once had to write a statically allocated (fixed-size) hash table with O(1) lookups. A lot of tradeoffs enter the picture at that point so you had better know a dozen different types of hash tables to hash out a suitable implementation for the particular usecase.

vickychijwani 10y ago

I like the fact that this tests understanding of certain trade-offs. It can be improved in 2 ways though: 1. It doesn't allow the candidate to map out the available options for themselves, which is an equally important skill in software dev. When I'm working, I often have to spend a good chunk of time exploring the space of solutions, and only then can I move on to assess the trade-offs involved. 2. Another important skill is being able to question assumptions. You could (for example) intentionally under-specify the problem and let the candidate ask follow-up questions to root out assumptions/constraints. Example problem: You have an array of integers, how would you decide on an algorithm to sort it? Expected clarifying questions: (a) is there any relation/pattern in the integers stored? If they're all from a small set (say, 1-1000) then a simple counting sort works best, (b) how large is the array? If it doesn't fit in memory, a disk-based merge sort could be the best option.