blog article

Curriculum Spotlight: DevPoint Labs with Dave Jungst

Imogen Crispe

Written By Imogen Crispe

Last updated on November 22, 2016

Course Report strives to create the most trust-worthy content about coding bootcamps. Read more about Course Report’s Editorial Policy and How We Make Money.

    Table of Contents

  • Q&A


Salt Lake City coding bootcamp DevPoint Labs recently decided to move the HTML/CSS part of their courses into a pre-work module. We spoke to senior instructor Dave Jungst about the reasons behind this shift, and how DevPoint Labs iterates on and updates the curriculum for both their full-time Immersive Full-Stack Rails and the part-time After Hours Full-Stack JavaScript programs. He explains how DevPoint Labs is able to quickly adapt and adjust to new emerging technologies, and how that helps to better prepare students to get jobs as junior developers.


We spoke to you earlier this year about your role as an instructor– are you still working at DevPoint Labs and part-time on Exposure Tracker?

We finished up that project, and handed it over to a team to maintain it. So I’m spending most of my time teaching at DevPoint Labs now. Two days a week I teach the Full-Time Rails course and three nights a week I teach our After-Hours JavaScript course.

How are you involved with curriculum planning and development?

I’m responsible for maintaining all of the curriculum, keeping it up to date and making sure things don’t go stale. Jake Sorce and I are the sole proprietors of the curriculum. But, like most developers, I’m still a student of software myself – I spend every waking moment reading articles trying out new things and new technologies. It’s a hobby of mine, so that helps to keep the curriculum up to date as well.

We hear you’re moving the HTML/CSS curriculum to a pre-work module. Can you explain that change and what it means for incoming students?

Adding pre-work to the course actually solves a couple of problems for us. The first problem was that the course is only 11 weeks long, so we want to teach students as much information, exposure to new technologies, and best practices as possible. Over the last few cohorts, we’ve found that when we’re teaching HTML and CSS frameworks, half of our students have never seen those before, while the other half of students are yawning, bored, and wondering if they made the right choice to be here. This HTML/CSS pre-requisite solves the problem – everyone is starting class on the same page. That also means that we’re able to add more in-depth curriculum to the JavaScript course and the Rails course.

The other problem it solved was that our JavaScript course and Rails course never aligned properly. The Rails course is 11 weeks, five days a week, 9:30am to 5:30pm. Whereas the JavaScript course is only four days a week, 6pm to 9pm for 14 weeks. Because of this timing, our graduation days didn’t overlap, and there was a feeling of separation between the students in each course. By eliminating HTML and CSS from the curriculum, we were able to drop the JavaScript course down to 11 weeks, and lower the price, which got more people involved.

What do students actually need to know before Day One of class? How deep should they dive into HTML and CSS?

Students can go as deep into HTML and CSS as they want. We provide a lot of resources that cover the basics and go in depth. Our main expectation is that they come to class on the first day with a portfolio web page that is styled, has different aspects, links, tables, etc. We can get an idea of each student’s progress by checking out their portfolio page. Then, if we need to dive a bit further in, we can. Because we teach React at DevPoint Labs pretty heavily, we are using a ton of CSS and HTML every single day, so students are still reviewing those topics, it’s just baked into other subjects.

When do students start on the pre-work module?

After students are accepted into DevPoint Labs, we give them all the resources and exercises they should complete. Then we provide checkpoint quizzes, so we can see their progress as they are preparing to come to the course. We require that they score at least an 80% on the quizzes. If they aren’t meeting that requirement, that’s flagged, and we can bring this student in before the course starts to give them some tutoring help.

How long do students need to allow to complete that pre-work?

Ideally, it should take 3-4 weeks, part time. But we also know that we have students who sign up late and want to start a certain cohort, so we’ve had people come in with as little as one week of time to go through the prep work.

What exactly does the pre-work include?

There is a lot of stuff out there, whether it be Codecademy, or Code School. So we give them access to that. We point them to w3schools to get the basics. We use the Canvas learning management system at DevPoint Labs, where we have homegrown resources and guides that walk you through HTML, CSS, CSS frameworks. And then at the end of all the modules, there is a quiz they have to pass.

When students are going through that pre-work, are they learning on their own or will they have access to instructors and other students?

The idea is to learn on their own, but Jake and I are always available before and during the cohort, so they have direct access to communicate with us on Slack and by email. If a student is struggling with the curriculum, we’ll have them come into the classroom and schedule some mentoring time.

When did you implement this pre-work and how is it going so far?

Since the change, our first cohort is running now, and they are in Week 4 right now. I think the biggest unexpected change, was that students have a little more skin in the game coming in. They have to do all the pre-requisite work, and be comfortable with that without the help of an instructor which causes them to really dive in, and discover self-learning in software. Plus they come in more prepared and already understand how a web page is actually rendered.

Also, now that both the Rails and JavaScript programs are 11 weeks, we’ve lined up the curriculum so that we are teaching the same concepts at the same time (even though they’re learning different languages). And as a result of that, the Rails students and the JavaScript students are starting to work together – there is more camaraderie, more networking, more outreach. We’re starting to see JavaScript students meeting with Rails students outside of the course to work on things.

We have also now aligned both of our hackathons to be on the same two Saturdays, so students from both courses are working at the same time to build a project for eight hours and demo it at the end of the day. In future hackathons, maybe the students can work together on the same project – the Rails students will build out the API, and the JavaScript students build out a client, to simulate more of a real-world team scenario.

What specific additional material or skills will students be able to learn during the courses, now that you won’t be spending much time on HTML and CSS?

One thing that's really interesting, especially in JavaScript course, is the speed that this industry is moving at. In the JavaScript course, I completely revamp the curriculum every single cohort. For a language moving as fast as JavaScript, outside of the basics, there is no way that we can continue to teach the same curriculum cohort after cohort. This current cohort will be able to spend more time on state management libraries, like Redux and Mobex, and we can go into React Native for mobile – which wasn’t part of our basic curriculum before (it was an extra paid course). So next cohort, with the launch of React VR, we’re hoping to bring in Virtual Reality concepts, and some Internet of Things concepts, like programming Raspberry Pis.

How does DevPoint Labs decide which new technologies to add to the curriculum? What is the process for that?

It’s a chaotic process! I follow quite a few of my software heroes on Twitter, Reddit, and Instagram, so my ear is always to the ground. I speak at a lot of conferences, the Utah JS meetup, and other meetups, so I’m getting topics here and there. As these topics grow in popularity, I start to reach out to businesses in the area to see where the trends are going. I also do a lot of contracting work with startups and larger size companies, so I’m seeing trends in the real world as well.

We started to notice over the last six or seven months, a tendency for companies to move away from a full stack server-side framework like Ruby on Rails, into more of an API backend, Javascript-heavy front end. So with that information we revamped the Rails course to be more Javascript heavy.

How many instructors or TAs do you have at DevPoint Labs? And how do you make sure all of them are versed in the new technology you’re going to be teaching?

We have two instructors, myself and Jake Sorce. Then a full-time TA who is here all day, plus part-time TAs for every three students.

I think that keeping instructors and TAs updated is one of the biggest challenges. Especially right now, a lot of the new technologies we are teaching sprout from the JavaScript course. So I’ll introduce a topic in the JavaScript course, see how it goes, then build material around that, and once we have it solid, we’ll bring it into the Rails course. All of our teaching staff can sit in on any course they want. We encourage them to sit in on the JavaScript course, so most of them do that. Then once a week, Jake and I sit down with the TAs to talk about the topics coming up for the following week. If there are any gaps, we’ll set aside some time to bring the TAs up to speed.

How will these changes to the curriculum make students more marketable as developers when they graduate?

You can’t go out into the job market just knowing Ruby on Rails anymore. You have to have some heavier JavaScript background in today’s market. Where we were able to remove HTML and CSS, we now spend more time teaching students JavaScript and Javascript frameworks. Our Rails students are no longer just looking for Ruby on Rails jobs, and they feel confident in the job search because we are exposing them to a plethora of technologies, so they don’t feel pigeon-holed in one small portion of the industry.

With these new changes, what sort of roles will DevPoint Labs grads be prepared for?

In the majority of the jobs I’m seeing right now in Salt Lake City, employers are looking for client-side JavaScript developers. Historically, Ruby on Rails developers have spent a lot of time trying to avoid JavaScript, but that can’t happen anymore. Ever since Jake and I came into DevPoint Labs we’ve been gradually increasing our JavaScript load in the course, and we’ve seen students leave here with a lot more job opportunities, whether it’s an HTML/CSS job, or PHP, or WordPress – just having that extra time with JavaScript makes them much more marketable.

Is there any pre-requisite knowledge to go through the admissions process? What are you looking for in new candidates?

We don’t really care about technical skills. It’s easy for us to teach technical skills. Usually, we give candidates a quiz that’s not software related to look at how they think about a problem. Are they able to take a big problem, break it down into small chunks, and solve the small chunks until they can solve the bigger problem? The ideal student already has that mindset. That mindset is a lot harder to teach than the syntax for a programming language, or how to navigate around your terminal. We’ve had students start at DevPoint Labs with no technical skills. The only thing we do stress is that if your typing skills are low, we give you some extra material to get up to speed.

Our Admissions Director, MarkAnthony, does the initial interview with the candidate, getting to know them, and seeing what their scenario is. We like to take people on a case by case basis. Then they meet with our lead TA, who conducts the non-software related quiz. If he feels they are a good candidate, they will meet with me or Jake, and we’ll let them know, what to expect, how to prepare, how to succeed, and how to fail. We really stress if that if you follow a certain pattern, you will absolutely fail and waste your money. So candidates meet with at least three people before they are accepted.

What meetups or events can you recommend for people wanting to prepare for the DevPoint Labs pre-work?

There are not a lot of meetups geared towards HTML and CSS, but there is a big JavaScript community in Salt Lake City. UtahJS does two meetups on the same day – a learner’s meetup which then rolls into a more advanced meetup. Those learners meetups are typically people who are just barely learning how to code, so even though it’s not HTML and CSS, it can really help to get you in that mindset.

Is there anything else you’d like to add about DevPoint Labs, the pre-work or curriculum?

Right now, as far as my career, this has been the most exciting time to be a developer, just because of how fast things are changing, how many options are available to us as developers, and how these technologies are merging together, so our skills are starting to overlap. I think it’s really interesting to be able to teach new and innovative technologies because you’re still gaining a skillset that is backwards compatible.

Find out more and read DevPoint Labs reviews on Course Report. Check out the DevPoint Labs website.

About The Author

Imogen Crispe

Imogen Crispe

Imogen is a writer and content producer who loves exploring technology and education in her work. Her strong background in journalism, writing for newspapers and news websites, makes her a contributor with professionalism and integrity.

Also on Course Report

Get our FREE Ultimate Guide to Paying for a Bootcamp

By submitting this form, you agree to receive email marketing from Course Report.

Get Matched in Minutes

Just tell us who you are and what you’re searching for, we’ll handle the rest.

Match Me