For a junior developer looking for his/her first job, the initial stumbling blocks can bring about a rush of “imposter syndrome” to stall even the most prepared interviewee. If you’re new to tech, it’s likely you’ve never had the technical interview under the pressure of securing an internship or full-time job.
Whether you’re still awaiting your first in-person assessment or already have some under your belt, the following is a beginner’s list of the criteria you’ll want to check off to generate interest in your profile and secure your initial interviews. The list is not comprehensive, but as a junior developer without formal development experience, you should consider this the bare minimum to begin your search.
1. Clean Up Your Github
Like the professionals, you’ll want a healthy Github that showcases your best looking projects and complete with a README file to let anyone clone into your repo to run your project cleanly. The last thing you want is for a prospective interviewer to run your code and start debugging right away. In any scenario where you’re meeting with a developer, it’s certain he/she will look at your Github and will likely care more about this than your resume.
In any scenario where you’re meeting with a developer, it’s certain he/she will look at your Github and will likely care more about this than your resume.
Consider this your “litmus test” — any senior dev will look beyond your tutorials and sample projects for something you’ve created on your own. While an active Github is not necessarily indicator of skill level, it’s an opportunity to make a strong first impression: don’t let a sloppy portfolio knock you off the candidate list.
2. Line up “Burn Card” Interviews
A “Burn Card” interview is a meeting you set up with the company that isn’t your dream choice. If you don’t get the offer, don’t lose sleep over it, the goal is to get hired and/or collect feedback on your candidacy. If you get the offer this could work as leverage with another employer. If not, make it a point to gather feedback and evaluate your performance.
All of us have our verbal and physical ticks — be conscious of this in the interview, especially the “Burn Cards,” to correct these bad habits. Take any negative experience as a learning opportunity — it’s never truly a “waste of time” unless you don’t learn anything from it.
Take any negative experience as a learning opportunity — it’s never truly a “waste of time” unless you don’t learn anything from it.
3. Build Something Challenging
This one may seem obvious, but it’s easy to see when a developer is complacent and relies heavily on his/her specialty, or is only willing to showcase class/group projects. The question you should be asking yourself is, “What new project can I build/am I building to highlight a new skill?” Technology feeds on change and the more willing you are to embrace this, the better positioned you’ll be to adopt newer technologies on the job.
Developers who refuse to respond to this change fall behind the curve and eventually find themselves out of a job. The key is to evolve with technology, not resist it. As an engineer, your job is to have your finger on the pulse of change — keep your technical skills sharp and follow the industry closely to prove you’re plugged in, pun intended. Whether you built your skill set at a bootcamp or are self-taught, your investment in your programming education does diminish over time. Keep up with the industry trends.
As an engineer, your job is to have your finger on the pulse of change — keep your technical skills sharp and follow the industry closely to prove you’re plugged in, pun intended.
In sum, be self-aware. Engineering teams, from seed-stage startups to large corporates, pride themselves on keeping their teams and tech “lean.” As such, any team you interview will ask themselves, “Can I spend 60–70 hours a week with this person?” Practice your story and your motives for becoming a developer to communicate this effectively. The best forms of practice are to get into actual interviews, test your performance under pressure, and build, build, build.
To learn more about the projects we’re building at Fullstack 360 — check us out at fullstack360.com
