6 ms·

I'm glad they're going away. > While coding boot camps had many course listings on JavaScript, Ruby, and web development, they had none that covered product ma

I'm glad they're going away. > While coding boot camps had many course listings on JavaScript, Ruby, and web development, they had none that covered product management, wireframing, cloud computing, DevOps, or Agile methodologies. In other words, they don’t teach students the other important entrepreneurial tech skills. This makes sense seeing how their focus is coding. But as I stated in my last article, many recruiters are not just looking for engineers, but DevOps engineers – those who have strong leadership, communication, and team-building skills. Being a coding god is one skill set, but knowing how to work collaboratively on a technical team and manage a product is another skill set in itself. This type of belief in what "coding" is, is hugely responsible for both the rise and fall of these horribly designed, while possibly well-intended, "bootcamps." Being a good software developer has absolutely nothing to do with "important entrepreneurial tech skills." Knowing how to tackle problems, envision loops and algorithms, write pseudocode, understand the basics of how requests on the Internet work, or how your computer accesses databases or files; these are skills of a good software developer. The end goal of being a software developer is not CEO. "many recruiters are not just looking for engineers, but DevOps engineers" No, recruiters all over the world are paying hundreds of thousands of dollars a year because they can't find any competent programmers anymore. There are hundreds of people who were taught how to write a conditional in Ruby on Rails available, but ask them to tackle a problem like: "how would you store 1 million strings, search through them while caching results, and make sure only certain individuals can access certain strings," and you get a deer in the headlights look. So recruiters don't ask questions like that anymore. They ask questions that can be simply memorized and regurgitated. When there's no difference between cramming for your History 101 mid-term and a technical interview for a software developer, we're not in a good spot. The sooner we can dispel the myth that programming and software is just "coding," "hustling," and "entrepreneurial skills" the sooner companies won't have to pony up over $150k/yr to find a competent software developer.

stale2002 9y ago
LOL! So your argument that what makes a person a good software engineer is the whiteboard coding algorithms? That stuff is EASIER to learn than actual software engineering skills. All you got to do is spend a couple months cramming from the book cracking the code interview. You learn that stuff in a singular CS class, that's called data structures and algorithms. You are right about one thing though, if we are in a state where you can cram for your interview, that is a bad spot. And that is precisely the problem with the CS algorithms type questions! The "hard" stuff in software engineering is about how you design maintainable code, how you design high level architecture, and generally all the skills that go into coding in a TEAM as opposed to be a programming superstar individual.
- Karrot_Kream 9y ago
  > That stuff is EASIER to learn than actual software engineering skills. All you got to do is spend a couple months cramming from the book cracking the code interview. You have got to be joking right? Not only is the intro-level algorithms class in universities a known-difficult class almost everywhere, MS and PhD students continue to try and discover better algorithms and new data structures. Sure if you're working on a CRUD web app then it doesn't matter, but if you're working on Postgres, it sure as hell matters.
  - stale2002 9y ago
    The PhD and MS stuff is not being asked in interviews. Yes, that stuff is hard. Tech interviews are 40 minutes max. There is only so much stuff that can be asked and programmed in such a short amount of time. The stuff being asked in tech interviews is "traverse a tree in this interesting way". There are only so many ways to traverse a tree. And no, I am not talking about crud interviews, I am talking about Google interviews, and similar. (Although Google hits the very high end of difficulty, most interviews are much easier). Perhaps there really is a way to do the mythical, problem solving, IQ test of a whiteboard programming interview. But that is NOT the way the industry does things currently. The way that the industry currently works is that literally half of interview questions are almost word for word listed in cracking the code interview (I counted!). And the ones that aren't are still quite common. When I did tech interviews with a dozen or so companies just recently, a full 90%! of interview questions were ones that I had been asked or studied before. Interviewers are lazy, and whiteboard algorithms as things are CURRENTLY is just about who can cram the most.
    - daotoad 9y ago
      Tech interviews are 40 minutes max? Where are you interviewing? I have seen far more 6+ hour interview loops that 40 minute ones. Maybe each session within the full loop accounts for 40 minutes. That being said, people have their pet questions they use to sort the wheat from the chaff--if you can't fizzbuzz your way out of a wet paper bag, I am not hiring you. The best questions are more about process than the final answer. Solve an easyish problem, add some features, add some more features. What other ways could you have solved that problem? Why did you choose this way? When would you use a different approach? How does your solution scale? The worst questions are gotcha questions with a right and wrong answer, `what does the C99 standard indicate is the correct size of a stack frame?`
vonmoltke 9y ago
> No, recruiters all over the world are paying hundreds of thousands of dollars a year because they can't find any competent programmers anymore. They pay it because they can't identify and source competent programmers, not because there aren't enough. Thus, when they (think they) find one they pay through the nose for it.
sotojuan 9y ago
Bootcamps are not going away, there just won't be so many of them any more. As another poster said, the market is correcting itself.
jefflombardjr 9y ago
> Being a good software developer has absolutely nothing to do with "important entrepreneurial tech skills." Knowing how to tackle problems, envision loops and algorithms, write pseudocode, understand the basics of how requests on the Internet work, or how your computer accesses databases or files; these are skills of a good software developer. I disagree. Knowing where to apply your skills at a company is just as important as having those skills. If your stakeholders aren't happy, it doesn't matter how beautiful the code is. You've failed to deliver. That being said, it's a balance you have to strike. You can't just focus entirely on making stakeholders happy, other wise you'd have a patchwork quilt of an application. Also, that's why I like side projects, you're the stakeholder and can focus on the tech/what you think is important.
sidlls 9y ago
> When there's no difference between cramming for your History 101 mid-term and a technical interview for a software developer, we're not in a good spot. Your "1 million strings" example is exactly the kind of thing that can be memorized, and is actually a quite common class of interview questions in certain segments of this industry. It's also only tangentially related to engineering. If I may, I'd draw an analogy with engineering a satellite system: your "million strings" example is more like the act of selecting a bolt from a catalog that fits the spec than it is engineering the spec in the first place.
- Hydraulix989 9y ago
  Which is fine because something like searching through a million strings is very much an actual problem that would be faced on-the-job -- usually the spec is already written and handed to you by your manager -- and we can all agree that being able to recall obscure syntactical knowledge or invert a binary tree are things that, while commonly asked in whiteboard interviews, aren't something an actual software engineer would ever be faced with in their daily work.

stale2002 9y ago

LOL! So your argument that what makes a person a good software engineer is the whiteboard coding algorithms? That stuff is EASIER to learn than actual software engineering skills. All you got to do is spend a couple months cramming from the book cracking the code interview. You learn that stuff in a singular CS class, that's called data structures and algorithms. You are right about one thing though, if we are in a state where you can cram for your interview, that is a bad spot. And that is precisely the problem with the CS algorithms type questions! The "hard" stuff in software engineering is about how you design maintainable code, how you design high level architecture, and generally all the skills that go into coding in a TEAM as opposed to be a programming superstar individual.

Karrot_Kream 9y ago
> That stuff is EASIER to learn than actual software engineering skills. All you got to do is spend a couple months cramming from the book cracking the code interview. You have got to be joking right? Not only is the intro-level algorithms class in universities a known-difficult class almost everywhere, MS and PhD students continue to try and discover better algorithms and new data structures. Sure if you're working on a CRUD web app then it doesn't matter, but if you're working on Postgres, it sure as hell matters.
- stale2002 9y ago
  The PhD and MS stuff is not being asked in interviews. Yes, that stuff is hard. Tech interviews are 40 minutes max. There is only so much stuff that can be asked and programmed in such a short amount of time. The stuff being asked in tech interviews is "traverse a tree in this interesting way". There are only so many ways to traverse a tree. And no, I am not talking about crud interviews, I am talking about Google interviews, and similar. (Although Google hits the very high end of difficulty, most interviews are much easier). Perhaps there really is a way to do the mythical, problem solving, IQ test of a whiteboard programming interview. But that is NOT the way the industry does things currently. The way that the industry currently works is that literally half of interview questions are almost word for word listed in cracking the code interview (I counted!). And the ones that aren't are still quite common. When I did tech interviews with a dozen or so companies just recently, a full 90%! of interview questions were ones that I had been asked or studied before. Interviewers are lazy, and whiteboard algorithms as things are CURRENTLY is just about who can cram the most.
  - daotoad 9y ago
    Tech interviews are 40 minutes max? Where are you interviewing? I have seen far more 6+ hour interview loops that 40 minute ones. Maybe each session within the full loop accounts for 40 minutes. That being said, people have their pet questions they use to sort the wheat from the chaff--if you can't fizzbuzz your way out of a wet paper bag, I am not hiring you. The best questions are more about process than the final answer. Solve an easyish problem, add some features, add some more features. What other ways could you have solved that problem? Why did you choose this way? When would you use a different approach? How does your solution scale? The worst questions are gotcha questions with a right and wrong answer, `what does the C99 standard indicate is the correct size of a stack frame?`

vonmoltke 9y ago

> No, recruiters all over the world are paying hundreds of thousands of dollars a year because they can't find any competent programmers anymore. They pay it because they can't identify and source competent programmers, not because there aren't enough. Thus, when they (think they) find one they pay through the nose for it.

sotojuan 9y ago

Bootcamps are not going away, there just won't be so many of them any more. As another poster said, the market is correcting itself.

jefflombardjr 9y ago

> Being a good software developer has absolutely nothing to do with "important entrepreneurial tech skills." Knowing how to tackle problems, envision loops and algorithms, write pseudocode, understand the basics of how requests on the Internet work, or how your computer accesses databases or files; these are skills of a good software developer. I disagree. Knowing where to apply your skills at a company is just as important as having those skills. If your stakeholders aren't happy, it doesn't matter how beautiful the code is. You've failed to deliver. That being said, it's a balance you have to strike. You can't just focus entirely on making stakeholders happy, other wise you'd have a patchwork quilt of an application. Also, that's why I like side projects, you're the stakeholder and can focus on the tech/what you think is important.

sidlls 9y ago

> When there's no difference between cramming for your History 101 mid-term and a technical interview for a software developer, we're not in a good spot. Your "1 million strings" example is exactly the kind of thing that can be memorized, and is actually a quite common class of interview questions in certain segments of this industry. It's also only tangentially related to engineering. If I may, I'd draw an analogy with engineering a satellite system: your "million strings" example is more like the act of selecting a bolt from a catalog that fits the spec than it is engineering the spec in the first place.

Hydraulix989 9y ago
Which is fine because something like searching through a million strings is very much an actual problem that would be faced on-the-job -- usually the spec is already written and handed to you by your manager -- and we can all agree that being able to recall obscure syntactical knowledge or invert a binary tree are things that, while commonly asked in whiteboard interviews, aren't something an actual software engineer would ever be faced with in their daily work.