“The brick walls are not there to keep us out. The brick walls are there to give us a chance to show how badly we want something.” -Randy Pausch, Last Lecture
Breaking into tech when you are not formally trained in its dark arts is daunting. Without a C.S. degree, the challenge looks like a giant brick wall, wholly immovable and seemingly in place specifically to keep you out. This situation is my experience, and it is the experience of thousands of people looking to make meaningful change in their lives. Like ancestors paving the way so progress may be easier for descendants, the aim of this blog is to outline strategies for overcoming the wall and maintaining momentum once you find yourself on the other side.
First, the briefest of background info for context, then straight to the meat. My background is in art and science. While briefly pursuing a degree in Fine Arts, I eventually made the switch to Environmental Sciences and Biology. I love science, and really wanted to find an avenue to grow pertinent skills without another capital investment for a graduate degree. Enter code school and the wall. It’s been a few years now, but as a painter and science tech, the transition to programming was foreign and frankly, scary, though not as much as I feared.
When I started programming and learning the basics, I began to notice something. The process of breaking down large challenges into small chunks and slowly testing my own understanding against reality as a method of learning matched in broad strokes to the scientific method of hypothesis formulation and testing. Aha! An anchoring thread to latch onto. And better yet, the thrill and satisfaction I gained from creating simple websites from my mind’s eye gave me the same intoxicating rush I valued so much when painting and creating art. These observations coalesced into something very important, and is foundational to this blog – healthy motivation.
Healthy motivation will power your motor when you need it most. It’s your “why” and you’ve got to have it or you’ll quickly crash and burn. Motivation looks different for everyone. Some are motivated to simply create a thing, whatever it takes, some want to find avenues for contributing to the collective social or environmental good, while others are motivated by the challenge of programming, and love the process of improving their skills. I can’t tell you how to find your motivation, but I can tell you that finding it is important, and I believe the healthier it is, the stronger it will be over time. There are enough mental stressors in programming, so having motivations that in some capacity encourage mental health rather than strain it is essential.
“Do the best you can until you know better. Then when you know better, do better.” - Maya Angelou
Throughout code school and beyond, I’ve learned to appreciate continuously betting on myself and my ability to succeed. This persistent belief is different than the mindset of sprinting hard, taking a leap of faith, and hoping it works out. Binary thinking such as that where you either make it, or you don’t, devalues the gift of failure and limits invaluable experience. Rather, it’s more sustainable to wake up every morning and bet on yourself to succeed in the long game. When I attended code school, I would often work a couple of hours after class on side projects, but never felt the need to punish myself. With work on the weekends to look forward to, and having been bit by burn out before, I knew the importance of persistence and trust in the process. Whether you’re in code school, in the midst of the job hunt or some other phase of your software development career, it’s critical to remember that this is a marathon, not a sprint, and you are yourself enough to scale the wall eventually.
“Now, go find your team and get to work.” - Leslie Knope, 2035 University of Indiana Commencement Speech
Part of betting on yourself is being discerning enough to understand you can’t do it alone. You will become stuck, frustrated, and not sure what to do next. Having a team to work with, even informally, can provide essential feedback and advice. Their spark can lead you to knowing better, and once you know better, you can do better.
I have always strived to build community at my places of school and work, especially when the challenge is especially new or large. I remain super close to other members of my cohort from code school and college and continue to spend a lot of time with them as we progress in our careers together. At Untold Studio I continue to build deeper relationships with our team as we trust and rely on each other on a daily basis, celebrating successes together and working through problems collaboratively.
It should be obvious that who you choose to spend time with and work with is very influential for you. Your work habits and tendencies are consciously and subconsciously malleable and will naturally drift toward those you spend time with. Knowing this is inevitable can empower you to make wise decisions about who you spend time with. Friends who can help with advice, provide an ear for your thoughts, worries, and plans, and who are eager to see you succeed can have an immeasurably positive impact on your life and journey into the world of tech. Surround yourself with folks who challenge and inspire you to improve and perform at your best, and do your best to return the favors. We all benefit from receiving support and validation from time to time, especially when starting out. So when you’ve found your team, whether it’s at code school, through meetups, or your job, invest in them, and know it’s time to get to work.
Oh, networking. Not everyone will be on your team, and extending beyond those select few, it’s useful to know every professional interaction is a network interaction, whether or not you’re aware of it. Sound intimidating? Not necessarily. Don’t change your behavior, it’s just something to be aware of. Be kind and honest to those you come across and your reputation will take care of itself, and that is the most important piece.
From a nuts and bolts perspective, while I’m not the biggest proponent of attending #all-the-meetups, I do think they hold a lot of value. Whether you’re meeting other folks in the field or learning about new topics, I associate it in an odd way to the utility of LinkedIn. You can see interesting articles and “connect” with others, but more than anything it will allow you to maintain a pulse on the community so you always feel grounded and integrated. This feeling can help you maintain focus and ease any doubts whether you’re on the right track on a macro level. So when you meet others in the field, be yourself, try to remember their name, and send a LinkedIn request. The reality that most opportunities result from your network is as true today as it ever was. You don’t have to be an all-star networker, but you will be fine as long as you’re doing something.
Endure the grind and eventually you will create opportunities. Code school for me was an intense grind. It’s designed to be, and that’s the beauty of it as it prepares you for the schedule of a software engineer. It is also well organized, and courses have been improved over the years to maximize their effectiveness. No matter how well you do during code school, afterward will be more difficult. Anyone looking to break into tech regardless of vector knows this period well because it’s the time you start searching for The Job. It’s the wild west, there’s no rule book, and you will often be left feeling isolated and frustrated. It’s time to start putting the lessons into practice: stay motivated, know it is a marathon, find your team, and don’t be afraid to network. It is the art of breaking into tech.
Of course, there is a certain social science at play as well. When you run a similar situation again and again, it’s common for patterns to emerge, and you can begin to take advantage of these observations beyond what soft skills alone can accomplish. I’ve had the pleasure of interviewing with way too many companies, and have come away with tips that are more science than art:
You will have much more success getting through the door if you know someone on the other side. Utilize this, but don’t abuse it.
Cover letters are read by humans; design them as visually pleasing and not too long. If applicable, mention near the top how you heard about the opportunity through your contact and how you know your contact.
Briefly associate your interest for the position with your honest, healthy motivation.
Use brief, but specific details regarding your past relevant work which highlights why you’re qualified for the position.
End with a friendly call to action, e.g. “I look forward to discussing more with you about this position. Reach me anytime by phone or email.”
Resumes are less likely to be read by humans, unfortunately. Thus, visual style is less important than the cover letter, but don’t neglect it completely. As more companies are using programs scanning resumes for key-words, take advantage of this to insert many key-words relevant to your experience and qualifications. Don’t be afraid to go over 1 page, but keep your content organized and otherwise dry; avoid needless exposition.
During the job search, prepare for interviews by working on… sigh… code challenges. You’ll be hard pressed to find huge advocates for code challenges to assess candidates, but they remain extremely common due to lack of significantly better options (other variations of challenges are becoming more common, such as take-home project challenges, but there’s no special advice for those, just do your best).
A benchmark to strive for is completing 1-2 code challenges a day. Start with the Easy problems. Don’t worry, they will get harder quickly and force you to stay sharp and adopt new techniques even if you never use them again.
Equally important as your solutions during these technical interviews is how you communicate your thoughts and planning during them. Knowing this, you’ll see the utility in practicing communicating your process and strategy with your team. I struggled a lot with this portion when first out of code school, and it revealed a big weakness in my candidacy for a lot of positions. Practice is key.
Work on a side project you’re passionate about. The better presentable pieces of work you can show and talk about, the more real examples hiring managers can anchor themselves to when considering your candidacy. If you’re considering multiple side projects and are unsure between focusing on one large project, or several small ones, opt for the larger project. It will be better for your development in the end, and give you more depth to your conversations.
Keep your head up. Understand that luck can be a big factor, and give yourself grace if you’ve strung together a good streak of failures. Improve the process based on your experience, and know it’s a matter of time.
Easier said than done? Perhaps. But I find that sentiment true with most actions, and wave such excuses away. These strategies work well in the grind, because you’re demonstrating an authentic personality, and a hunger and ability to learn, which helps alleviate hesitancy many managers harbor when considering candidates outside of the traditional C.S. pathway. Focusing on these points to demonstrate your value will inevitably lead to opportunities.
Eventually, all your work and dedication will culminate into the magical email or phone call and soon after you’ll show up for your first day of work. This next piece of advice may seem obvious, but from experience I’ve seen the importance of knowing when you’re in the middle of the opportunity, and making the most of it.
My first job in tech was as a contract QA engineer. It was not the position I was necessarily aiming toward, or even interviewed for, but to me, it was an opportunity. My manager knew I wanted to do software development because I communicated that clearly. To make the most of my opportunity and achieve the goals I desired, I knew I had to build value into my new team, and show enthusiasm to take on more difficult tasks. Eventually, I was given more programming tasks, promoted, then hired in a short amount of time until I was helping build microservices in Golang. It worked. Even though I still had (and have) so much to learn, I had reached the top of “The Wall” and broken through into tech.
It was looking back that I saw the importance of building value in your new team when you finally have your opportunity. To do so requires honesty, eagerness, and kindness, all different facets of effective communication. Everyone understands you don’t know everything, so don’t pressure yourself into seeming like you do. Saying “I don’t know” is perfectly okay given you’ve done due diligence and have attempted to find the answers yourself.
Intentionality here is a big help when embedding yourself into any new team. It blends the aforementioned honesty and eagerness, and it can look like being forward with your managers when looking for feedback, relaying your intentions for solving specific problems, and inquiring about design decision specifics. It may seem like over-communication, and while you don’t want to overdo it, I’d argue it’s better to go over than under at this stage of your career. Small check-ins and sanity checks can go a long way toward building trust with your team that you’re on the right track with your tasks. Note that this is different than trying, giving up, and simply asking for help so often that work is virtually being done for you. That overreliance on help won’t serve your development and it will erode confidence in your peers if it happens too often. Eventually you will demonstrate you know your stuff, and the trust will grow with your confidence to a point where the need to communicate as much may lessen, and you start to gel harmoniously more and more. Remember, your team is there to help you succeed and they believe in you, or else you wouldn’t be part of that team to begin with.
So, at this point, you’ve made it. You’ve scaled the wall and broken into tech. It might not even feel like you’ve made it, because of course, being in “tech” is not a static destination. There is always more to learn and room to improve. But know this is not easy, and if you haven’t taken time to appreciate your progress yet it’s well past time to do so. A healthy, consistent motivation will help you maintain a desire to improve over time to build better and cooler stuff throughout the years. The marathon continues, so you may as well enjoy it. As you look back and look ahead to all the new challenges that await you, something will begin to dawn on you if it hasn’t already. You’ll realize it was never a brick wall, but a steep brick road, and one that never ends. You got this.