DataChef Logo
Letter on Designing Bootcamps
Letter on Designing Bootcamps

Letter on Designing Bootcamps

πŸ’‘
From a strategic point of view, Data Engineering bootcamps are especially important for DataChef, considering the global market demand and insufficient talented candidates.
  1. We should experiment. You can't set one strategy and that is fine. Be OK with changing our minds, direction, and strategy.
  1. There might be a few strategies running in parallel to measure the effectiveness.
  1. Why do we run Bootcamps? Take a candidate only after delivering THA if s/he:
    1. matches
      Our Core Values
      Our Core Values
      (litmus test: do you like to work with him?)
    2. shows an aptitude (how to measure? 90% historical data and 10% questions and curiosity he shows in follow-up rounds or emails)
    3. is not ready to join you in ongoing Client projects because he lacks a few (or many) specific skills that stop him from an impactful git push within his first week at the client site. We focus on taking them from "Novice to Advanced Beginner" or "Advanced Beginner to Competent.” The terminology above is based on the Dreyfus skill acquisition model:
      1. πŸ‘¨β€πŸ³
        If you are interested in learning more about the Dreyfus model, watch this video by Dave Thomas (pragmatic Dave) and this video by Andy Hunt. If you are really serious about "Learning" go straight and read their excellent book titled, Pragmatic Thinking & Learning: Refactor your Wetware.
  1. Example of successful bootcampers:
    1. A python developer who has done a lot of web app and microservices but never focused on data engineering + he is a good consultant or keen to invest in becoming one
    2. A Java developer who has done on-prem data crunching but never on AWS + he is a good consultant or keen to invest in becoming one
    3. A junior developer who has done a few pet projects but is flexible and open enough to be shaped by us in a particular form or career path + he is a good consultant or keen to invest in becoming one
  1. Trade-offs: running bootcampers is quite costly if you sum all hours our mentor chefs spend there, and those hours could be spent well on recipe or content development if not on client projects. This is not a good cause campaign, and we should do cost-vs-benefit before committing too much.
    1. πŸ’£
      Be aware of NIH syndrome.
  1. Bootcamps should not be designed based on one or a few specific bootcampers strengths (or lack of experience). This will mislead us.
  1. Our training style:
    1. Highly opinionated. We know our game so don't be shy to call "tableau" ugly, "pandas" a toy for preschool, or "dbt" a design flaw. Our ideal output is a focused chef, not a generic data professional with a bag of keywords on his resume.
      1. πŸ’‘
        If we are training someone with a specific client need in mind, the best place to start is the of that client project.
    2. Unintrusive. It is like having a colorful leadership with transparent management. Be there watching and caring but don't get involved too much. Why?
      1. this must be felt like a fun and fulfilling journey for bootcamper and not a go back to your dear powerpoint lecturing professor.
      2. too much active training comes with a time and energy cost. Remember trade-offs!
    3. Minimal. Less is more. We are persistent (and obsessed) on a small set of topics and the quality of learning them. This can be super practical or even theoretical subjects we feel every chef must know well. At the same time, we are conscious of the cognitive load (and stress of novice) on our bootcampers. Here is an example conversation I've had:
      1. Topics covered in chapters 1,4,7 of book X you must know very well. If you don’t you'll let us down in projects by reinventing the wheel or making bad decisions. You don’t learn well and I found it out: then you'll buy my beer for a month (and I drink a lot).
      2. Topics covered in chapters 2,3 are interesting to have a mental bookmark about them so I suggest you skim it. If you know them and surprise me later I might buy you a beer (intrigue mode on!)
      3. The rest are bla bla because publishing houses still live in Shakespeare's time and can't publish a book under 200 pages so the author had to do something. Ignore them.
        1. πŸ’‘
          It is stressful for a committed novice to cut through the noise and skip sections or chapters. For him, everything is equally important because he is a novice. We can help by giving him confidence that those chapters are safe to skip. Cut through the noise for him.
    4. Cherrypick and curate: The Internet is full of good and lots of not-so-good content because someone once taught us "content is king" and here we are with 1.408.437.232 blog posts about AWS data transfer costs (and still only one nailed it down). We don't add to the noise. If you find a full or part of a book chapter, official doc, blog post, podcast episode, Youtube video or cover it good enough, just link to that part on your checklist for bootcamper. Don’t redo it, you have a finite number of keystrokes left in your hands and it can be spent for creating something that doesn't exist yet.
    5. Ping pong and interactive: It is no fun being an information sponge for 3 months even if DataChef market it as "Bootcamp". Our weekly accountability calls are not a "how do you do" soft touch but measuring how persistent is this potential-future-chef with learning and is our assessment of his learning aptitude was realistic. Bootcampers should do something every week, not only READs but also WRITEs. This helps them build the cadence and rhythm of producing. Here are some examples of small commitments you are entitled to ask for:
      1. 😱
        Unpopular opinion: learning new things is absurdly overrated in our industry. The majority of candidates during screen calls say their clicking core value is "Design to learn quickly". The focus of that core value is on "Design" and "Quickly" more than being on "Learn" as if they are capable of planning an effective learning path for themselves in a short time or not. Still, candidates take pride in how many new Javascript frameworks they've read about in the last 6 months. So many forks on Github and so few contributions, so many upvotes on StackOverflow and so few answers... sight!
      2. Now that you learned the basics of DataFrames, see if you can transform this single-threaded code I give you today to run in parallel. Show me your code next week and we'll review it together.
      3. Now that you found S3 retention cycles interesting, see if you can add a paragraph or two to this draft blog post we are going to publish? I'll make sure your name be there as the second author if you like.
      4. Now that you learned these two courses it is time to have a hands-on lab test on or sign you up for an AWS certificate mock test etc.
        1. πŸ’‘
          You should try to keep the ping pong consistent by asking for some action even small every week. My favorite rule is never let it go for more than one day!
          Video preview
    6. 🀩 Nice to have would be having a theme in this journey like we are going to develop this car pricing application for Blue Nissan company from bottom-up and you will learn all skills you need in this context... Warning: this might sound easy but is actually very hard to set such an overarching fun context. Examples of successful courses that do this well: courses by Mark Clark and MLOps training by Goku Mohandas
  1. Make our Bootcamp public in the future. We should be really proud of it before letting it go.
Β 
Β 
Γ—