5 ms·

I'm curious about what the common deficiencies that your encountering are. Do you mean lack of knowledge and testing and more applicable skills?

jfasi 9y ago
Unfortunately I can't share the exact questions we ask, but here's a smattering of the sorts of pitfalls I encounter, in no particular order: * Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess your data into a hashmap, hashset, whatever. * No or insufficient considerations for edge cases. What if the input array is empty? What if I pass in invalid arguments? What if the strings aren't ASCII? What if the numbers you're multiplying are very large? What if the input is coming from an untrusted source? * No questions about the size of the input. Some of my favorite questions are those whose solutions bifurcate on whether the input can fit on in memory, or whether it's coming in on a network stream. Some questions involve multiple arrays, and I always like to ask "you assume A is much bigger than B, but what if A is much smaller than B?" * We place a great deal of weight not just on the solution, but on justifying why that solution is the most appropriate one. More often than not, this hinges on the Big-O performance and the system on which we're running. It's a mistake to dive right in to your solution, because it robs you of the opportunity to demonstrate that you have multiple fully-formed ideas knocking around in your head and you need to choose which one to code up. Otherwise I might get the impression that you only have one way to solve a problem. * Sorting the entire array when I ask you for the top N elements! Getting the top handful of elements is a linear-time operation, people! Bonus points: * No consideration for parallel processing. I've run maybe like two serial production workflows in my entire career. Try to parallelize your solution to handle bigger inputs. * Don't forget cache performance! I usually let candidates working in Python or other high-level languages slide on this one, but those odd C/C++ candidates have a major opportunity to impress me by optimizing their memory access patterns for cache performance. * I let this one go for intern and entry-level candidates, but testing should never be an afterthought. The moment you finish your implementation you should throw input/expected output pairs on the whiteboard. You don't even need to walk through them super carefully, just show me that you know how to design test cases.
- thaumasiotes 9y ago
  > Sorting the entire array when I ask you for the top N elements! Getting the top handful of elements is a linear-time operation, people! Unlike your other points, this one seems unlikely to cause any trouble in practice. From a polynomial-order perspective, a factor of log N is literally infinitesimal, essentially free.
- gpetukhov 9y ago
  These are pretty hard questions for an average junior role. But depends on a company.
- gbuk2013 9y ago
  Most of these things are not “junior” level at all. There are exceptional people though and I suppose it makes sense for you to try and hire those. But large amounts of disappointment are very much part of the process then.
- crdoconnor 9y ago
  >Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess your data into a hashmap, hashset, whatever. Big O should be an afterthought - the MO of any developer ought to be to get it right and then refactor - and worry about speed after profiling. Premature optimization is an antipattern you should be selecting against, not for.
  - dozzie 9y ago
    No. Leaving landmines like an easily avoidable linear search in a loop is an antipattern.
- VexorLoophole 9y ago
  Dunno how i should feel about this. Somehow i got into Tech Industry without a fitting degree and found myself in a smallish (30 people) company as the only SysAdmin. Exploring, setting, and controlling all technical parts this office needs: Multiple Linux VMs with different services like smb, confluence, ...; AD- and Terminal Windows Server; Device-Managment of all used MacBooks; and so on. I always also liked to code stuff, and always found a way to archive what i tried to solve. But of course i never build something big or even though about things like super efficient ways to archive what i did. I always though that when i keep going and try to build my small personal projects, one day i can maybe start as a junior dev. Even without the degree. But your post somehow states that a junior dev has to think about edge cases even before they occur. As a Sysadmin i also have to do this. But i always imagined that the job as developer is no one man show, and that these edge cases will be found together. Code will be reworked when a more experienced team member found a pithole.

jfasi 9y ago

Unfortunately I can't share the exact questions we ask, but here's a smattering of the sorts of pitfalls I encounter, in no particular order: * Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess your data into a hashmap, hashset, whatever. * No or insufficient considerations for edge cases. What if the input array is empty? What if I pass in invalid arguments? What if the strings aren't ASCII? What if the numbers you're multiplying are very large? What if the input is coming from an untrusted source? * No questions about the size of the input. Some of my favorite questions are those whose solutions bifurcate on whether the input can fit on in memory, or whether it's coming in on a network stream. Some questions involve multiple arrays, and I always like to ask "you assume A is much bigger than B, but what if A is much smaller than B?" * We place a great deal of weight not just on the solution, but on justifying why that solution is the most appropriate one. More often than not, this hinges on the Big-O performance and the system on which we're running. It's a mistake to dive right in to your solution, because it robs you of the opportunity to demonstrate that you have multiple fully-formed ideas knocking around in your head and you need to choose which one to code up. Otherwise I might get the impression that you only have one way to solve a problem. * Sorting the entire array when I ask you for the top N elements! Getting the top handful of elements is a linear-time operation, people! Bonus points: * No consideration for parallel processing. I've run maybe like two serial production workflows in my entire career. Try to parallelize your solution to handle bigger inputs. * Don't forget cache performance! I usually let candidates working in Python or other high-level languages slide on this one, but those odd C/C++ candidates have a major opportunity to impress me by optimizing their memory access patterns for cache performance. * I let this one go for intern and entry-level candidates, but testing should never be an afterthought. The moment you finish your implementation you should throw input/expected output pairs on the whiteboard. You don't even need to walk through them super carefully, just show me that you know how to design test cases.

thaumasiotes 9y ago
> Sorting the entire array when I ask you for the top N elements! Getting the top handful of elements is a linear-time operation, people! Unlike your other points, this one seems unlikely to cause any trouble in practice. From a polynomial-order perspective, a factor of log N is literally infinitesimal, essentially free.
gpetukhov 9y ago
These are pretty hard questions for an average junior role. But depends on a company.
gbuk2013 9y ago
Most of these things are not “junior” level at all. There are exceptional people though and I suppose it makes sense for you to try and hire those. But large amounts of disappointment are very much part of the process then.
crdoconnor 9y ago
>Number one is probably no Big-O performance considerations, or Big-O is an afterthought. For the love of God, please please please don't do a linear search on an unsorted array anywhere inside a nested loop. If you're going to do any appreciable number of lookups, preprocess your data into a hashmap, hashset, whatever. Big O should be an afterthought - the MO of any developer ought to be to get it right and then refactor - and worry about speed after profiling. Premature optimization is an antipattern you should be selecting against, not for.
- dozzie 9y ago
  No. Leaving landmines like an easily avoidable linear search in a loop is an antipattern.
VexorLoophole 9y ago
Dunno how i should feel about this. Somehow i got into Tech Industry without a fitting degree and found myself in a smallish (30 people) company as the only SysAdmin. Exploring, setting, and controlling all technical parts this office needs: Multiple Linux VMs with different services like smb, confluence, ...; AD- and Terminal Windows Server; Device-Managment of all used MacBooks; and so on. I always also liked to code stuff, and always found a way to archive what i tried to solve. But of course i never build something big or even though about things like super efficient ways to archive what i did. I always though that when i keep going and try to build my small personal projects, one day i can maybe start as a junior dev. Even without the degree. But your post somehow states that a junior dev has to think about edge cases even before they occur. As a Sysadmin i also have to do this. But i always imagined that the job as developer is no one man show, and that these edge cases will be found together. Code will be reworked when a more experienced team member found a pithole.