Getting turned down for a web developer job can feel like you’re back at square one. In the worst cases, it can make you decide you’re not cut out for this work and seek refuge in the 💩 job you’re more familiar with.
The problem is the same whether you’re trying to get a permanent position or trying to find freelance gigs. I’ve developed a few strategies to minimize the impact of rejection on your career.
While you’re here, one of the best ways to push through rejection is to remember your Big Goal. I can help you find yours.
Stop Believing in Fate
You’re not destined to become a web developer. If you get turned down for the one job you applied for, it doesn’t mean you’re destined not to be a web developer. Whether or not you will have success comes down to three factors:
- Can you provide a valuable service to someone? (Hint: If you can build for the web, the answer is yes.)
- Can you stick with it long enough to get someone to pay you to do it (and endure the rejections in the meantime)?
- Can you get yourself enough exposures to land the luck you need to get there?
That last one deserves some more explanation.
Understand Luck (and Make It Work for You)
Think about playing the lottery. If you buy a single ticket, you have to be extremely lucky in order to win. If you buy tickets with every single possible number, you’d no longer have to be lucky at all to win. Buying every number is not feasible, but buying a single ticket and thinking you’re going to win is just silly.
What if you bought two tickets? You’ve now doubled your chances over buying a single ticket. Buy four tickets and you’ve quadrupled them. You can’t control the role of luck in your lottery chances, but you can control how many opportunities you have to get lucky.
The same goes for your web development career. Think of each job you apply for, each relationship you create, and each project you build as an opportunity. Each one of these opportunities has very little chance of becoming your new career. That’s why you have to collect as many of the opportunities as you can to maximize your chances that one of them will pay off.
You’ll never apply for every job or meet every business owner, but you should strive to find as many opportunities as you can.
Act Like You've Already Failed, Interact Like You've Already Succeeded
You will not know whether you’ve succeeded until the contract is signed. Everything may look perfect. You can’t imagine a way this could go wrong. Just one more executive needs to sign off before they can make you an offer. They’re waiting on a check to clear before they accept your proposal.
Your brain tells you these jobs will definitely close in your favor. In reality, 80% of them will evaporate. When you’re talking to your interviewers or prospects, you should be confident and interact as though they’re definitely going to work with you. Otherwise, you need to behave as though the deal definitely won’t happen… because it probably won’t!
If you’re looking for full-time work, that means keep applying to jobs, keep going to meetups, keep refining your resume… everything you would do if you didn’t have a single interview.
If you’re a freelancer, keep contacting leads and making new relationships. Don’t rest because the contract is almost signed, or you’ll be kicking yourself when it falls through.
Pursuing new opportunities is hard. That’s why it’s so easy to convince ourselves we don’t need to do it anymore. We don’t even need a contract signed to believe we’ve already succeeded. Fight against that impulse, and you won’t be so crushed when an opportunity slips through. Pretend you’ve already lost the opportunity. That will align your behavior with the most likely outcome.
Define “Opportunities” More Broadly
This advice is specifically for the full-time job junkies among you. If you believe the only way to your web development career is by applying for jobs and waiting for someone to pick you, think again. You can pick yourself. Hire yourself as a web developer by doing freelance work.
When you get turned down for that job after four rounds of interviewing, that’s a great opportunity to go pick yourself. Join your local Chamber of Commerce and start going to their events. Talk to people and find out what they’re struggling with. Look for opportunities to help them, and offer your services.
If you can show these people you’re valuable, you have a good chance of getting hired… and you can skip all the questions about how many years experience you have, whether you know Docker, Vagrant, React, Angular, Vue, Backbone, Ember, continuous integration, data science, Big O, and whatever else (because, as you probably know, all posted positions require at least 5 years experience in all of these 😉.
If you’re helping business people make more money, they don’t care what stack you use. They don’t care if you have umpteen years experience. Heck, most of them don’t even care about your test coverage.
None of this means you can’t go have a full-time job later, but why not pick yourself and start being a professional web developer rather than waiting for someone to give you permission.
“There is no better moment to pick yourself than right now. Because, after all, if you're not willing to pick yourself, who will?”
— Seth Godin
Listen to this episode of Seth’s Akimbo on this subject. He’s much more eloquent than I am at conveying why you should stop waiting to be picked.
Focus Energy on the Factors You Can Control
Imagine you’re coaching a team, and your advice to them is to “win the game!” Sounds reasonable, right? That’s the outcome you want, so why not define that as the goal?
You tell the team this and one of your players says, “Coach, how do we do that?” Oh, crap. You’ve given your team a goal that’s too abstract and that they don’t have full control over. The other team stands in the way, and we can’t predict what they will do.
What you need to do instead is figure out which tangible actions will increase your chances of winning. Coach your team to do those things. When we set a goal like “win the game” or “get the job,” we end up giving up because we don’t know how to do that and can’t do everything it takes to make it happen. If you’re looking for a full-time job, here are some important inputs you can control:
- How many applications you submit
- How many people you meet (other developers, CTOs, business owners)
- The quality and relevance of your resume
- Your skills
- The projects in your portfolio
Note: Be careful optimizing those last three. They’re not anywhere near as important as the first two.
Here are the important inputs for freelancers looking for gigs:
- How many people you meet
- How well you have honed your pitch
- How well you know your value proposition
Note: Again, the first input is far more important than the last two.
Work hard on the pieces you have control over, but don’t sweat it after that. At a certain point, you have to put your work out there and let the machinations of chance take over.
Takeaways
- You’re not fated to have any outcome. You have to create the outcome you want.
- Don’t worry about whether or not you’re lucky. Learn how to work with it by giving yourself loads of chances to get lucky.
- Keep going even when you have a good prospect. Most good prospects don’t work out, whether it’s for a job or a freelance contract.
- Pick yourself.
- There are many factors you can’t control. The same is true for everyone else too. Focus on the factors you can control.
Use these tips to get back on your feet and keep pushing toward your web development career!
Oldest comments (6)
In retrospect, I found three things that helped as someone who quit his job as a journalist a year ago, learned web development and found a full-time job within 6 months:
Having done freelance work, no matter how little it paid, as long as it was part of a new project and not adding features to an existing one.
Going to a lot of job interviews. This didn't actually help me find a job as much as it challenged me to learn new things, as online classes are good in teaching some fundamentals, but you never know what it is that companies actually need.
Not being picky in terms of employment options but being picky in terms of pay. My first job was at a poorly-run small business that stopped paying salaries the day my probationary period ended. However unpleasant this was, it was much easier to find work again because I already had experience. Plus, I got an offer for 30% more than what I last had and now work at a much nicer office where people don't smoke e-cigarettes. If I did anything differently, I would have asked for more money. Companies seem to judge people who ask for less money as less determined, and it's true: managers demand exponentially less from coders who are paid less, and you really need to have people demand a lot from you to have an urge to improve your skills.
Of course, my experience is based on me living in a city with a vibrant IT job market and financial stability thanks to my partner. Without that, doing 3-4 job interviews a week for two months with no experience and facing rejection at almost all of them would have been much harder both in terms of finances and overall morale.
Awesome advice! I'm curious why you specify freelance work that "was part of a new project and not adding features to an existing one." I think a lot of employers would love to see that you can come in and work with legacy code since that's probably what you'll be doing in most jobs.
At least in my case, it allowed me to have something to talk about during interviews. A prospective employer actually recommended that as a beginner, I stay away from positions that have a lot of refactoring and minor fixes as the premise of the job because it doesn't really teach you anything and doesn't let you have a real portfolio of projects.
And honestly, it's true, it's one thing to write new features, but another to just have a lot of boring chore-like assignments like "we need another column in this table" that may or may not cause you to refactor the entire codebase while you're at it. That and if it's written by someone much more skilled than you, it will be hard to understand how all the parts work together and faster to just imitate the logic of it and stick something in that works but doesn't conform to the structure. And if someone who is also new wrote it, in my experience, that can lead to things that are very stressful but ultimately useless for experience, like working with a codebase where a single file can have 2000+ lines of code.
I did 2 and 3. Got my first full-time dev job in a very tiny company with the smallest possible (by law) salary. And yes, it sucked in many ways, but I learnt a lot in 10 months and it was fairly easy to find another job after that, at least a lot easier than when you are a fresh graduate without relevant work experience.
Nice intro, I never had an issue with being rejected, I got used to it from my first time I looked for a dev position.
Even now, as experienced dev I hear the same lines "not enough experience in X technology".
Also being picky and knowing my market value did not helped at all 😹, most companies are looking for cheap labor not quality work.
I will bookmark this article and share it to my mentees at need.
It is great to have this by hand when the moment comes.