5 ms·

> Bootcamp grads match or beat college grads on practical skills, and lose on deep knowledge. I feel as though you are attempting to lower the bar of what is a

by lsadam0 10y ago

> Bootcamp grads match or beat college grads on practical skills, and lose on deep knowledge. I feel as though you are attempting to lower the bar of what is acceptable in order to sell something :). The word 'practical' is thrown around in this article without much of a definition. Are we talking about making simple web pages? I've just finished conducting a round of interviews for a junior level position, and based on this experience I highly doubt I will be considering bootcamp graduates in the future. As an example, for a question which involved sorting an integer array, and providing a method GetElementAt(index)....95% of the bootcamp applicants implemented sort within the GetElementAt method so that the entire array is sorted with every single call. A handful of CS grads made the same mistake, but most of them did not. Is this sort of oversight excused in the idea of 'practical' programming? Or in your definition, is this considered deep knowledge?

busterarm 10y ago
Personally, I never expect people to pick the right algorithm the first time. In the real world it's hard to do. I'm much more interested in if they think about alternatives to their solution, know where the problems with theirs are and if they might find an alternate solution to the problem online. If you're hiring junior developers without expecting to be hands-on in their work and with plan to train them, then you aren't really hiring junior developers, you're just trying to pay at junior rates. It's not doing them or your business a service to hire them. There are plenty of CS grads out there with all sorts of algo skills but no practical and will take 3 months + to build anything in your stack. This is basically the same problem with different symptoms: You don't have the resources to hire a junior developer. It's just way easier to blame the hire than your company.
- lsadam0 10y ago
  I believe we are misunderstanding each other, as you are making some assumptions. We do spend time training junior developers. We are hands on during work. I'm talking about one problem at the start of the process. In the example, I didn't touch on their choice of sort algorithm. I was pointing out that they believed that re-sorting the same array, for every single GetIndexAt(x) call, was an ok thing to do. The majority of boot campers did, the majority of CS grads did not. So if we have two distinct groups applying for a junior level position, and one group has a stronger grasp on fundamentals, I fail to understand how a company is at fault for choosing the better candidate. Objectively, the junior level CS grad had a better understanding of the problem.
  - busterarm 10y ago
    Are they saying that it's an actual okay thing to do? ...like, you challenged them on it and had a discussion and they said it was perfectly okay regardless of size of array? Or it was just allowed to let lie and they said it's an okay thing to do because that's what's in their code? I think it's a huge mistake to conflate whether someone does know and whether they can know something. Some of the best programmers I've ever seen started off pretty clueless - most of that group learns things absurdly quickly too. I don't think that exercise gives you good information other than to confirm your expectations. I don't know whether that can tell you if they'll bring value to your organization or not.
    - lsadam0 10y ago
      There were a few hundred applications to sort through for the position. Applicants all received the same test. The initial response is used to filter the pool and decide with whom to speak with further. Only with a filtered applicant pool is it reasonable to sit and discuss their solution with. Some criteria is needed to filter the pool, so obviously those that have submitted a better initial solution will be selected. The exercise shows that some applicants will require more training than others.
      - dionidium 10y ago
        You're talking about a single junior-level position and you had a few hundred applications? That isn't passing my smell test.
        deleted 10y ago
        [deleted]
      - busterarm 10y ago
        There are many reasons why I think this process is broken that others have written so much at length about enough that I'm not going to bother taking the time. If it's enough for you to say that because you have a test that everyone takes and it filters your candidates so that's proof of ability, without even going into the results and asking if your test is optimizing for the correct things, there's nothing I can say to convince you otherwise. Anecdotal, but I know about a half dozen people with experience and CS degrees who would blow your filter but can really get shit done and don't really need any training. Hiring is hard and the real shame of this industry is that collectively we don't approach this problem with the same level of rigor that we do everything else because by and large we consider this sort of work to be beneath us and not worth a significant investment of our time.
xhedley 10y ago
Software companies aren't the only people who hire developers. I spent today (I'm a non-technical product owner in an enterprise) discussing middleware which will transform 10,000 miscellaneous transactions from multiple line of business system every night into our ERP. There's lots of domain logic and we're paying the supplier a lump sum more than the annual salary of a new CS or BC grad. It isn't a simple web page. Say the transformation from source to target with good sorting would take 100 milliseconds. If it took 10,000 times longer, that's 17 minutes - and that would meet my user requirements. If it didn't I'd expect the supplier to fix their SQL indexes. So none of their technical guys need to be good at sorting.
- lsadam0 10y ago
  That's a very good point. I'm only speaking from the view of my experience, and my responsibilities and concerns are different than your example. I suppose my initial skepticism of the article is grounded in that we do all we have different concerns, and I felt the article attempted to paint with too broad of a brush. The author would have helped me tremendously had they defined terms like practical programming.

by lsadam0 10y ago

busterarm 10y ago

Personally, I never expect people to pick the right algorithm the first time. In the real world it's hard to do. I'm much more interested in if they think about alternatives to their solution, know where the problems with theirs are and if they might find an alternate solution to the problem online. If you're hiring junior developers without expecting to be hands-on in their work and with plan to train them, then you aren't really hiring junior developers, you're just trying to pay at junior rates. It's not doing them or your business a service to hire them. There are plenty of CS grads out there with all sorts of algo skills but no practical and will take 3 months + to build anything in your stack. This is basically the same problem with different symptoms: You don't have the resources to hire a junior developer. It's just way easier to blame the hire than your company.

lsadam0 10y ago
I believe we are misunderstanding each other, as you are making some assumptions. We do spend time training junior developers. We are hands on during work. I'm talking about one problem at the start of the process. In the example, I didn't touch on their choice of sort algorithm. I was pointing out that they believed that re-sorting the same array, for every single GetIndexAt(x) call, was an ok thing to do. The majority of boot campers did, the majority of CS grads did not. So if we have two distinct groups applying for a junior level position, and one group has a stronger grasp on fundamentals, I fail to understand how a company is at fault for choosing the better candidate. Objectively, the junior level CS grad had a better understanding of the problem.
- busterarm 10y ago
  Are they saying that it's an actual okay thing to do? ...like, you challenged them on it and had a discussion and they said it was perfectly okay regardless of size of array? Or it was just allowed to let lie and they said it's an okay thing to do because that's what's in their code? I think it's a huge mistake to conflate whether someone does know and whether they can know something. Some of the best programmers I've ever seen started off pretty clueless - most of that group learns things absurdly quickly too. I don't think that exercise gives you good information other than to confirm your expectations. I don't know whether that can tell you if they'll bring value to your organization or not.
  - lsadam0 10y ago
    There were a few hundred applications to sort through for the position. Applicants all received the same test. The initial response is used to filter the pool and decide with whom to speak with further. Only with a filtered applicant pool is it reasonable to sit and discuss their solution with. Some criteria is needed to filter the pool, so obviously those that have submitted a better initial solution will be selected. The exercise shows that some applicants will require more training than others.
    - dionidium 10y ago
      You're talking about a single junior-level position and you had a few hundred applications? That isn't passing my smell test.
      - deleted 10y ago
        [deleted]
    - busterarm 10y ago
      There are many reasons why I think this process is broken that others have written so much at length about enough that I'm not going to bother taking the time. If it's enough for you to say that because you have a test that everyone takes and it filters your candidates so that's proof of ability, without even going into the results and asking if your test is optimizing for the correct things, there's nothing I can say to convince you otherwise. Anecdotal, but I know about a half dozen people with experience and CS degrees who would blow your filter but can really get shit done and don't really need any training. Hiring is hard and the real shame of this industry is that collectively we don't approach this problem with the same level of rigor that we do everything else because by and large we consider this sort of work to be beneath us and not worth a significant investment of our time.

xhedley 10y ago

Software companies aren't the only people who hire developers. I spent today (I'm a non-technical product owner in an enterprise) discussing middleware which will transform 10,000 miscellaneous transactions from multiple line of business system every night into our ERP. There's lots of domain logic and we're paying the supplier a lump sum more than the annual salary of a new CS or BC grad. It isn't a simple web page. Say the transformation from source to target with good sorting would take 100 milliseconds. If it took 10,000 times longer, that's 17 minutes - and that would meet my user requirements. If it didn't I'd expect the supplier to fix their SQL indexes. So none of their technical guys need to be good at sorting.

lsadam0 10y ago
That's a very good point. I'm only speaking from the view of my experience, and my responsibilities and concerns are different than your example. I suppose my initial skepticism of the article is grounded in that we do all we have different concerns, and I felt the article attempted to paint with too broad of a brush. The author would have helped me tremendously had they defined terms like practical programming.