Finding a Junior Dev Job: Optimizing Your LinkedIn Profile

Helping our students find great jobs is a huge part of what we do at Epicodus. In fact, it’s our mission. Over the years, we’ve accrued quite a bit of job-hunting knowledge to help set our students apart. In the next few weeks, we’ll be sharing our best tips and tricks for junior developers who are looking for their first jobs.

If you don't already have an up-to-date, professional-looking resume, start by making a LinkedIn profile, which you can later be used to generate a resume. Many employers will even ask for your LinkedIn profile in lieu of a resume. For most people, we suggest you organize your LinkedIn profile as follows:

• Include a recent photo.
• Edit your tagline to something like "Junior web developer", or something similar.
• Create a friendly URL including your name.
• Write a short summary of what you're doing now (learning to code) and why you decided to become a developer. Keep it under five sentences.
• Add a link to your Github profile (and optionally your website) to your summary. The link will show up as a large box, this is OK.
• Move the Projects section just below your summary. Add some projects that you've completed to this section. Include links to the Github code for the project or a live site on Heroku, Github Pages, or another hosting option, if possible. Talk about what the projects do and what technologies were used.
• Next, list your previous jobs under Experience, with a short description of what you did at each role. Be specific and succinct - use concrete numbers and examples, like "Responsible for on-boarding and training two dozen new employees in 3 months", rather than vague statements, like "Fulfilled management duties beyond expectations." If you have more than 3 or 4 previous jobs, just include the most recent ones (unless earlier ones are relevant to the jobs you're applying for).
• Break down past experience descriptions into bullet points. You can easily do this by using the Alt-8 shortcut.
• If you're an Epicodus student, add Epicodus to your Education section, and move that section directly after your Experience section. Write a brief summary of what you're learning and doing at Epicodus. Don't write about what Epicodus is - write about your experience. For example, one student wrote "I'm currently learning how to build web applications with JavaScript, Ruby/Rails, HTML, and CSS. More importantly, I'm learning how to think more like a programmer, write good code, and pick up new languages and technologies." Another wrote: "At Epicodus I've learned how to learn programming languages more than learning any one language for the sake of itself. I've learned how to work towards a programming goal on my own and with others until success happens. I've also learned how quickly I can process a tremendous amount of information that is new and uncomfortable at first, and have it feel comfortable like a worn pair of jeans by the end of a week!" Don't copy these examples - come up with your own that describes your own unique experience.
• In the Skills section, list skills you've learned, like HTML, CSS, JavaScript, jQuery, Ruby, SQL, Ruby on Rails, AJAX, Git, TDD, pair programming, and more that are specific to your own course track.

What Programming Language Should I Learn?

By Michael Kaiser-Nyman

Now that Epicodus offers so many different courses, we often get students unsure of what to take after they finish Introduction to Programming. If you're an Epicodus student or anybody wondering which language to learn, the first thing you need to decide is if you want to focus more on front-end or back-end development. Front-end developers spend their time making things look and work well, obsessing over layouts, navigation, colors, and design. If this type of work appeals to you, your best bet is to take CSS and Design classes at Epicodus.

If you're more interested in back-end development, you have several choices of languages: C#, Java, PHP, and Ruby are all offered at Epicodus. My best advice about how to choose is not to worry too much. Most modern programming languages have more similarities than differences, and Epicodus graduates often find themselves working in different languages than they studied in school. Back-end programmers often switch languages as they change jobs, or even as they build different types of software at the same job. So don't stress too much about making the right choice! That said, each language has found a bit of a niche, and depending on your interests, you might be attracted to one over another.

C#

C# is most popular among bigger established businesses, often for building internal software. Because it's been around for a long time and has the backing of Microsoft, it is one of the most in-demand languages in the job market. C# has also been going through a bit of a rebirth lately, with Microsoft open sourcing the language and surrounding platform, porting it to run on Mac and Linux, and incorporating many of the best features of other languages. If you like the idea of working for a larger company on business software, C# is a great choice.

Java

Java is also a favorite of enterprise companies, but its appeal is broader as well: it's one of the most popular of all programming languages, and it's used in everything from for high-performance processing to building Android user interfaces. Because Java has been very popular for a very long time and is used in so many applications, it is also a very high-demand language. If you're interested in working for an enterprise-level company, as an Android developer, or in high-performance applications, Java could be a good language to learn.

PHP

PHP is by far the most popular backend language today, with 80 percent of websites utilizing it 'server-side'. It is perhaps best known for it's use in content management systems like Wordpress, Drupal, and Joomla. But the versatility of the language and the frameworks it powers make employment options numerous and diverse. If you're keen to work for a fast paced agency that builds websites for lots of clients, or maintain the security and stability of a huge complex of government websites, or if you like the idea of building out small sites for brands, businesses, and organizations - In any of these cases, PHP would be a great way to go.

Ruby

Ruby is a favorite language of developers building interactive web applications. If an app involves users creating accounts, entering information, and interacting with dynamic content, there's a good chance it is built with Ruby. Ruby became popular because the Rails framework, which is written with Ruby, simplified many of the common tasks associated with building web applications. It's most popular with startups and smaller companies who are looking to build their product quickly.

Though each language has its niche, there is plenty of crossover. For example, Rails' popularity inspired copycats in just about every language, and so you'll see interactive web applications written in C#, Java, and PHP, with Rails-like frameworks including .NET MVC, Spring, and Laravel. Even at one company, you might find them using PHP for their marketing site, Ruby for their web application, and Java for their back-end processing. 

The most important thing is to get the basic principles of coding down, practice a lot, and be ready to change to another language when your job inevitably does.

Why We Shouldn't Make Kids Learn to Code

By Michael Kaiser-Nyman

As our society grows increasingly aware of the power of computer programming, both to shape how our world works and provide high-demand jobs, some people have suggested that we require all children to learn how to code. I think this is a terrible idea. Here's why.

When I was a kid, I became interested in programming, and I was lucky enough to have parents who helped sign me up for community college classes. In an era when coding has become such an important skill, it would be absurd to require kids to navigate the community college system if they're interested in learning to code, and despite this post's title, I'm all for offering courses in our K-12 education system. But I also strongly believe in the importance of letting kids choose if and when they want to learn programming. When my interest waned as a teenager, my parents didn't pressure me to continue coding, and I think that's part of why I ended up becoming a successful developer - I had the freedom to pursue it when I wanted to and when I was ready. Forcing all kids to learn to code risks killing the joy of it for those who would otherwise come to love programming, and turning it into yet another test to take for those who never had any interest in the first place.

Furthermore, the focus on teaching kids to code is misplaced: the most important skills our education system can provide to children have nothing to do with software or technology. When I started Epicodus, before I ever wrote a single word of curriculum, I asked many programmers and hiring managers what Epicodus should teach. I was shocked: people talked very little about languages or design patterns or technologies. Instead, I heard about teamwork, self-awareness, communication, and humility. "Sure, that's fine," I would say, "but what about the coding skills? Isn't that the important thing here?" The resounding answer I received was "no". Across the board, employers told me that they needed a certain baseline level of skills to hire somebody, of course, but so long as somebody had that baseline, their so-called "soft skills" were far more important. One developer told me something along the lines of: "I can teach a junior developer the coding skills they need to solve the problem at hand, but I can't teach the curiosity they need to solve the next problem without my help." Another told me "The greatest risk to a software company isn't their code, but how their employees work together."

At Epicodus, we try to foster soft skills like communication, teamwork, and curiosity. But the best time to develop these skills is as children. People can learn to code as adults - I see it happen every day. Their gains in soft skills are smaller and come more slowly, though. It would be great if every child had the opportunity to learn to code, but it would be far better if every child graduated high school excited to learn and explore, effective communicators, and adept at resolving conflict with their peers. Even if they had these skills and had never seen a line of code before, they'd likely turn out more successful than a programming whiz coming out of the average American high school today.

There are many great reasons to encourage kids to learn to code: it sets them up with a vocational skill, it helps them understand how our technology-driven world works, and it develops their problem-solving and logical abilities. But not every person wants or needs to learn to code, and even those who do can be successful learning as adults. The interest in coding in K-12 education is misplaced. It's far more important that we re-tool our education system to give kids more opportunities to develop teamwork experience, communication skills, and curiosity to become lifelong learners.

Aptitude, Attitude, and Experience

By Michael Kaiser-Nyman, Epicodus President

Over the years of teaching people to code, I often get asked what kinds of people make good programmers, or how to know if somebody's cut out to be a developer. I've certainly noticed that some people have natural talent for coding and can pick it up remarkably quickly, but I'm also convinced that it's much less important than many people think.

There are three things I've seen that determine how quickly someone can pick up coding: aptitude, attitude, and experience. Aptitude is someone's natural, unearned talent. Attitude is the way someone approaches learning to code. And experience is simply how much time they've already spent learning how to code.

Aptitude is of course important, but for most people, their attitude and experience have a much greater impact on their learning curve. Someone who can stay positive while pushing through frustration is going to learn more quickly than another person who gets discouraged. Someone who isn't afraid of learning from their mistakes will figure things out faster than another who is scared of messing up. Someone who can slow down and pay attention to the details will succeed more quickly than someone who tries to blaze through problems without really understanding what's going on.

And besides your attitude, there's just no substitute for experience. What looks like wizardry to someone who's been coding for a month often feels like boilerplate to someone with just a few more weeks of experience. And just as importantly as actual coding knowledge, most developers build good attitudes as they gain experience.

If you're a new programmer, my advice is to not worry about your aptitude - there's nothing you can do about it. Far more important is the way you approach your learning, and the amount of time you spend. Cultivate healthy attitudes, be patient with yourself, and spend lots of time coding. For most people, attitude and experience are far more important than whatever natural skills you were born with.

The Myth of the Best Programming Language

By Michael Kaiser-Nyman, Epicodus President

As an aspiring programmer, it can be hard to know what programming language to learn. You'll often hear hyperbole like "In the future, everything will be written in JavaScript," or "Ruby is the most elegant language." Programmers you meet may warn you against languages they don't like, and you'll come across stories in the tech media about how some language or technology or tool is making everything else obsolete.

My advice to you is: Don't worry - just code.

Most programming languages have more similarities than differences. No matter what language you learn first, you'll need to begin by mastering the concepts of variables, branching, and looping. Most languages use similar patterns of code organization (primarily based around object-oriented design). There are variations in the syntax, structure, and tools, but by and large, programming languages have far more in common than they have differences, especially among the languages commonly used in web and mobile development.

This point really came home to me the other day, when I was chatting with an experienced developer who has worked with many languages over the years. He told me a story of joining a new team that used a language he had never used before. A junior programmer needed help with a problem, and even though the junior had more experience with the team's language, my friend immediately knew that the language probably had a tool to solve the problem at hand. He told the junior where she could probably find it, and sure enough, the junior was able to use it to solve her issue.

When I first learned to code, I agonized over what language I should learn. I started on one language, got stuck, tried another one, heard that it wasn't a good language, went back to the first, got frustrated, and so on. Sometimes it seemed like I spent as much time trying to figure out what language to learn as I did actually coding. In hindsight, I realize that no matter what language I tried, I was going to have a tough time, simply because the basic principles underlying all languages are all difficult to understand at first.

So if you're just starting out, I suggest you aspire to be like my friend the experienced developer. Instead of getting caught up on which language to start out with, just dive in. If you come to Epicodus, you'll be required to learn at least two languages before graduating, but I'd encourage you to learn even more if possible. Every language has its place, and many of the "unhip" languages like C# and Java are actually in higher demand in the job market. The more languages you know, the easier it is to pick up new concepts, dive into new projects, and, of course, get a job.

Why We Pair Progam at Epicodus

One of the most unique aspects of how the Epicodus classroom works is that our students practice pair programming, where two people use the same computer at the same time. One person drives, controlling the keyboard and mouse, and the other person watches and talks. Typically, students are pairing with a different partner each day.

Why is this practice beneficial? We’ve found that there are several reasons why pair programming can be more effective than soloing:

Programming is less about writing massive amounts of code and more about solving difficult problems. When two people solve a problem together, they often come up with better solutions, more quickly than each working alone.

Usually, each person in a pair will have different sets of knowledge and different strengths. Pairing allows you to learn from each other.

When you work alone, you’re often tempted to take shortcuts that will come back to haunt you - such as writing code without tests. When pairing, you can hold each other accountable to writing high quality code.

When you watch somebody else code, it’s easier for you to see their mistake and catch their bugs than for them to see their own.

You don’t check your email, social networks, news, text messages, and so on when you’re pairing; as a result, you’re much more productive.

Even though pairing has many advantages, it can still be frustrating. You’ll usually be working with someone who is either more or less experienced than you, and you’ll often feel like you’re slowing down your pair, or they’re slowing you down. You might want to explore how something works, while your pair wants to focus on actually finishing the project at hand. Or, you’ll run into a nasty bug, and you’ll have different ideas about the right way to try to fix it.

Every day at Epicodus, before students start programming, we ask pairs to check in with each other. The pairs discuss what each of their personal goals is for the day or the lesson, they share their strengths and weaknesses (both in programming and in pairing), and they talk about what they need for a happy and safe work environment. At the end of the day, the pairs ask each other for feedback on how the day went.

Pairing is challenging because each student is bringing a different set of experiences, interests, and backgrounds into the classroom, not to mention different communication and learning styles. In the long run, embracing those differences helps to enhance learning capacity and problem solving skills, creating more well-rounded programmers. 

Encouraging the Growth Mindset

Mindsets can be taught; they’re malleable.

Now that we’ve kicked off our final four classes of 2015, we wanted to share one of the philosophies that runs throughout our courses: the growth mindset. At the start of each class we have all of our students read this excellent article from Khan Academy founder, Salman Khan, which lays down several of the key tenets of developing a growth mindset.

The brain is like a muscle; the more you use it, the more it grows.

Researchers found that people adhere to one of two mindsets: fixed or growth. Those with fixed mindsets (mistakenly) believe that people are either smart or not, and that intelligence is dictated by genes. But people with growth mindsets believe that intelligence can be grown through struggle, effort, and failure.

Our intelligence is not fixed, and the best way that we can grow our intelligence is to embrace tasks where we might struggle and fail. 

People come to Epicodus with a wide range of experience in and natural aptitude for programming. The most successful students, however, are the ones that embrace the growth mindset and know that when they struggle, their learning capacity grows. Our teachers at Epicodus help all our students develop a growth mindset, and encourage students to help their peers develop growth mindsets as well. 
 

How to Ask for Help When Programming

One of the most unique aspects of Epicodus is our teaching style. The school uses the flipped classroom model, which means that we don't have lectures or lightning talks. Students are pair programming for the entire time that they are in the classroom. Our teachers walk around the classroom and help when needed, but we really encourage our students to learn from each other and ask their peers for help before going to a teacher.

Asking for help can be difficult, so we always share the following suggestions with our students before they start class:

1. Do your own research. Go through all of the steps on the debugging lessons before asking for help. Re-read/watch the relevant lessons on the site. Search online to see if you can find anybody else who had the same problem you did.
2. Have your problem as close to being fixed as you know how. Often, when something isn't going right, you try a lot of different things to see what works, including things you think won't work but want to try out. Before you ask someone for help, get you project back to the state that you think is the closest to working.
3. Demonstrate the problem. It can be tempting to show the person helping you the problematic code and explain all the things you tried, but without the context of seeing what's going wrong, it will be hard to understand what you're talking about. Demonstrate the bug, show the part of the program you can't figure out how to make work, and pull up the error message.
4. Narrow down the problem. Show which part of the code you think is the culprit. Explain why you think your code in the present state should work, and any ideas you have about why it doesn't.
5. Share your hypotheses. Often, you'll have some ideas about what's going wrong based on your understanding and clues from your research. Share these with the person helping you, as they may not be immediately obvious.

Why Java?

A few applicants have asked about our upcoming Java/JavaScript/Android class, wondering about job prospects after the class. First of all, we're strong believers in teaching students multiple languages (all of our classes cover at least two), so that graduates can feel comfortable picking up new languages on the job. In fact, many of our alumni work in different languages than the ones they studied at Epicodus.

That said, it does make things easier if you know the language of your job, and Java developers are in very high demand right now. Many Epicodus graduates already work at companies that use Java heavily, like Intel, Nike, and New Relic, and many more companies around Portland have told us they'd be eager to hire graduates trained in Java.

On top of the high demand for Java skills, the market for Android development has been exploding in recent years, and Android apps are written in Java. Since one of our classes focuses on web applications (with Rails) and one on content-heavy web sites (with Drupal), adding a mobile-focused class with Android fits in nicely with our current offerings. 

This year marks Java's 20th birthday, and it is still one of the most popular programming languages. We're excited to join the Java community and help fill its need for more developers!

How to Start a Coding School

I regularly hear from people who are interested in starting a coding school and want to learn more about my experience starting Epicodus, so I thought I'd jot down a bit about our history, what's worked well (and not), and advice I have for other people.

Before the first Epicodus class, I did a lot of networking to find out what companies were looking for in junior developers. I made sure that there was actually a market for the students I was going to teach, and learned about what companies value in junior developers. What I heard more than anything else was that specific languages and technologies were less important than a hunger to keep learning and an attitude of humility. And while there were many companies who weren't sure that graduates of a program like Epicodus would be a good fit for them, there were just as many who were very excited about hiring junior developers.

Next, I turned to the student side of things. I volunteered at local meetups and events for beginner programmers to see how other people were teaching beginners. I also went through many books, videos, and tutorials myself. At the in-person events, I watched the students learn to see which lessons and approaches were effective, and which didn't work as well. After getting some experience, I assembled my own lessons and put on several free evening workshops to get more experience teaching and running classes, and saw how I could make my lessons better. I asked for a lot of feedback from the workshop participants.

At that point, I felt ready to run my first Epicodus class. I spent a couple months getting the curriculum ready and promoting the class: I announced at local meetups, emailed local tech mailing lists, posted on online forums, and listed our classes on several websites for coding schools. I rented a room in a local co-working space, and bought computers and furniture. 

I knew that teaching staff would be my biggest cost and potentially very hard to hire, so I decided to try an unusual approach to structuring Epicodus's classroom. Instead of giving lectures in class, I completely embraced the flipped-classroom model and put all of the lessons online for my students. In class, students would just work on coding projects all day. I figured that way, I wouldn't need to hire experts to teach my classes: instead, I could just hire strong graduates to help out the next batch of students, and the lessons, which need more experience and expertise to make, would already be ready to go. Additionally, I had all of the students pair-program in class, as I had seen that two people working together learn from each other and need less help from teachers, and that would help keep the number of teachers we needed down.

I learned an awful lot of the first class. The first thing I realized was that I was totally off-base on my student to teacher ratio. With the way I had structured the classroom, I had nothing to do most of the time! Another important lesson I learned was that after the class was over, many of the graduates had a hard time structuring their job search. Finally, I discovered that there was a lot of demand for other languages than the one I taught initially - it turned out that the choice of language was more important than I had though. So for the next class, I tripled the number of students to 24, incorporated job search prep into the curriculum, followed up with all of the graduates regularly until they found jobs, and expanded our curriculum to cover two languages.

For the third class, I hired two teachers and increased the class size to 60. That 1 teacher to 30 student ratio turned out to be a good sweet spot. It also let me focus on the employment side of things, which I wanted to continue improving. We created an internship program with local companies to help our students get real-world experience before graduating, and instituted a more formal resume and cover letter review and mock interview process. We also started working on adding classes in other languages.

Since then, we've continued to grow, add staff, and improve. Every day, we challenge ourselves to make our classes and career services better, and we constantly ask our students for feedback so we know how we're doing. 

For people thinking about starting a school like Epicodus, here are a few things I'd suggest:

• If possible, start the school with two people. Have one person focus on the classroom, and one focus on everything else (admissions, career services, administration, etc).
• Talk to local employers and learn what languages are in high demand. 
• Utilize the flipped classroom structure by building out all of the lessons as evening/weekend homework, and use the class time just for coding. Feel free to use Epicodus's materials at learnhowtoprogram.com. 
• Provide a lot of structure and support for job-seeking, starting before students graduate.
• Ask your students for lots and lots of feedback.
• Little things: incorporate your company, get a business bank account, buy standing tables from MultiTable with Ikea tops, use 27" iMacs (no reason to skimp on computers - it's way easier for pairing and for teachers to help out, and over the course of the computers' lives the difference in cost is negligible), and take advantage of all of the operations and software tools Epicodus has open-sourced.

If you find this helpful in opening a school, drop us a line and let us know!