Are you interested in becoming a Google Cloud Platform certified professional?

Last year, I took five out of the seven (at the time of this writing) of the GCP professional exams:

• Professional Cloud Architect
• Professional Data Engineer
• Professional Cloud Security Engineer
• Professional Cloud Network Engineer
• Professional Cloud Developer

In this post, I'll share some information about the exams, my strategies for passing them, as well as a link to the study guides I created along the way. These guides have been battle tested by more than a hundred professionals (so far) who successfully got certified with their help.

About the certification exams

Professional Cloud Architect

Professional Cloud Architect certification logo

• Length: 2 hours
• Registration fee: $200 (plus tax where applicable)
• Languages: English, Japanese.
• Exam format: Multiple choice and multiple select, taken remotely or in person at a test enter. Locate a test center near you.
• Exam Delivery Method:
  • Take the online-proctored exam from a remote location, review the online testing requirements.
  • Take the onsite-proctored exam at a testing center, locate a test center near you.
• Prerequisites: None
• Recommended experience: 3+ years of industry experience including 1+ years designing and managing solutions using GCP.

Reference: https://cloud.google.com/certification/cloud-architect

Professional Data Engineer

Professional Data Engineer certification logo

• Length: 2 hours
• Registration fee: $200 (plus tax where applicable)
• Languages: English, Japanese.
• Exam format: Multiple choice and multiple select taken remotely or in person at a test center. Locate a test center near you.
• Exam Delivery Method:
  • Take the online-proctored exam from a remote location, review the online testing requirements.
  • Take the onsite-proctored exam at a testing center, Locate a test center near you.
• Prerequisites: None
• Recommended experience: 3+ years of industry experience including 1+ years designing and managing solutions using GCP.

Reference: https://cloud.google.com/certification/data-engineer

Professional Cloud Security Engineer

Professional Cloud Security Engineer certification logo

• Length: 2 hours
• Registration fee: $200 (plus tax where applicable)
• Languages: English.
  Exam format: Multiple choice and multiple select, taken in person at a test center. Locate a test center near you.
• Prerequisites: None
• Recommended experience: 3+ years of industry experience including 1+ years designing and managing solutions using GCP.

Reference: https://cloud.google.com/certification/cloud-security-engineer

Professional Cloud Network Engineer

Professional Cloud Network Engineer certification logo

• Length: 2 hours
• Registration fee: $200 (plus tax where applicable)
• Languages: English.
• Exam format: Multiple choice and multiple select, taken in person at a test center. Locate a test center near you.
• Prerequisites: None
• Recommended experience: 3+ years of industry experience including 1+ years designing and managing solutions using GCP.

Reference: https://cloud.google.com/certification/cloud-network-engineer

Professional Cloud Developer

Professional Cloud Developer certification logo

Honestly, this one caught me by surprise. Back in December 2019, when I took the exam, there wasn't anything saying it was in beta. By that time, this was the information available at the exam page:

• Length: 2 hours
• Registration fee: $200 (plus tax where applicable)
• Languages: English, Japanese.
• Exam format: Multiple choice and multiple select, taken in person at a test center. Locate a test center near you.
• Prerequisites: None
• Recommended experience: 3+ years of industry experience including 1+ years designing and managing solutions using GCP.

At the time of this writing, though, the information available on the exam page is very different, as you can see below:

Beta certification exams are newly developed assessments. We gather performance statistics on the questions and use these statistics to create the certification standards for the final exams. If you pass, you are Google Cloud Certified.

• Save 40% on the cost of certification
• Prove early adoption by claiming a low certificate number if you pass
• Get exclusive Google-branded apparel
• Refer to our FAQs for more details

Specifics about the beta

• Length: 4 hours
• Registration fee: $120 USD (40% discount on retail price of $200 USD) (plus tax where applicable)
• Languages: English.
• Exam format: Multiple choice and multiple select, taken in person at a test center. Locate a test center near you.
• Prerequisites: None
• Recommended experience: 3+ years of industry experience including 1+ years designing and managing solutions using GCP.
• Beta exam preparation resources:
• To take the upcoming beta exam, use the revised exam guide.

Reference: https://cloud.google.com/certification/cloud-developer

The Preparation Process

Now that you have all the basic information about the exams, it's time to study and get ready to pass them. My preparation process for the five exams I took involved the following steps:

1. Read the exam overviews:
   • Professional Cloud Architect exam overview
   • Professional Data Engineer exam overview
   • Professional Cloud Security Engineer exam overview
   • Professional Cloud Network Engineer exam overview
   • Professional Cloud Developer exam overview

2. Read the exam guides:
   • Professional Cloud Architect exam guide
   • Professional Data Engineer exam guide
   • Professional Cloud Security Engineer exam guide
   • Professional Cloud Network Engineer exam guide
   • Professional Cloud Developer exam guide

3. Next, visit the products page of the platform and identify each product that may be related to the topics listed on the exam guides. For GCP, you can find this list here.

4. For each of the products identified in the prior step, visit its Documentation/Concepts page and start reading about each of the concepts that are relevant for the given product. Check the GCE concepts page, for example.

5. You’ll probably notice some products seem to overlap with each other, and you might find it difficult to know when to use one or the other. Google Search is your best friend here. :)

6. For the Cloud Architect exam, after going through each product and its concepts, read the sample study cases provided by Google and try to design potential solutions that could address the requirements described on them.
   • Mountkirk games study case
   • Dress4Win study case
   • TerramEarth study case

For the Data Engineer exam, the sample study cases have been recently removed and weren't part of the exam anymore, at least until June 2019.

All the other exams didn't make use of sample study cases, as of 2019.

7. Finally, take the practice exams. The practice exams provide an explanation for each of the questions after you finish them. They also help you get an idea of the format of the questions you’ll face on each exam and will help you know how prepared you are.
   • Professional Cloud Architect practice exam
   • Professional Data Engineer practice exam
   • Professional Cloud Security Engineer practice exam
   • Professional Cloud Network Engineer practice exam
   • Professional Cloud Developer practice exam

8. After finishing the practice exams, take notes of the topics that didn’t go well and re-read the relevant documentation collected on step 4 above.

9. Take the practice exams again (you can take them as many times as you want) and keep repeating steps from 6 to 8 until you feel confident to take the real exams.

Study guides

From my own experience, I can tell you it's a lot of work. For this reason, I decided to contribute back to the community and share the study guides I created throughout my preparation process.

The study guides are contained in the spreadsheet linked below, each on a separate tab.

To use it, create your own copy. Once you do it, the spreadsheet will be made writable to you and you’ll be able to update the Status column, which you’ll help you to track your progress through the material:

A screenshot of the spreadsheet with reference material for both professional certification exams.

You can freely copy, change and distribute this material. The only thing I kindly ask from you is that you keep a reference to the original material and give me proper credits, if you feel it's helpful.

Even though the Cloud Developer exam is back in beta, I believe the guide I created is still relevant, as it covers a lot of the topics (probably even more than what's needed_.

Disclaimer

I'm sharing these guides with the only intent of helping people aiming to take the Google Cloud Professional certification exams. Be advised there is no guarantee that following the guides will make you pass the exams. Use them at your own discretion.

Tips for taking your exams

1. Know what each product does, what it’s good for and what it’s not good for, as well as its billing characteristics.
2. As you can see above, except for the Cloud Developer exam, which seems to be back in beta, you have 2 hours to finish the exams. Keep in mind that good time management is crucial for your success.
3. Don’t spend too much time on questions you don’t know. If you aren’t sure about an answer, mark the question to be reviewed later and move on to the next questions.
4. Practice as much as possible using the practice exams.

Conclusion

In my opinion, the greatest value of a certification** is to help you know which subjects are important to learn as a professional, if you are willing to work with a specific technology.

The Professional Cloud Security Engineer certification exam helped me a lot in guiding my studies to learn more about the security aspects of the Google Cloud Platform. It helped me learn about specific concerns** we should have when considering or using many of the platform products from a security standpoint.

The Cloud Network Engineer certification was the hardest one I took out of the five. I believe it’s due to the fact my whole career was focused on Software Development so far.

I recognize that, just because I got certified, it doesn’t mean I am now a network specialist (and, honestly, I don’t really intend to be). As some people say, a certification is just a “piece of paper”, right? On the other hand, I certainly learned a lot during this process and having some networking skills in my belt certainly makes me a better professional.

In fact, some of these skills have already helped me solve some infrastructure issues from one of my clients.

Besides all that, certifications are still highly valued by the market and may help you stand out from the crowd.

As a final tip, if you aren't sure which certification you should take first, this is the order I'd recommend (unless you have specific needs related to your job or are strongly focused on a specific area):

1. Professional Cloud Architect
2. Professional Cloud Security Engineer
3. Professional Data Engineer
4. Professional Cloud Network Engineer
5. Professional Cloud Developer (because it's back in beta, otherwise it would probably be number 3 in this list)

I hope this article and the referenced study guides help you in your journey to become a Google Cloud certified professional and I wish you all the success in your career!

_Photo by [Unsplash](https://unsplash.com/@mahdigp?utm_source=ghost&utm_medium=referral&utm_campaign=api-credit">Mahdi Dastmard / <a href="https://unsplash.com/?utm_source=ghost&utm_medium=referral&utmcampaign=api-credit)

What being a Senior Developer is not

Before we start, let's get this out of the way. Contradictory to what you'll see on 95%+ of the job postings online, a Senior Developer is not strictly correlated to only the number of years on your resume.

It's true, more often than not, that many years on the job typically bring with them a lot of experience. And with some companies you can get by with just that. But it's not the only quality that rightfully proves that someone is at a Senior level.

This is a common problem in the software world and can lead to high expectations with low delivery. It can also lead to conflict within the team when your new 15 year 10x Senior Developer refuses to work with others.

So what can we do to prepare ourselves for that role?

What makes a Senior Developer?

Looking back through my career at the developers on my team that I've admired and respected the most, it's really come down to four qualities:

• Experience
• Leadership
• Mentorship
• Technical Ability

It's not good enough to look at any one of these as the sole representation of how someone will perform on a team. Each developer is unique and may be stronger with one quality than another. But it's important to see how those qualities come together to determine how someone will help your team grow.

Let's break these each down a little bit.

Experience

Experience is typically thought of as years on the job, and while it's not completely inaccurate, it doesn't tell the whole story.

Just as every developer is unique, so is their experience. While one developer might have spent five years in an intensive position where they worked to solve hard technical challenges every day. And another might have been kicking their feet up at a local shop where their only responsibility was to update the website every week.

And that's not necessarily a bad thing! We each have our own journey and need to balance our lives to fit it. But it's not realistic to say those 5 years were the same.

Then what does experience really mean?

Recognizing patterns from previous work

Every developer has a story (whether they remember it or not) of a random error they stumbled into through their development experience. This could be something dealing with Javascript, webpack, or even your operating system, and it just doesn't make any sense!

But whether through a peer or by searching on Google, you figure it out. And three months later when you're working on another project and run into the same thing, you don't even have to Google it, or you already know what to Google. You already know what the issue is and can get past it quickly and move on.

This is the kind of experience that makes a difference. Being able to recognize patterns whether because of an error or because it was super successful is what helps each of us grow. These are the experiences that help a team grow when others are stuck and you can get them out of a bind.

Recognizing what you don't know

It's also important to understand what you don't know. I think part of what contributes to my own personal struggle with imposter syndrome is that the more I learn the more I realize I don't know.

But this shouldn't be looked upon as a bad or scary thing. This should be inspirational. That means that your craft that you've been working on has that much more cool stuff to explore!

It's important to realize how this impacts your work and the rest of the team. For example, it doesn't help anybody if you act like you know everything and commit to huge amounts of work. When you commit to that work and actually don't understand it, it could knock your sprint off track which can frustrate the entire team (and the client).

Whether it's when you're planning or during development, don't be afraid to ask for help. Come up for air and throw your hands up! Just because you're the only Senior Developer, doesn't mean you can't learn something from a Junior team member.

Try to take a good look at where you've been, what you understand, and where you could benefit to dig in more.

Leadership

As a senior member of a team, I would expect a developer to have a natural tendency to lead. While this doesn't mean you have to be an actual Tech Lead on a project or make any of the final decisions, this does mean that you should have a basic level of being able to help push the project forward

Understanding the bigger picture

If you've worked on projects with team members, you should know that each project or feature typically comes with a bunch of stories to work through to get it done. Each story should be a focused piece that helps accomplish a larger goal.

Where this becomes challenging is if no one on the team understands how each of these stories help to accomplish that bigger goal. As a Senior Developer, you should be able to see how each piece fits into the puzzle and why the story is written with the specific acceptance criteria. And if you don't know, you'll know how to get the answers and make sure it's communicated to the team.

If you're unsure of the direction, try to take a step back. Try to see where it fits in. Help to lead the project team to that ultimate goal.

Helping direct less experienced team members

This comes naturally in the ability to help guide those on our team who are more junior or less experienced. It's common for developers to lose focus on the big picture. But as we just discussed, a Senior Developer should be able to continuously have a good idea of the overall project and where the different stories fit into the bigger epic.

Help guide others on your team to get them on the right path. While it would be beneficial for everyone to understand how everything fits in to the bigger picture, sometimes it makes more sense to help an individual focus on how their specific task fits in.

Try to recognize this struggle when working with others whether by encouraging them to ask more questions or helping to guide them if they're not quite on the right path as you're reviewing their code.

Mentorship

It's often more convenient to be heads down on your work and not have to worry about what anybody else is doing, but is that really benefiting anyone?

Helping to build up other team members

You might be the so-called 10x developer, but doing everything yourself and not helping others can only slow down the overall team. Often you'll be stuck picking up the pieces that you could have easily caught if you spent an extra second pairing up with someone else on your team.

It's also bad for morale. No one wants to feel alone on a project and even more so as a junior. Software is a big scary world, a little guidance can go a long way to helping others to become more productive and subsequently encouraging a happier, less stressful environment.

It's easy to forget that we were all a junior team member at one time. While you might take things for granted, the concepts might be really challenging for others to grasp.

Keep in mind that we're all in this together. Celebrate the wins whether big or small. If somebody's struggling, reach out to help.

Knowledge sharing

Sharing knowledge is something many teams struggle with. While we're all usually hopeful that there's a way to accomplish it, most of the time it just goes unsolved. So what can we do?

Take it upon yourself to share what you know. Did you just rework the core business logic? Offer 30 minutes to walk everyone through the code. Pair up and screen share with your code reviewer if they're having a hard time understanding it.

This is something we can encourage everyone to do. You'll naturally learn more by presenting your work by reinforcing what you just worked on. This is helpful whether you're a Senior or it's your first time opening up a code editor.

Technical Ability

I intentionally wanted to leave this until the end. This is because, while it's important, there are more aspects to your journey to becoming a Senior Developer than just being really, really good at something.

Ability to get moving quickly

As a Senior Developer, I would expect another Senior Developer to become productive in something quicker than a Junior Developer. If they're an expert with Javascript, I would expect them to understand the core principles and patterns of the language.

But back to the idea of recognizing what you don't know, it's not reasonable to expect all Senior Developers to know everything. I wouldn't consider an expert in Ruby any less of a Senior Developer because they don't know Javascript, but I would expect them to understand how to apply what they know when building in and learning another language.

Promoting software patterns

More often than not, the code pattern you just came up with isn't new. And that's okay! The goal of building great software isn't necessarily to be unique with every solution.

And because of that, we can learn from past work by seeing what's succeeded and what's maybe not gone over so well to find patterns that work for you and your team.

Patterns like MVC (Model View Controller) didn't become popular without reason. Developers learned from the past and have learned from their peers who have solved big software challenges. With that knowledge, they can apply the solutions to their own work. It's not about reinventing the wheel, it's about solving challenges and making a good product.

We all have our own unique journeys ahead

No matter what anyone tells you, we all have our own unique code journeys. This is meant to encourage you and inspire you to become a better overall developer and understand how your work impacts the rest of the team.

While you certainly might succeed without taking these things into consideration, you could be missing out on core traits that could make people not want to work with you from a human being perspective.

Whatever your journey, keep these things in mind as you grow into becoming a better developer!

What do you think makes a good Senior Developer?

Do you think I'm spot on or way off? Share with me on Twitter!

Around this time last year I started learning the basics of code in my spare time, and sure enough found myself working as a professional developer just 7 months later – with no CS degree, no bootcamp, and no clue.

So if you’re reading this you’re probably thinking: how on earth did that happen?

Well, my thoughts exactly.

In this article I’ll share what I did in those initial 7 months leading up to my first ever dev job. I’ll also include lots of resources I found helpful along the way, and bits of advice that I wish I had taken on sooner.

If you’re a fellow coding beginner aiming to make a similar career change into web development, my hope is that this article offers you some guidance…

(If you haven’t started coding yet but want to find ways to begin, you might find my previous article a little more helpful, which includes lots of insights on how to take that first step towards learning to code.)

So, lesson number 1:

? Share your interest early.

When I seriously started thinking about programming, the first thing I did was talk about it.

I asked my friends and family if anyone knew any developers who’d be willing to chat about their jobs, and ended up meeting so many smart and creative people who gave genuine, practical and (most importantly) varying insights.

The key here is to try and meet as many different kinds of developers as possible. If you can, speak to people with all sorts of interests and specialties at various stages in their careers. This kind of access can unveil the variety involved in programming, and you can use it to demystify the idea of coding as this big, scary thing.

Another good habit to pick up early is to constantly:

? Ask.

I asked developers some of the most basic things like:

• What the hell is GitHub?
• Do you really not need a computer science degree?
• Why is everyone always talking about React?
• What kind of tech jobs do you think there’ll be in 10 years time?

? And go to meetups.

If you’re lucky enough to live in a place like London where there are plenty of meetups happening – go!

This is great practice early on not only because you might get to have human beings guide you through coding problems, but because it lets you meet with organisers, coaches, bootcamp students, etc. etc.

By going to meetups you can also build up your network in the industry and hear about potential job opportunities suited to your skill level.

Some of my favourite beginner-friendly and inclusive meetups include:

• Codebar. This is an amazing weekly meetup with over 20 chapters worldwide, where you can work with coaches and really get stuck into your code (they also run virtual meetups for those who can’t make it to events).
• Ada’s List. This organisation runs friendly monthly meetups in London alongside a virtual community online, offering women a great way to meet other women in tech (and not just coders).
• 24 Pull Requests. This annual event (also in London) is a lovely place to contribute to open source projects, and includes an introduction to Github – very handy for beginners.
• Node Girls. This group organises meetups a couple of times a year in multiple locations, and is a great place for newbies to learn Javascript and Node.js.

?‍♀️ Next: Play the field.

For ages, I thought the first thing I had to know about code was what language I wanted to learn. But not only is it ok not to know where to start, I actually think it’s a huge advantage.

There are so many languages and topics out there, and while this can definitely be overwhelming as a beginner, you can also make the most of your naivete and just try it all out without getting too preoccupied with all the surrounding jargon (for instance, you don’t need to know the entire history of CSS to just play around with it) – which leads me to my favourite bit of advice from those initial 7 months...

? Be bad.

When I first started I was so scared of how bad I was going to be. And one of my biggest revelations since then was: nobody cares.

Of course you’re going to be bad at it! You’ll be terrible. But, having a beginner status gives you license to suck at everything, so use it while the stakes are low. Enjoy being terrible – it’s fun, and freeing.

?‍? Do the tutorials.

When you’re trying to level up from total beginner, tutorials are great because their format eliminates the problem of having to figure out what you want to learn and how you want to learn it (while you’re actually just trying to learn it).

Some of my favourites include:

• Any of the Codebar tutorials (great for learning different languages from scratch)
• Rachel Andrew’s video tutorials (awesome for learning CSS grid)
• NodeGirls workshop tutorials (nicely paced walkthroughs that introduce you to Javascript & Node.js)

When it comes to tutorials though, try and understand how you learn best and don’t get bogged down in one method or approach just because it’s the most popular or it was suggested to you.

You might not know much about coding at this stage, but what you do know is how you learn best. So trust your own judgement here.

Here are some different learning methods that have worked well for me:

• freeCodeCamp curriculum. Byte sized exercises for different languages, great for when you need a break from heavy tutorials and want to play around with something a little lighter.
• CSS Diner & Flexbox Froggy. Two fun games that are great for helping you get to grips with CSS selectors and practicing flexbox layouts.
• Codepen. A coding playground where you can look at people’s projects alongside their code, letting you to connect the dots between the two.
• Grasshopper. A sweet, beginner-friendly mobile app that introduces you to Javascript fundamentals.
• Eloquent Javascript. This digital book pairs really well with freeCodeCamp exercises, giving a thorough and foundational understanding of Javascript.

? Be a copycat.

Soon enough, you’ll feel like it’s time to build something a bit more substantial. And a really fun way to do this without feeling overwhelmed is by trying to replicate cool stuff you’ve already seen (you can browse some cool looking website here). And as you do this:

? Know why.

If you’re building your first ever website, before you even get to writing any code remember to ask yourself why. Are you doing it to:

• Just fill up your portfolio?
• Learn a particular language?
• Try out different hacks you’ve heard about?

As a beginner, your main reason for building something is probably to learn by doing so your website or app is just a means to an end. It’s the byproduct, not the goal. Remember that.

Knowing this distinction is crucial to learning effectively, especially if you’re teaching yourself because as you’ll quickly learn: everyone’s got their own way of doing things. For instance if you’re building a website as a way to learn flexbox, then don’t let someone talk you into using Bootstrap.

If someone tells you there’s a quicker way to achieve a goal they may be right, but they might not have clarity on what the real aim is.

? So articulate it.

First to yourself, then to others, and then make your own decision about how you want to go about it. This part might seem super obvious, but in the midst of soaking up all that information, it’s all too easy to forget.

? Then chill.

The great thing about self-directed learning is that you decide the whats and the hows right? Well, another great thing is that your deadlines are made up by you, and if you don’t meet them, nobody cares. So give yourself a break!

⚡️ Stay inspired.

This learning process is twofold: on one hand you need to spend time figuring out the technical minutiae in your code, and on the other you need to look around every now and again and see what other people are doing.

Blending these two approaches gives a great holistic perspective on your learning, and helps mitigate the stress of getting caught up in all the details. Here are some tips I found useful in my first 7 months:

? Go to conferences.

• You Got This. This is a UK-based event specifically for developers in the early stages of their careers. I went to it without ever having worked as a developer, felt totally comfortable there and left ready to get stuck into some code.
• New Adventures. This Nottingham-based conference provides a less technical, more meta approach to tech and where it fits into the world these days. With varied speakers and far-reaching topics, it’s super inspiring.

? Read up.

• freeCodeCamp (of course)
• Codebar (they run a great series of interviews with self-taught developers)
• A List Apart (publishes a huge range of topics from design to coding to career progression)
• Smashing Magazine (features articles, books, events, jobs – you name it)

? Follow people.

• Mandy Michael – has a lot of seriously cool stuff on Copeden.
• Rachel Andrew – gives loads of inspiring and practical talks, many of which you can find online.
• Jen Simmons – has a rich Youtube channel full of insights on design and developing.
• Saron Yitbarek – founder & CEO of CodeNewbie – total boss.

And that’s essentially it. Looking back over the last year, I’ve come to realise that these core lessons were what sustained me as I went from being a copywriter who had never looked at a single line of code, to working as a full time developer.

So if you’re thinking about switching careers but are worried about committing to such a big change, try breaking it down into these smaller goals and challenges.

If it can work for a woman who had absolutely no clue what she was doing at the time, it can surely work for you. So please: use these lessons learned, tailor them to your own learning style, and get after it.

If you want to get in touch or keep up to date on future articles, talks and events, you can follow me on twitter here: https://twitter.com/niamhmccoo

Landing your first junior developer job is an amazing accomplishment. You’ve worked really hard towards getting the skills to pay the bills and now you’re ready to prove yourself in your new job.

You’re definitely excited. And you should be. Being a developer is awesome. But with that excitement, it’s also normal to be feeling a bit nervous. My first week as a developer was pretty hectic. My first day, I was given a 200 line SQL query to try to make sense of… I still have flashbacks from that. Generally speaking, you’re going to feel like there’s so much you don’t quite know or understand, but it’s all a part of the experience.

In order to make your transition into the working world as a developer as smooth as possible and really bring value to your team, here are my professional recommendations.

Really Understand Git and Semantic Versioning

Git is the most popular tool for managing source code. If you’ve graduated from school or completed a boot camp, you’re probably at least familiar with what Git is.

Working knowledge of Git will only take you so far.

When you start working on a team, you’ll be introduced to concepts strategies like:

• Pull Requests (or PRs as they’re known on GitHub)
• Merge Requests (this is what GitLab calls PRs)
• Merging
• Rebasing
• squashing commits and
• Semver (semantic versioning)

My first week as a developer, I actually couldn’t stop sweating. I was so nervous thinking that I was going to delete the entire company by accident when presented with options in Git I wasn’t familiar with or didn’t know how to deal with.

The coaster I never knew I needed.

In my experience, a lot of teams like to use Git Flow in order to manage how code gets developed, versioned, tagged and released into production builds.

For new developers, some of the common questions and confusions I see are:

• the difference between merging and rebasing
• when should I rebase?
• how do version numbers work?

If you look into understanding each of these terms, I think you’ll be really well off for how to contribute within a team and release features.

Come prepared to your standup meetings

If your team practices agile, you’ll be expected to report:

• what you accomplished the previous day
• what you’re working on today
• what’s blocking you

This can be slightly different from company to company. Sometimes you might not even be asked to do this. But regardless, I think it’s useful for you as a developer to know what you’re going to work on the next day ahead of time. Sometimes it can be easy to get trapped into the mode of just responding to things that come up, and that can lead to burnout and losing focus.

Try coming prepared to your standup meetings by preparing ahead of time. Spend 3 minutes every morning before work or before you go to bed to lay out what you’ve accomplished the day before, what you’re going to work on for the day, and what’s blocking you.

You’ll not only impress your team lead by coming prepared, but you’ll appear a lot more professional and credible, even if you get stuck and aren’t able to accomplish what you wanted to that day.

Learn how to ask for help

Knowing how and when to ask for help as a new developer is so important. What might take you 5 hours to figure out could take another more experienced developer 5 minutes (or seconds).

It truly is in your best interest (and the company’s) to ask for help when you need it.

However, it’s not a good idea to ask for help on every single challenge you’re presented with without attempting to solve it yourself first.

So, before you ask for help on something, make sure that you:

• try to figure it out yourself
• search Google for answers on how to solve the problem (paste logs or error messages)

If no dice, then it’s definitely time to ask for help. Here’s how you properly ask for help:

Asking for help in person

Look out for the other person’s body language. If they seem like they’re annoyed, stressed out, or in the zone, it might be better to ping them first and ask them if it’s a good time for you to come over to ask them a question.

Be wary of people doing the ‘ol George Costanza: Looking Busy trick.

Asking for help over instant messenger

When you’re thinking of pinging another developer over IM for help, there are a couple of ways that you can increase your success in getting a positive and speedy message back.

Here’s a bad example on how to ask for help:

“Hey, can you help me? I can’t install node.js on my computer, it’s not working.”

This isn’t a good way to ask for help. Here’s how it could be improved:

• Introduce yourself first if you’ve never talked to this person before
• Be sure to include what you tried to solve the problem. Give the other person context as to what the problem might be by providing things that it’s not.

Here’s a better way to ask for help.

Good example

“Hey John, I’m Khalil — the new developer here. Nice to meet you. I heard that you might be able to help me with a particular problem I’m facing. Basically, I’m trying to get Node.js installed on my computer. I tried this link (paste link) and followed the instructions, but when I ran this command (insert command), I got this error message (insert error message). I’m using one of the new Macbooks. Any idea what’s going on?

There’s a reason why this is so much better.

This way of asking for help provides the other person with so much context as to what you’ve probably already tried so that they can hone down on what the problem might be more quickly.

When you don’t include this information, it’s putting a burden on the other person to ask you relevant questions in order to get to the root of the problem.

Imagine how much time you save by giving the other person all the information right up front. It takes time to ask questions. That other person might be busy with a lot of other things at the moment, so think about it like this:

Try to help the other person save as much time as possible by giving them as much information about the problem as you can upfront.

When receiving help

Do not have an ego. I repeat, do not have an ego.

When someone takes the time to help you out, you should not aim to make it known to the other person that you knew how to fix it all along.

When your issue is resolved, don't say:

“yeah, that’s what I was going to try next”

Do say:

“Got it working, thanks!”

Be careful to not blame something not working on someone else. Don’t say:

“The backend team messed it up and that’s why it wasn’t working.”

Instead, say:

“I’m thinking that it may have had something to do with the recent changes on the backend.”

Always make sure that when you finally get your problem solved, let the other person know. They might still be thinking about ways to help you solve your problem when you’ve already fixed it and moved onto the next thing.

Make sure that you manually test your code

I’ll never forget the one moment that at my first dev job that I neglected to test my code and just assumed that it would work in production.

That code made it’s way out to the client and broke as soon as they tried it out.

Boy, did I ever get an earful that day…

Don’t be like me, make sure that you manually test that your features work! Test the happy paths and even more importantly, test the non-happy paths.

Maliciously try to break your own code. If there’s something I’ve learned by putting code into production, it’s that if you’ve written bugs, your users will eventually find them.

Even if you have a QA team, aim for QA to find nothing.

Learn to write testable code and how to write tests for them

Writing testable code isn’t normally something that’s taught in school, but it is easily learned by applying the SOLID design principles.

Also, ask the other lead developers on how to write tests for something that you’ve written. They’ll appreciate that you asked. They might be able to sit down with you and teach you a thing or two. If they’re unable, or you don’t notice that there are many tests in the codebase anyways, the next best thing is to ensure that you tested the code manually.

Constantly be learning

Even if you’re a front-end developer, learn about backend development and DevOps.

If you’re a backend developer, research HCI (human and computer interaction) and UX.

Master a tool that you use on a daily basis.

In this career as a professional in technology, the amount of learning and growing that you do will ultimately determine your success.

Wrapping up

We’ve just gone over some of the best ways to make your first developer job a success, no matter if you’re a jr web developer, jr backend developer, front-end or whatever. If you practice some of these things, you’ll impress your boss and quickly figure out how to become productive working with your team.

If you’re still looking for a Developer job, you should consider joining Univjobs. We have hundreds of employers looking for students and recent-grads in technology. It truly is a great time to be a developer.

Originally published at https://univjobs.ca on May 9, 2019.

Referrals are the holy grail of freelance client acquisition. But they don’t come automatically, even for many experienced consultants. So, how do you get more referrals?

I’ve talked a lot about how word-of-mouth referrals have been a large part of my freelance business growth and success. Anyone who’s experienced freelancing for themselves — or has read about client acquisition strategies — will have heard that getting referral clients is the key to maintaining a pipeline of consistent work with less cost and effort.

However, as Abbey Woodcock recently pointed out:

Very few articles about getting clients really cover how to systematically generate referrals.

I’m guilty of that too. I’ve discussed client-acquisition quite a lot, yet apart from general terms like “building a strong reputation”, I’ve failed to go into detail about what steps you can take to encourage more organic referrals.

Challenge accepted! Today I will outline my strategy for how to turn nearly all of your clients into referral machines. And the solution may not be as direct as you’re expecting.

How do freelancers find clients?

Let’s take a step back and first consider all the ways freelancers may try to find new clients and projects:

• Referrals.
• Their own website/portfolio (through organic search or direct).
• Receive work as a sub-contractor for larger agencies.
• Other industry-specific showcases/directories (like Dribbble or Behance for designers).
• Cold outreach (email, phone)
• Social media groups or campaigns (Instagram, Facebook, LinkedIn, etc.)
• Attending live events (conferences, meetups, etc.)
• Gig Sites (Fivver, Upwork, Craigslist)
• Job Boards
• Paid traffic (google ads, facebook ads, etc.)

You may have a few more fringe channels to add to this list — depending on your industry, niche, marketing strength and preferences — but these tend to be the primary drivers of client acquisition for most freelancers and small creative service businesses.

I’ve ordered this list in the approximate order of importance for my own client acquisition pipeline. The percentage of success of each channel may differ greatly for you. But we’re here to talk about only one method, so let’s ignore the others.

Why are referrals the best form of freelance client acquisition?

Ease, and trust. Let me explain.

I’ve heard different numbers, but most people seem to agree that getting work from existing clients is about five times easier (faster, cheaper) than finding new clients. I hear you saying “referral clients aren’t existing clients!” and you’re right, but they come with most of the same benefits.

Referral clients come with the same ease of acquisition as existing clients. You could almost consider a referral as an extension of an existing client. You didn’t have to reach out or pitch to them, and they already know something about you and have some level of trust in you. More on trust below.

If you can cut your marketing efforts dramatically and still keep your work schedule busy with referral work, who wouldn’t want that? We all like it when good clients fall into our laps with very little effort on our end. That’s the freelance dream (really, the dream of all service businesses regardless of size).

However there’s a deeper reason to encourage referrals. Referral clients trust you more.

Trust is a hugely important factor is building client relationships. Trust helps grease the wheels of the creative feedback/revisions process, allowing you more freedom to use your skills and experience. Trust makes client communication more enjoyable and effective. Trust leads to long-term partners.

I consider building trust to be a key part of any client onboarding process, and it often takes the first 25% of a project to communicate expectations effectively and build that trust over time.

But referral clients come to you with a large part of that trust already baked in. Why?

When a friend, family member, or colleague — a person you already trust and respect — refers you to someone or something, some of that trust rubs off. It transfers to the thing they’ve recommended by good association. You think — with less due diligence than usually required — that you can trust this recommendation because you trust the person it came from. If they say something it good, it’s probably good, because this person has your best-interest at heart. And, making a good recommendation makes them look good too. It gives them extra social cred.

When that referral client comes to you, they come pre-loaded with trust. They already know you’re the person they want for the job before you’ve even tried to sell your virtues. Half of your trust-building has been done for you. Now all you have to do is meet or exceed that expectation.

With more freelance business experience, usually referrals grow too. You naturally establish a good reputation over time, and slowly grow a list of satisfied clients that refer you to others with little encouragement needed.

However I’ve heard from experienced freelancers who used to get referrals, now saying they’ve suddenly dried up. Or what about recent grads or new entrants to the freelance market who haven’t had the luxury of building a reputation over years?

It’s not magic. There are steps you can follow to accelerate the process of earning referrals, no matter what your experience level. Here’s my recipe.

How do I get more referrals?

If you search for “how do I get more referrals”, you’ll find plenty of scripts that would help you ask for referrals in a very direct way. They might tell you to email your client after a successful project, asking:

“Do you have names of three friends or colleagues that I could reach out to?”

And then you’d send something like this to those new contacts:

“I worked with [CLIENT NAME]. They were really happy with my service and said that you might be interested.”

Some people may have success with this method, but I don’t do it and I’m not aware of anyone else who does. The problem is that it comes across as too desperate. It’s not something that adds to a genuine relationship and interest in your client’s success. Immediately treating your client as a lead-generation tool feels sleazy. That’s not how I want to be remembered by my clients.

So I take a more indirect approach to encouraging referrals. I make myself as “referable” as possible. Then my clients refer me by their own initiative when it suits them best, without me ever having to ask.

Also remember that referrals don’t always come from clients, they can come from colleagues as well. When I’m too busy to take on a new job, I usually get asked if I can recommend someone else. You want to be that someone else.

Being more naturally “referable”

Being referable is a combination of a number of factors. Each is helpful on its own, but their true power comes in doing them all at once. You’ll find they snowball together to create a momentous effect if you complete the entire formula.

1. Establish a great reputation

This is the most important foundation, but also the most difficult step for new freelancers to achieve. The more experience you have freelancing, the easier your reputation will naturally build. So long as you’re doing the right things.

You want to be seen as the best of the best.

Building a reputation is simple. It takes only two thing: excellence and consistency. Be excellent at your craft, and do it consistently for every client and every project. You’ll quickly become known for your quality of work.

2. Be ultra-professional & build trust

Being good at your craft is only half of your job. Running a professional business is the other. The basis of any referral is trust. Your colleagues and clients must trust you enough to put their own reputation on the line by recommending you. You need to be credible enough that they feel elevated to be partnered with you. They need to feel proud to recommend your name, as it reflects back on them.

The way you communicate with your clients and set expectations will be just as memorable to them as the quality of work that you deliver. Be the freelancer they remember because you were so trustworthy, reliable and easy to work with, and your reputation will grow at twice the pace.

3. Overdeliver

I don’t mean the often-ill-advised “underpromise and overdeliver”. I never underpromise. I simply overdeliver, without being asked to.

Surprise your clients with a little something extra now and then. That can either be an added bonus on their project, or a thank you gesture completely unrelated to your creative work.

Maybe you go the extra mile to document a really comprehensive interaction styleguide for your latest UI design project, even though the client didn’t ask for it. Perhaps you deliver a framed print of your client’s new brand identity for them to hang proudly on their wall, as a gesture of your gratitude for a fun project. Or maybe you simply send a holiday card or some surprise chocolates because you know your client is a cocoa lover.

Remind your clients that you’re thinking of them and you have their business’s best interest at heart.

4. Build ongoing relationships

Even if a client is clearly a one-off project and there’s little potential for future work from them, it pays to stay in touch. I do my best to email all of my favourite (or most valuable) clients from time to time, just to check in and ask how their business is going. This is easy, because I don’t take on new clients unless I have a genuine interest in their business. So following up about their plans and successes is a natural step for that kind of relationship.

This follow-up communication may even result in more work directly from your existing clients, which is better than referrals. But even if it doesn’t deliver more work, it keeps you “on their radar” so when the right time arises for a referral, they’ll have you in mind.

5. Your website must back up your personal brand

If your colleagues or satisfied clients do recommend you to one of their contacts, the first thing that new contact will do is google you and check you out. Make sure you are easy to find when they do their due-diligence.

Once they hit your website (or any other online representation of you, like your LinkedIn profile) the messaging they encounter must match the expectations they’ve been given. Make sure there is no inconsistency or disconnect between what your carefully crafted reputation says about you, and what impression your website leaves on them. These touchpoints are all part of your personal brand, and like any other brand, the most important point is consistency in experience.

6. Reciprocate referrals

If you want a colleague or client to recommend you, one great way to encourage this is to recommend them! If you come across any of your own connections or other clients who could benefit from a relationship, help them make that connection with a personal introduction or referral. This is another way of showing your clients that you’re thinking of them, and that gentle reminder will encourage them to do the same for you.

Being a “matchmaker” can be a valuable tool for keeping yourself in your client’s awareness, and in their good graces.

7. Say thanks for referrals

Once you do get a referral, it’s imperative that you show gratitude for it. I make a point of asking every new person who contacts me “where did you hear about me?”. If they say they were referred by someone, I waste no time in contacting that person and thanking them for the referral. A simple email or phone call will do. Even of the referral leads nowhere and I’m not interested in the work it brings, I thank them for it just the same. Some people like to send small gifts, but I don’t feel it’s necessary. A simple thank you note will let them know how much the referral means to you.

Now you’ve built a mighty referral engine

All of these steps done together make it very easy for your colleagues and clients to refer you, without being asked or bribed to do so. And equally important, easy for those referrals to validate your value and feel confident using your services.

I won’t promise this formula will bring you overnight referrals. Like any business strategy, knowing the theory is one thing but successfully implementing it is another. You may have to refine things along the way to build a system that feels right to you. I’d be interested to hear what else you do that may work better.

This is part of playing the long game of freelance business success. If you’re a part-time freelancer side-hustling to make some extra cash, or a temporary freelancer filling “in-between” other employment, this may be too much of a commitment for your casual business endeavour.

If you’re a full time indie business owner looking to make a permanent career out of it, you can’t afford NOT to get referrals. Commit to doing these things for a few years — not just a few weeks or months — and watch your colleagues and clients spread around your good reputation for free. That’s when you hit freelance referral gold.

Please ? clap if you found this valuable, ? follow me for more writing like this, as I unfold 17 years of freelance business knowledge ?

Subscribe to get my best articles in your inbox.

This story can also be found on solowork.co

So, you’ve landed an interview with a company you’ve been dreaming about working at. You sit down and, after some small chat, the interviewer says “tell me a little bit about yourself.”

This common question results in the first impression at your interview, but is often the most overlooked. In my experience from being on both sides of the interview, I believe that by crafting a unique and memorable answer to this one question, you can land that job. Here’s how.

Don’t recount your resume

A big mistake I see people make is using this question to go over their résumé.

Don’t do this! Your interviewer has already looked over your résumé and probably has it sitting in front of them during the interview. They don’t need you to go over it again.

Practice over and over again and prepare answers to any obvious questions your interviewer may have

You wouldn’t show up for a talk you’re giving at a conference without practicing over and over again, right? Make sure you don’t show up for an interview without doing the same.

Sit down a few days before and think of what questions an interviewer may have for you after looking at your résumé. Then prep how you will answer them.

For example, I’m a coding bootcamp graduate who used to work in music publicity (read my career transition story here). A potential employer looking at my résumé may wonder why I wanted to transition from publicity to tech, and they’d probably ask about the process I went through.

And so, that’s one of the main things I address in my answer, because I know that will be the biggest question and could cause the most hesitation when it comes to a potential employer choosing me for the job.

Take a look at your own résumé as if you’ve never looked at it before, and figure out what those questions would be for you —and be sure those are your main points in your answer.

Find your quirk

For the next portion of your answer, find something that will make you stand out. You want your interview to be memorable, and this is a great way to accomplish that.

Have you started your own meetup group? Do you volunteer consistently at a charity? Are you super passionate about a certain sport? Find your quirk. Make sure to mention it and tie it in to why you’d be a great choice for the position.

I personally have mentioned that while I was at The Iron Yard’s front-end bootcamp, I co-founded the Nashville Tech Ladies® chapter where I organize quarterly professional development meetups for women in all areas of tech. Sometimes I’ll even mention how I grew up doing ballet. I’ll describe how ballet has taught me many things, like how to pay attention to the little details, that I am now able to translate into my career.

Pick something that is uniquely you, and it will make a lasting impression.

Explain why you applied for the position

Lastly, round out the question with why you want the position and why you are excited about it. You applied to the position for a reason — so tell the interviewer why you did it. They saw something in you, and this is a great moment to let them know why you think it’s a good fit.

What are your tips for answering this question? Follow me on Twitter and let me know!

Kara Luton (@karaluton) | Twitter
_The latest Tweets from Kara Luton (@karaluton). Front end developer + former music publicist. Retired ballerina…_www.twitter.com