How to Get That First Programming Job

if i think through the corpus of posts i’ve published, it seems they rarely focus on concerns at the entry level. or, at least, at the entry level of software, specifically. today, i’d like to look at a reader question about getting that first programming job:

my question is, what if i’m not exactly a developer yet? i’m just wrapping up one of those full stack coding bootcamps, and i’m anxious about finding that first job. can you offer any advice? i want to show that i care about doing things right.

first, i’ll offer a few caveats. nothing in the reader question spoke to how much experience the asker had outside of the programming industry. that can matter, but i’ll write this post in such a way where it won’t. secondly, because i’m not entirely clear on the context for the last sentence, i’ll assume it exists as a way to show (and provide) value to prospective employers. in other words, i’ll assume that “i care about doing things right” means “i want employers to see that i have good work ethic and care about the craft.”

the entry-level conundrum

when i graduated college at the end of 2001, i graduated into the teeth of the .com bubble bursting. offers i had received dried up and interview invitations i had received evaporated. a new reality emerged — a reality in which entry-level folks found themselves subject to a paradoxical conundrum.

nobody wanted to hire software developers without experience. and i couldn’t get any experience without getting hired. i did what anyone in my position would do and went to work at radio shack. (i’m actually dead serious about going to work at radio shack. that’s how bad things got in my search, and i needed money.)

eventually, after almost a year of peddling cell phones, freelancing a bit, and looking for work in my spare time, i landed a job as a “software quality engineer,” or, as i like to think of it now, “software engineer with training wheels.” i took the job, shed the training wheels, and never looked back.

while my story eventually ended in joy (or at least employment), i believe the entry-level conundrum holds true in the industry to this day. developer fortunes as a whole have improved substantially since i graduated with my cs degree, but it can still be hard to find that first gig.

the hiring managers’ conundrum

having spent time as a manager and as a consultant helping with hiring, i have more perspective on this now. people that hire software developers face a conundrum of their own, albeit not one that threatens employment status, per se.

to understand this, put yourself in a hiring manager’s shoes and imagine what concerns that person. you might be tempted to think they worry about making a hiring mistake, but that’s not exactly right. rather, they worry about making an unjustifiable hiring mistake.

as an analogy, think of the it security theater in which companies make users change their passwords with absurd frequency. in spite of studies saying this is actually a bad idea , they keep doing it. why? because if some sort of hack ever happens and they didn’t have this policy in place, everyone would point fingers and accuse them of negligence. it’s cya 101: security theater.

think of avoiding entry-level people as diligence theater.

the truth of the matter is that humans are terrible at hiring strangers. why shouldn’t they be? meeting someone for three hours, asking them random questions, and then looking into a crystal ball to predict three to five years of working compatibility is such an absurd proposition that we would laugh off if we had better ideas. we’re going to whiff and whiff badly and frequently when we hire this way.

so, the hiring process tends to optimize for the least bad rather than for the most potential. optimizing for the least bad means being able to say, “well, that didn’t go well, but he had four years of web development on his resume and didn’t swear at anyone in the interview, so who could have known?” it’s not that hiring managers, by any means, set out to make bad hires or that they don’t care; rather, they face extremely difficult tasks and do their best not to blow it.

becoming a safer bet

what this means is that entry-level candidates need to find ways inside the cocoon of diligence theater. if you want to frame the job search correctly for yourself, start thinking in terms of, “how do i make myself a safe bet?” or, more bluntly, “how do i make it so that no one can be accused of poor judgment for hiring me?”

first things first. go out and find any relevant programming experience that didn’t come in a classroom or bootcamp. have you ever beefed up an excel sheet with macros? gotten paid $22 to make a website for the pizza place down the street? collected a bribe to do someone’s programming homework for them? (just kidding about that one.) get creative and find ways to boost your resume to reflect programming responsibilities at previous jobs, even if that was not the primary purpose of the role.

next up, do a bit of job search hacking. go out and file a doing business as (dba) to make yourself an official business. now you can add to your resume, “freelance web developer at myamazingcorp” and be telling the truth. to beef this up, see if you can land a little bit of volunteer or inexpensive business to further bolster your cred. build that $22 pizza site. volunteer to build some kind of widget for a charitable cause. put this real, if flimsy-feeling, experience on your resume.

finally, round this out by developing an open-source footprint. bite the bullet and get involved with existing projects. build a thing and store it on github. develop a highly visible audit trail of “yes” answers to the question, “can you show me any examples of your work?”

putting it all together

taking these steps may seem fake to you. but many in the industry suffer from impostor syndrome and grit their teeth through the “fake it ’til you make it” phase. that’s what you’re doing here. these experiences that you manufacture and string together may seem contrived, but they matter. they take you from “complete unknown quantity that could make me look bad” to “slightly less unknown quantity that someone else asked to program, so i could always point to that.”

at the end of the day, looking for jobs becomes a numbers game, particularly at the entry level. having some work experience and/or public code to point to means fewer screened resumes, more conversations, and more chances to prove yourself — and, as a bonus, scraping together some initial development work will help you get better as well.

i’ll round out the post by bringing things back full circle. you mentioned showing that you care about doing things right. taking any opportunity to practice programming in a professional context shows that you care. contributing to open source shows that you care. donating time to showcasing your work on github shows that you care. and being able to articulate what you learned from those experiences in letters or interviews shows that you care and that you care about getting things right.

it could be that your boot camp program has an excellent placement record and you get a job no problem. it could be that companies in your area specifically hire at the entry level. maybe what i propose will be overkill. however, if you have the time and ability, it makes for a great hedge of your bets. for what it’s worth, these sorts of strategies, employed over the duration of my entire career, are what have helped me scratch and claw my way to my current position in life, such as it is.

have a question you’d like to ask me? please feel free!