I’m posting my answers to these software engineering questions here, just in case anyone else finds them helpful! (Also, it gives me another link to share when I get asked these kinds of questions.)

How did you become interested in software engineering?

I wrote a bit about my coding bootcamp journey in a previous post.

Part of my interest in software engineering is/was related to the particular path my journey took. That is, while studying Bible/religion/theology, I always knew that “bi-vocational ministry” (ministering in a church setting while also making money from another profession) was on the table.

Whenever I thought about “careers that might be a good fit for bi-vocational ministry,” software engineering, web development, etc. were on the short-list. You don’t need a specific degree. You can make good money. You can work remotely. It’s not an especially emotionally draining profession (like, say, counseling, therapy, or chaplaincy). The list goes on.

As it turns out, I’m now “just” a full-time software engineer. I’m not having to balance things with working in a church setting. But it’s nice to know that I could have that flexibility in the future, if I wanted to.

And, in addition to all the ministry-related reasons that software engineering was on my radar screen, I really love learning things and solving problems. And that’s what I get to do each day as a software engineer!

I was born in 1991, so computers and the internet have always been a part of my life. I was always curious about how digital tools worked behind the scenes. After years of dabbling and tinkering in the shallow end of the internet, as it were, I was eager to take the plunge into the deep end of computer programming.

What does a typical work day/week look like for you?

Most days, I work from home. My company has an office here in Pittsburgh, but I’m not required to go in.

I’m expected to be available/contactable (via Microsoft Teams) from 8am-5pm Eastern. And there are various meetings I have to attend each day/week:

  • daily squad standup at 10am,
  • weekly 1:1 with manager,
  • weekly “town hall” meeting,
  • weekly “tech sync-up” chat with other devs on my squad,
  • bi-weekly sprint planning and retrospective meetings, etc.

Outside of the meetings and general availability, however, I’m pretty free to get my work done when/as I wish.

Now, I usually get all my work done between 8am and 5pm anyway! But if I have to step out for a bit for a doctor’s appointment, to drop-off/pick-up kids, to run a few errands, etc., I can always put in the time needed to get my work done outside of business hours.

What do you like most/least about your work specifically or this career in general?

I LOVE how my work requires me to continuously learn things and solve problems.

Sure, my work isn’t as “tangible” as, say, building a house. But, especially when compared with my previous work/studies in religion and theology, building software feels a lot more concrete!

Fixing a bug, getting tests to pass, building a feature and seeing it work for customers…all of these things are very satisfying to me.

However, the main downside is related: software engineering can feel very overwhelming because you’ll never know everything–or even almost everything–about the field. In addition to acquiring basic knowledge of programming, one of the main skills I’ve had to learn is how to keep making progress even when the task at hand feels confusing and overwhelming.

It’s taken some getting used to, going from being one of the well-informed “experts” when it comes to church, Bible, theology, etc., to being a complete n00b at software engineering!

But, even though the feeling of “I have no idea how to do that” is the main source of stress in my work these days, re-framing it as “I get to learn something new” is what keeps the work exciting!

In your opinion, what skills/abilities/personal attributes are essential to success in this field?

You’ve got to be curious. A lifelong learner. Which, importantly, doesn’t just mean “I enjoy knowing a lot of things,” but also “I’m comfortable with the uncomfortable parts of learning something new.”

Are you OK with realizing that you don’t know something? Or does that totally paralyze you?

When you realize that you don’t know something, is your first instinct to go learn more about it and figure things out? Or do you tend to avoid that area of uncertainty?

Furthermore, what about when you don’t know what you don’t know? How do you respond?

Can you tell me about the hiring process you went through? Either for your current job or others you have applied for.

One of the reasons I chose my coding bootcamp, Tech Elevator, was that they included a pretty robust job-search component to the bootcamp. As a part of this, they set us up with a handful (I think I had 5) of brief (15-minute) “matchmaking” interviews.

Tech Elevator develops relationships with tech companies, usually with a focus on companies that have a footprint nearby one of Tech Elevator’s campuses.

So, in my case, one of the matchmaking interviews I was assigned was with Proofpoint.

To be honest, I hadn’t heard of Proofpoint before the bootcamp. And, once I discovered that it’s a large cybersecurity company, I was SUPER intimated. In fact, I straight-up told that to the two developers who did my first interview: “Look, Proofpoint sounds amazing, but I don’t know if I’m cut out to work for a cybersecurity company with just a 14-week bootcamp under my belt!”

Those devs reassured me that, even though Proofpoint’s a cybersecurity company, that I was not applying for a cybersecurity expert role, but for a junior developer role. That calmed my nerves a bit!

After my matchmaking interview, which went quite well (and, unlike my other matchmaking interviews, was quite technically focused…getting a sense of what I had and had not learned at the bootcamp), I made it to a 3-part second interview. 3 back-to-back interviews (Zoom calls, in my case) with 3 different groups of 2 Proofpoint interviewers each. I spoke with a technical product manager, a QA manager, two mid-level devs, and two senior-level devs.

Only the 3rd sub-interview was the dreaded “technical interview.” A mid-level and a senior dev asked me to whiteboard maybe 2 different problems. (As they taught me in the bootcamp, I went into as much detail as possible while solving the technical problem(s), so we didn’t cover all that many different topics.)

The devs were quick to reassure me that I was not being judged on coding syntax, but rather on problem-solving approach. I could either code in the language I was most comfortable with or write pseudocode.

I was quick to say that, in the real world, I would approach a problem by googling to see if a ready-made solution (in this case, for string manipulation) existed. I even mentioned the library/tool that I thought could do what I was being asked to do.

And, looking back on the experience, that’s completely true. The coding problem(s) I was asked to do in the technical interview was NOTHING LIKE what I do each day as a software dev. I would never ever spend so much time trying to put together a string manipulation solution from scratch unless I had already exhausted other options.

But, hey, there are only so many different ways you can test someone’s problem-solving skills. At least my interviewers clearly understood (and told me) that this was obviously a very artificial situation.

Anyway, it didn’t go perfectly (at least not in my opinion), but I was able to come up with a workable solution to the problem and, more importantly, thoroughly talk through my thinking as I went. I felt very well-prepared by the bootcamp for my interviews.

BUT, I will say that, outside of my other matchmaking interviews, it was quite difficult to get my foot in the door for an interview for other positions. There were plenty of jobs I applied for that I either never heard back from or received a pretty quick rejection.

This makes sense to me because, without any industry experience or a Computer Science degree on my resume, why would the average tech company give me a second look? For all I knew, my resume was getting filtered out by an algorithm before a human even looked at it!

Again, that’s one of the reasons why I chose Tech Elevator, and it paid off. They developed a relationship with companies to get students initial interviews. And they trained us, as people who were pivoting into tech from a variety of other backgrounds, how to pitch ourselves and compellingly describe what we brought to the table.

What steps would you recommend I take to prepare to enter the field?

Keep going. Show your work. Steal like an artist (programmer).

Read those books above. Read The Missing README. Read the books recommended in The Missing README. Keep reading! (Need to learn how to read better? Read How to Read a Book. Seriously. It’s golden.)

Keep making friends and making things until someone notices you and you get a job! Then, keep making friends and making things!

Learn how to ask questions the smart way.

Keep learning. Your “to-learn” list should never ever be empty.

Don’t know what to learn next? Let your immediate problems be your guide. If you’ve got a job, learn what you need to learn to close your next ticket. If you don’t have a job (yet), learn what you need to learn to better align with job descriptions.

Need a bigger-picture overview of things to learn and be familiar with? I LOVE the “Developer Roadmaps” over at roadmaps.sh.

Need to get your sh*t together, life-wise? Check out these books below. Start with whichever book piques your interest the most!

I hope that helps! Do you have more questions for me? Let me know in the comments! Or use the contact form on my website.