Tag Archives: software engineering

The Dreaded Technical Interview

Jobs, ,

What’s the worst thing about looking for a job in software engineering? In my opinion, that would be the technical interview.

It’s easy enough to talk about projects you’ve worked on or how you would be a good addition to the company, but it’s another thing to be able to show off coding skills on the spot, especially for a junior engineer.

I’ve completed (completed may be a strong word) several technical interviews. Each one a little different than the last. The worst was for a gaming company in town. I had twenty minutes to code, using C++, a problem they gave me. While normally this would be no big deal, my heart started racing when I knew I only had the 20 minutes AND two people on the zoom call were watching my every keystroke. That was horrible. Let’s just say, I did not hear back after that.

Other technical interviews are a little less stress based. I applied for a job at Amazon and went through multiple rounds of technical interviews. These were all timed as well, but didn’t have somebody watching me. It also consisted of multiple smaller exercises, and they mainly wanted to see what thoughts I could apply to these problems, if I didn’t finish it. I did well, was invited to do some in-person interviews, but ended up not pursuing any further after that because of a different job opportunity.

I think my favorite (favorite, yet again perhaps a strong word) technical interview was for my current company. There was no coding specifically, the hiring manager even mentioned that he can look at my portfolio to figure out my coding ability. We talked concepts. The manger provided different scenarios that fictional users may encounter. He wanted to see how I approached it from a high-level view. For example, one scenario was a new parking garage keeping track of cars that come in and go. The prompt was specifically vague, in order to see where I’d go with it. They’re looking to see if people create user stories, ask for more details, see prompt for what needs to be fixed, find out what external pressures there are, etc. The idea was to see how I would handle a new project and if I could ask the right questions while setting up something that the user actually wants, not just what the user says they want.

I liked this idea a lot more than the usual “here’s a problem, code it to make it work”. I think giving a more high-level view of a problem and seeing how somebody would handle it is more of an insight to a candidate than seeing if they can make a small problem work under pressure.

Let’s just say, I’m happy to be working for that hiring manager now. He clearly appreciates different views that his team members bring to the table. It creates an interestingly diverse team all working towards the same goal.

I got the job! Now what?

Jobs, ,

Have you ever started a new job and had no idea where to begin? I’ve had that feeling, 8 times specifically since I first graduated college in 2010. Sometimes I can blend into the position and soon run with it. Other times I feel lost for months. It may be worrisome, but let me tell you, it always gets easier.

I’ve worked in the local news industry for 12 years, starting as a photographer’s intern, later trying out producing, then finding my niche in broadcast directing.

Remember this scene from Star Wars?

Yeah? Well that “control board” is called a switcher. We use it (or automate as of recent) for directing local news. When I first became a director, that board was intimidating! There’s buttons, there’s menus, there’s external devices. There’s anything and everything Grand Moff Tarkin would want when blowing up planets. As a new director, I thought I’d never figure it out. Things take time though, and sure enough, I became an expert. So much so that I was teaching others the intricacies of the switcher just a couple years later.

Fast forward to today. I officially switched careers and landed my first software engineering job with a company that makes broadcast equipment (how fortuitous!). The first two weeks I spent just playing around with the equipment, not even looking at code. That was challenging enough. Then they gave me the keys to the (source code) kingdom. There’s millions of lines of code, most of it legacy. By legacy, I mean there are chunks of it they still use that are dated in the ’90’s.

I’ve been here nearly 5 months, and I’ve barely scratched the surface. Many times I still feel overwhelmed. I have to remember from my experience with new jobs though, it gets better. It’ll take some time to get used to developing software and the intricacies it entails.

If I can provide anybody in similar situations or for many students looking for their first job in a new industry, this is what I’d say: Always ask questions! Find those people at your new job you trust and pick their brain. You’d be surprised how many people like to share their knowledge with junior developers. Embrace code reviews and do your best evaluating pull requests. Be open to trying new technologies and always push to do things outside of your comfort zone. Most likely, we won’t be in this same job 5 years from now. Develop skills in the real world that are useful. Don’t lump yourself into coding in just one language.

Sometimes new jobs are fun, most of the time they are terrifying. I definitely get a sense of imposter syndrome with some positions. Always remember though, they hired you for a reason!