6 ms·

My two cents: simple supply and demand. The slow deflation of the startup bubble of the past five years or so has killed the junior developer. Once upon a time,

by jfasi 9y ago

My two cents: simple supply and demand. The slow deflation of the startup bubble of the past five years or so has killed the junior developer. Once upon a time, there so much competition for engineering talent in the startup world that even developers with little to no experience and/or formal training were being handed lucrative jobs. Looking back we see clear signs of a seller's market in talent: companies went out of their way to hire anyone remotely competent. Once hired, devs could hopefully rely on their company's mentorship, training, and experience opportunities to raise themselves up, and companies could rely on the same for retention. Coding boot camps sprung up to give people just enough skills and credibility to get their foot in the door. Salaries were high. That gold rush has since dried up. Early stage funding has plummeted. Fewer and fewer companies want to go public. Large companies like Google, Facebook, etc. now dominate their respective product categories. Why is it now difficult to find senior people? Because for someone with years of experience and/or formal training, these companies offer the holy trinity of excellent pay, top-tier perks, and opportunities for career growth. My personal opinion is that many of these junior devs simply aren't very good. As someone who conducts interviews at one of those aforementioned big companies, I'm consistently disappointed by how poorly most candidates perform on basic interview questions. And I don't mean the kind that test book knowledge of some obscure algorithm, I'm talking basic coding tasks. From where I stand it's a matter of an oversupply of inexperienced, under-qualified developers that are no longer being absorbed into startups desperate for warm bodies to do rudimentary coding tasks, coupled with a strong demand for senior folks from big companies with the coffers to pay them.

apthnz 9y ago
As someone starting to teach myself how to code, I'd be interested to hear more about the basic coding tasks people are failing at.
- accatyyc 9y ago
  As someone else who have hired developers I agree with the parent post here. Examples include: - totally oblivious to standard library for the language/frameworks, reimplementing the most basic things (poorly) - even after a 3 year CS education, lacks basic understanding of object-oriented programming/class hierarchies - has trouble implementing even simple if/else-conditions without help I’m talking really basic stuff here. You’d be surprised. I assume that if you are self-taught, you have the interest and because of that already much more knowledge than many graduates.
  - hanniabu 9y ago
    The if/else part is really astonishing. The other ones I can understand in SOME way but the if/else is logic that's used in every day life. If I do this then that will happen, otherwise this other thing may happen. Very surprising.
    - analogic 9y ago
      "The other ones I can understand in SOME way" Not me, "OOP class hierarchys" still incomprehensible gibberish here.
- jfasi 9y ago
  I gave a little writeup to a sibling comment, PTAL.
- odiroot 9y ago
  For me it would be lack of intuition / imagination for building software. Some people just cannot come up with a high level idea of a solution. Many of them immediately jumps into code, even worse so it's usually some UI code.
- wccrawford 9y ago
  We have a pre-interview test that is basically "use flickr's api to show some pictures", with a few details about how the pictures are sized and arranged. Applicants that have gone to bootcamps and even college frequently fail this miserably. Many of the rest fail to understand the details. We even had one use a completely different end point than the one specified by URL to the documentation. Some have just given up and turned nothing in, or something that they admitted didn't work. These are candidates that we liked their resume enough to give them a shot, not just anyone who applied.
  - mattmanser 9y ago
    That's, errr, a very high bar you got there. People got it working, showing they can code just fine, and you fail them because they got some details wrong?
    - Raidion 9y ago
      If you have only one or two positions open, have no trouble finding applicants, why not give a test that has a 5% pass rate if that means you end up with 6 people to choose from and still have to turn people away? What would the advantage be of making it easier just so you would have to review and turn even more people away?
    - wu_tang_chris 9y ago
      that's a super regular bar that anyone who's moderately able to program or learn new things should be able to jump over easily. details are important in a technical field.
    - wccrawford 9y ago
      We aren't looking for someone that has to be told repeatedly to read the entire ticket and actually do everything in it. We're looking for detail-oriented people. And we find them. It's so much easier to work with them.
  - mixmastamyk 9y ago
    I think teaching is a bit behind on the rest api thing, probably isn’t specifically taught. Doesn’t mean they couldn’t learn it. Why do you refuse to mentor a few of them? /s
mgenglder 9y ago
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.

by jfasi 9y ago

apthnz 9y ago

As someone starting to teach myself how to code, I'd be interested to hear more about the basic coding tasks people are failing at.

accatyyc 9y ago
As someone else who have hired developers I agree with the parent post here. Examples include: - totally oblivious to standard library for the language/frameworks, reimplementing the most basic things (poorly) - even after a 3 year CS education, lacks basic understanding of object-oriented programming/class hierarchies - has trouble implementing even simple if/else-conditions without help I’m talking really basic stuff here. You’d be surprised. I assume that if you are self-taught, you have the interest and because of that already much more knowledge than many graduates.
- hanniabu 9y ago
  The if/else part is really astonishing. The other ones I can understand in SOME way but the if/else is logic that's used in every day life. If I do this then that will happen, otherwise this other thing may happen. Very surprising.
  - analogic 9y ago
    "The other ones I can understand in SOME way" Not me, "OOP class hierarchys" still incomprehensible gibberish here.
jfasi 9y ago
I gave a little writeup to a sibling comment, PTAL.
odiroot 9y ago
For me it would be lack of intuition / imagination for building software. Some people just cannot come up with a high level idea of a solution. Many of them immediately jumps into code, even worse so it's usually some UI code.
wccrawford 9y ago
We have a pre-interview test that is basically "use flickr's api to show some pictures", with a few details about how the pictures are sized and arranged. Applicants that have gone to bootcamps and even college frequently fail this miserably. Many of the rest fail to understand the details. We even had one use a completely different end point than the one specified by URL to the documentation. Some have just given up and turned nothing in, or something that they admitted didn't work. These are candidates that we liked their resume enough to give them a shot, not just anyone who applied.
- mattmanser 9y ago
  That's, errr, a very high bar you got there. People got it working, showing they can code just fine, and you fail them because they got some details wrong?
  - Raidion 9y ago
    If you have only one or two positions open, have no trouble finding applicants, why not give a test that has a 5% pass rate if that means you end up with 6 people to choose from and still have to turn people away? What would the advantage be of making it easier just so you would have to review and turn even more people away?
  - wu_tang_chris 9y ago
    that's a super regular bar that anyone who's moderately able to program or learn new things should be able to jump over easily. details are important in a technical field.
  - wccrawford 9y ago
    We aren't looking for someone that has to be told repeatedly to read the entire ticket and actually do everything in it. We're looking for detail-oriented people. And we find them. It's so much easier to work with them.
- mixmastamyk 9y ago
  I think teaching is a bit behind on the rest api thing, probably isn’t specifically taught. Doesn’t mean they couldn’t learn it. Why do you refuse to mentor a few of them? /s

mgenglder 9y ago

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.