When am I ready to go job hunting?

Each business likes to do things a certain way and expect that new hires will not know every skill needed. Two things that will help you stand out are:

• To be able to show that you can learn and implement a new skill within a reasonable amount of time
• That you have a general understanding of programming structure, methodology, and standards

Lastly, go to an interview with a learning mindset and ask questions. Someone performing an interviewing is trying to gauge if you have the proper skill set to perform the job. They can tell you what you are lacking, so ask them and work on those skills.

Hey Jon,

I actually work at a web development agency where we segment our team into web designers, front-end developers and back-end developers. Every business place has a different definition of what these roles entail and sometimes the line between one and another can be blurry, but I've found that the way we segment these roles at my agency is pretty standard. It's typically segmented in by design, client-side code and server-side code. To explain how they differ, I think it makes more sense to describe the typical agency process:

First, you start out making a design. This is the role of the WEB DESIGNER. He will typically work mostly in Illustrator and Photoshop making mockups of the site and often will go as far as writing the initial HTML and CSS for the site. Again, the extent to which a web designer will get into coding varies, but they are mostly in charge of the aesthetic look of the site and the layout of the site's components.

After the design is pretty fleshed out, it goes to the FRONT-END WEB DEVELOPER. Front-end developers typically work with HTML/CSS and are in charge of all the client-side programming. That is, JavaScript, jQuery and any front-end library that the site may require. In my agency in particular, the Web Designer will hand off a few coded-out page templates to our front-end developer that only include the basic design and no interactive features. For instance, the site may have an image slider, a gallery that will open modal previews, forms with interactive features, etc. The web designer will hand off a static page that has all of these elements in place and mostly designed all the way through, but none of it actually works yet. The slider doesn't actually slide through, the images in the gallery don't do anything when clicked and the form doesn't do anything. The front-end developer will then write all the jQuery and whatever else he needs to use to make these elements actually work. They'll also add animations to the site for transitions and whatever interactive "bling" the site needs. They'll mostly use CSS transitions and jQuery for this.

Lastly, this working template is handed off to the BACK-END DEVELOPER. This person is in charge of all the server-side programming. That is, PHP, Ruby On Rails or whatever the project may require. This guy will code out the CMS (like WordPress) and pretty much add all the functionality that will require the site to communicate with a server. For instance, they'll add the functionality that will make the form that the designer and front-end dev made actually send emails back and forth, maybe they'll add functionality that will allow the site to fetch images for the gallery from a social media site, and create any of the other data-drive functionality that has to do with JASON, AJAX or XML being fetched or sent out. They'll also deal with all the functionality like storing and handling data for users (such as passwords or profile information) and do also manage all the database stuff.

Again this is the most common segmentation of these three areas, but they are not always this cut-and-dry in the real world. In reality, the process is rarely that ordered. A site will go back in forth between these people and they work on stuff simultaneously pretty often. Smaller places will sometimes join two of the roles into one, or sometimes have one person do everything. Sometimes designers only make static mockups in Illustrator/Photoshop and never write a single piece of code. Other times, they don't even use those and go straight to prototyping in HTML and CSS. It all really depends on the particular process of the agency or business place, but overall, when people refer to any of those roles, I think what I explained is the standard segmenting of those roles.

As for what they expect, I think it also depends on the size of the team and the role you're going for. The smaller the team, the less specific they will be about what they require you to know. If you're applying for a job as a back-end developer on a medium to large team (about 5+), they'll usually expect you to know a lot of MySQL, PHP and other server-side jazz, and they probably won't care if you're a terrible designer. Also on a larger team applying for a web designer role, they will probably only need you to know HTML/CSS and JavaScript and just a very basic understanding of the other roles. They'll mostly care to see that you can make some really nice looking stuff and understand UI/UX well. On a smaller place, you'll mostly need to have more all-around knowledge, but in my experience smaller places are usually much less likely to know exactly what they need and will often have a much less specific definition of each of these roles. This could be a good thing or a bad thing. Make sure you know what you're getting yourself into before you accept a role that's not well defined. It might give you flexibility to do more of what you already know, but make sure they didn't hire you as a "web designer" and suddenly expect you to build a system that requires you to get crazy with databases and servers.