You need to find a job to get software development experience, and you need the experience to find a job. A Catch 22? Well, not exactly. For one thing, development as a profession changes so much overtime that anyone who works here ends up learning, unlearning and re-learning things. And for another, coding culture differs from company to company, and it is going to take months for anyone, regardless of their experience to start knocking out valuable, production-ready code. This is why your chances of getting a job are not as bad as you might think. All you need to show them is that you have an open mind and easy to work with. As for specific skills, these will skyrocket once you’re positioned in a company where you’d be spending 8 hours a day coding, surrounded by experienced colleagues.
It all boils down in the end to what you show and say on your interview. It has to make the interviewer confident that you will be able to learn what the job requires you to do and learn it quick. Yet, they will want to see your portfolio. I have written previously on how to build that portfolio in the first place (and should probably write more, tbh). As product engineer Stella Chung suggests in her brilliant piece, your portfolio needs to have at least three solid projects, showcasing the full range of your current abilities. And having your portfolio website adds bonus points!
There are a few things to keep in mind though:
1. It must look great
Regardless of how perfect the code under the hood you think you have, people will still judge your portfolio based on how it looks. If your website is full of broken links or not mobile-friendly, it will immediately tell them that you are not paying attention to details, you can’t make a template, use Bootstrap, and so on. Why would they want to hire someone like this? Yet if you spend a bit of extra time thinking about the UX and UI and make it responsive, this would tell them your approach is professional, and even if you don’t have massive experience, they will know that you treat your code professionally, too.
2. What are you building?
Your portfolio project needs to tell the dev manager what your portfolio project does - in a practical way. For example, if you present them your bug-tracker app, they will immediately know what it is and what kind of business problem it is trying to solve. Ideally, you’d build a good one, but in any case, they will know what a bug-tracker app is, and what are you trying to do here. A case study like this will give you a solid starting point to talk about your approach to problem-solving in the real business environment. In other words, it would take the fact that you lack actual work experience out of the picture.
“Your skills will skyrocket once you’re positioned in a company where you’d be spending 8 hours a day coding, surrounded by experienced colleagues”
3. Build in the stack they are using
A stack is a combination of tools you use to make a project function. For example, marketer’s stack will have email campaign software (Mailchimp), scheduling tools (Hootsuite or Buffer), CRM (Hubspot of Salesforce) and content management system (WordPress). Project manager’s stack is a combination of time tracking (Toggl), communication (Slack), file sharing (Dropbox) and an information/tracking system like Trello, Notion or Jira. Similarly, in software engineering, back end developers will have a package manager (nam for Node.js or pip for Python), testing (Mocha or Jest), database management (PostgreSQL or MongoDB, depending on what kind of database it is), caching system (Redis) and a server (nginx or Apache). If you’re in front-end, your stack should include Bootstrap to handle CSS and HTML in one place, some js library like React or jQuery and a framework (like Vue, Ember or Angular) (read more on stacks on toggl). Having said that, you can’t be sure what each particular company is using, right? So as long as you know - and can explain - why you use this or that particular component in your stack, it shouldn’t be a problem for them.
“People who are interviewing you have to listen to many, many other candidates - it is as hard for the employer to find a developer, as it is for a developer to find a job”
Conclusion: practice talking about your work
A great portfolio gets you an interview invite - yet, failing to present it well during the interview can be a deal-breaker. Talk with confidence and have a certain narrative. Remember, people who are interviewing you have to listen to other candidates too. Sometimes many, many others. Talking from personal experience, it is as hard for the employer to find a developer fit for their needs as it is for a developer to find a job. Talking about your thought process clearly and concisely is hard, especially in a stressful situation like an interview. You’d wonder, how do some developers do that with so much ease? Perhaps not surprisingly, they practice doing it a lot! Plan your speech, stand in front of the mirror and run through it 30 to 40 times, then you can be sure you’d be better than 90% of the other applicants bidding for this job. Why in front of the mirror? Because you need to be aware of your body language too. Remember that you need to talk naturally and make eye contact. I practice often with a stopwatch, to know how much time it takes me to explain things - you normally say 100 words per minute, so you probably won’t have a chance to say more than 1500 words in your interview - which makes sense to write it all down. Here’s a bunch of great tips on Corecursive podcast - it’s about speaking on conferences, but the same rule applies to job interviews.
To sum up - three portfolio pieces, a well-known stack fir for your purpose, and a clear vision of what the project does. If you can present the answers to these in your interview in a succinct yet eloquent way, congratulations, you’re hired - or if you’re not, it’s their miss!
