Grace Teng

Advice for Le Wagon Web Dev Bootcamp grads

Dated: Mar 6, 2022

Congrats, you’re done with Le Wagon’s Web Development bootcamp. You have 360 hours of classroom time, three Rails applications, and zero professional software development experience. What’s next?

Le Wagon maintains its own career playbook, but depending on where you are and what your goals are, you may find yourself struggling to adapt its advice to your circumstances. I’m just one data point, but what I hope to do here is offer another perspective and perhaps a little direction as someone who was in your shoes not too long ago.

Can I really get a job?

Yes.

I had my own doubts after completing Le Wagon (batch #454), even though code came to me easily during the bootcamp. The doubt came from feeling that everyone who got a job must simply be “better” than me in some way, and that in order to get a developer job, I had to first learn more, practice more, etc. My way of fending off that uncertainty was to be a TA for the next full-time batch in Singapore, #512, and postpone the job search while I consolidated my skills. I don’t regret TA-ing at all, but my decision to TA was definitely rooted in fear of the unknown.

Miguel and Prima, my lead instructors, told me I had the chops to land a junior developer role, and I should go for it. In my mind, I discounted their enthusiasm because I thought, what else would they have said? However, the reality is, if you don’t apply for jobs, you truly have no idea where you stand in the job market. Once you start applying, you’ll get a better sense of what types of jobs are a good fit for bootcamp graduates, and how to best position yourself for them.

Part of the challenge in this job-hunting phase is that you will have to cast a wide net, and apply to jobs that use technologies outside of what you’ve used in Le Wagon. Some companies will be open to hiring juniors who are willing to learn the stack, while others will want you to have a base competency in the tech stack before hiring you. Some of the requirements are learnable within a relatively short time, while other competencies take longer. How can you determine which jobs you are suited for?

In my opinion, you can’t. My approach to job applications was essentially spray-and-pray. I’m ambivalent about this approach: it will be clear to many companies that you have no idea what you are signing up for (which is true), and it can be demoralising for you, the applicant. On the other hand, there will be places willing to hire a junior developer who is trainable. Unfortunately there is no way I know of to distinguish such organisations from the rest, short of applying to all of them and seeing what comes back.

The majority of places I applied to never replied, which is par for the course. I’ve had interviews that went really well, interviews that went nowhere, and one interview that went poorly. All of these interviews help you to learn about the tech job market, regardless of the interview outcome. The interview that didn’t work out sticks in my mind because even though it was a junior role, it required specialised technical knowledge that I simply did not have. The interviewer highlighted the total mismatch between my skillset and the job description, and estimated that it would take me six months of grunt work, reading and writing documentation, before I would be ready to make any code contribution.

On the one hand, I came out of that interview totally deflated. On the other, I learned a little bit more about an area of software development, and what would be expected of a software engineer in that domain, that I might not have otherwise.

With this information, you can start to develop an eye for what jobs you are more likely to be a candidate for, and to create a roadmap for professional development down the line.

How do I make myself competitive for developer positions?

As a career changer, you are not a blank slate.

You are likely to be applying to junior developer jobs, where your main competition is fresh university and polytechnic graduates. You have disadvantages, for sure: many of these graduates will have had a classical computer science education. Their CS knowledge is a known quantity to employers. It’s easy to feel that a nine-week bootcamp, or 24 weeks for part-timers, cannot possibly compare with a four-year degree.

On the other hand, you also have advantages that you can and should lean into:

Another thing to understand is that any employer that seriously considers hiring you is not hiring you on the basis of what you learnt in nine or 24 weeks, but on the basis of what you demonstrated.

This is an important distinction: you did not learn enough during the bootcamp to do your job. This is simply a fact: if everything a developer needed to know could be taught in nine weeks, the job market would look drastically different. Instead, what completing the bootcamp demonstrates is that you are trainable as a developer: you learned a tremendous amount in a compressed timeframe, you have the grit to work through things that are technically challenging, and now you have some foundation for learning everything else you need to learn on the job.

Performance expectations for junior developers typically revolve around attitude and ability to learn, not around the depth of your technical skills. This helps to reframe the problem: for jobs where you are a viable applicant, you are not competing against other applicants who know more than you do. You are being considered on the basis of your ability to learn, and that is something you definitely have.

Are my Le Wagon projects really good enough for a portfolio?

The time pressure of Demo Day forces many Le Wagon teams to focus only on features that will be demonstrated during Demo Day, and ignore any features or bugs outside of the demo’s path. It can end up being a very delicate operation: my team found a bug just before Demo Day that forced us to perform the checkout in a very specific order, for example. You may feel that your LW projects are not “ready” to be put into a portfolio that you can show to potential employers. That’s understandable.

In that case, what do you do with your projects? I can only really offer suggestions based on what I did, but hopefully you will find it useful as well.

The goal here is to show a baseline level of technical skill and an abundance of trainability. Instead of focusing on achieving an unrealistic level of polish in your LW projects, identify talking points around your projects and frame the project in terms of learning: what problems did you face while building this project? How did you work through these problems? What did you learn along the way? Put these talking points in your portfolio. This emphasises your ability to learn, and helps to contextualise the projects for potential employers.

Another thing I did is what I call the Redux option : identify 2-3 things that you didn’t get to finish for Demo Day, and complete them. These should be small tasks – fixing a known bug, making the app responsive, making it a simple progressive web app, adding error handling for a feature that only has its happy path completed. Then, if this is not a project you want to work on for the long term, stop here, accept that your early work is not going to be perfect, and move on.

You can see examples of how I wrote up my talking points and presented the Redux versions of my projects here:

What additional skills should I pick up?

I’m hesitant to answer this because it might fuel someone else’s imposter syndrome, but at the same time there are real gaps between what Le Wagon teaches and skills you really do need to know.

The first thing on the list is tests. The Le Wagon experience depends extensively on tests, at least until week 6 (for full-time) / week 15 or so (for part-time). By now you’re intimately familiar with how to interpret a failing rspec test. But can you write one?

If the answer is no, this is the first thing you should learn. There are two reasons for this:

  1. Everybody should be writing tests!
  2. Knowing how to write tests makes you more attractive to companies that care about testing, which are also companies that care about building good software, i.e. the companies you want to work for.

The second thing on the list of things to learn is JavaScript. Yes, you learnt five days’ worth of ES6, and then avoided it as much as possible during the projects because you didn’t understand any of it. I know. I understand the reason Le Wagon’s curriculum is built the way it is, and I don’t think I would take out something else to put in more JavaScript.

However, the JS covered in the bootcamp is grossly insufficient, especially if you want to pursue front-end or even generalist full-stack development. At a minimum, I would urge you to watch Codesmith’s videos on Promises, Async and the Event Loop. You must understand how frontend API calls really work, instead of copying the fetch(url).then(response => response.json).then(data => { // do stuff }) magic incantation from Kitt every time you need it. Better still, go through Codesmith’s CSX course, which mimics the style and content of what you learn in Le Wagon for Ruby, except this time in ES6.

From here, there are not as many hard-and-fast rules. I think many Wagoners would say to learn React , and I definitely think React is a good choice – but I actually don’t know if I consider it strictly necessary unless you definitely want to do frontend work. In my opinion, React is useful to learn because it gives you a mental model that is very different from Rails, and that you can then use as the starting point for learning other things. The course I typically recommend is Brian Holt’s Complete Intro to React v6 (if v7 is out by the time you read this, search for that instead).

Two more things I would add to this list are a high-level understanding of infrastructure and networking. You don’t need to understand the details at this stage, but you should understand how exactly a web application lives on a computer somewhere and how users somehow get that application delivered to their web browser.

Infrastructure and networking aren’t necessarily something that will come up at the job interview stage for a junior developer, but it makes your life as a developer vastly easier if you have a mental model and a vocabulary for talking about infrastructure and networking to your colleagues once you’re on the job.

How do I keep learning when I can’t raise any more tickets?

This is not an original visualisation:

Image: Three concentric circles. The innermost circle is labelled "Comfort", the middle circle is labelled "Learning", and the outermost circle is labelled "Panic". Three concentric circles. The innermost circle is labelled “Comfort”, the middle circle is labelled “Learning”, and the outermost circle is labelled “Panic”.

You’ve developed some familiarity with Rails, and a mental model of what software development looks like. That’s your comfort zone.

Outside of your comfort zone, there’s a zone of proximal development, or a learning zone. This is where you can learn something new if you can relate it to something you already know: you can read a tutorial and learn by analogy based on what you already know, or you can watch a video and follow along reasonably well. You want to stay in this zone as much as you can.

The great beyond is the panic zone : when you’re confronted with something so new, you don’t have a frame of reference at all. You want to stay out of this zone: spending too much time here makes you feel dumb and demoralised.

Over time, things that were formerly in your learning zone become your comfort zone, and the comfort zone circle expands. Things that were formerly in your panic zone start to come into your learning zone.

If you find yourself panicking when faced with something you don’t understand, take a step back, and see if there’s a way you can connect it with something you know, and build up to it that way. If there isn’t, there’s no shame in accepting that you’re not ready for it yet, and finding something else that does fall within your learning zone. Eventually, you’ll learn something that allows you to bridge that gap.

What should I consider when deciding on my first software development job?

My answer is going to be heavily biased by my experiences at Thoughtworks, which has been an excellent place for me to start my software development career. You should definitely talk to other alumni and other software developers, who will probably give you a variety of responses that you can consider in your decision-making.

In my opinion, the first thing you should look for is availability of mentorship : specifically, what support do junior developers get to develop their technical skills?

This can take many forms: a company may highlight its L&D budget, or give you access to many learning resources on Udemy, O’Reilly, or whatever its learning platform of choice is. The thing I would ask about, though, is what kind of technical feedback you can expect : do senior developers actively mentor juniors and give feedback on their code? If you’re unsure about something, can you get an extra set of eyes on it to verify you’re on the right track, or will you be left to your own devices? Feedback is critical to learning, and without feedback, it will be challenging to gain confidence in your skills as a developer.

The next thing I would look for is the quality of software engineering practices in the team or in the organisation:

On the last point: note that the frequency of code deployment is often a business decision, not an engineering decision. An engineering team may be capable of deploying often, but the decision to deploy a new release involves a lot of other teams as well (product, marketing, CX, etc.), so the actual deployment frequency doesn’t matter as much. What matters is whether the team can deploy at short notice if they have to.

Other things to consider that will impact your job satisfaction, but that don’t necessarily reflect a company’s engineering quality, are:

I think these axes are mostly about preferences, and the right choice is whichever makes you happier. At the same time, it’s worth thinking about what is negotiable and what is not, and staying open to new experiences: I thought I would dislike how much pair programming happens at Thoughtworks, but over time I’ve come to really appreciate how much I learn through pairing.

What about the tech stack?

I personally don’t think the tech stack matters that much in your first software development role. You can definitely lean towards companies that use Rails or Ruby as a core part of their stack, and you should probably stay away from overly esoteric tech stacks for a first job. That’s about it.

Restricting your job search to only Rails is unnecessary: most of your Rails backend knowledge is readily transferable to Django, Express, Spring Boot, etc as long as you put in the work. Most employers who will consider a bootcamp candidate will be aware of this and give you some time to learn the stack. The cost of learning a specific stack is just not that high compared to the cost of hiring a weaker employee, so if you are an otherwise strong candidate for the job, the tech stack is unlikely to be the differentiating factor.

Erring in the other direction and being too open to esoteric stacks is a bigger risk, in my opinion. For a first job, you don’t want to become pigeonholed into a niche. Early in your software development career, you should aim to stay in the broad middle of the tech landscape, using more common frameworks and technologies.

To get a sense of how popular a given technology is, you can look at the Technology section of the annual Stack Overflow survey. If the main components of a company’s tech stack are not on the “Most Popular” list, or are very low on the “Most Popular” list and are at the bottom of the “Most Dreaded” list, I would probably not choose that company unless there were other very strong reasons to do so.

When will I learn enough?

I hope it doesn’t surprise you that the answer is “never”.

The world of web development is vast, and the wider world of software engineering even vaster still. Le Wagon teaches you two things:

The first skill is your launchpad, but that second skill is the real fuel that will maintain the trajectory of your software development career. Every time you are asked to do something you have not done before, it will be bootcamp all over again: looking up resources, experimenting, debugging, and expanding your comfort zone to be a little bit bigger than it was when you woke up in the morning.