Curtis Branum

Doing DevOps in D.C.

Advice for your Full Stack Interview December 21st, 2018

I have certainly given my share of bad interviews. As I've grown a bit professionally, I often find myself on the hiring side of the table, interviewing Engineering talent to potentially join the company I work for.

Here are some items to consider that may help you to have a better interview experience.

Try Out the Product

If you are interviewing at a company that has a flagship SaaS product, sign up for it. Spend as much time as you can understanding which problems it solves, and how it works. It is surprising how many applicants completely miss the mark on this one.

Spending time with the product before your interview is an easy way to get a leg up on your competition. Be sure to let your interviewer know that you checked it out, and come with questions about how those features work under the hood, and communicate some enthusiasm around the opportunity of working on certain areas of the product that you are now familiar with.

Find Out What You'll Actually Be Doing

Too many engineers focus solely on tech stack and conveying their technical competency during the interview phase. While those conversations are totally necessary, nobody's work-happiness is defined by their programming language. Asking some of these organizational/process questions below will help you to understand what you're potentially getting yourself into, as well as convey to the interviewer that you are vetting them just as much as they are vetting you.

  • Which team will I be on, and what would my role be?
  • What are the key responsibilities of this team?
  • How many people are on this team, and what are their roles?
  • Who decides which projects will be worked on, and their priority?
  • How well-defined are the requirements for a typical project?
  • Are projects assigned to solo developers or are they shared?
  • Will you describe the Sofware Development Lifecycle at this company?
  • Will I be working closely with QA?
  • Do you utilize manual QA, automated QA, unit tests, or some combination?
  • Does every merge request undergo a code review, and if so, what is the process?
  • How frequently are releases deployed?
  • Who is responsible for deploying code?
  • Who is responsible for keeping servers online?
  • Does the company have clearly defined goals?

All of the above are fair-game questions for your interview, don't be shy. Overlooking process-related concerns may wind up causing you grief down the road if you are not careful and find yourself in a chaotic organization.

Talking Tech

Stick to what you know and are comfortable with. Resist the urge to name-drop the latest trend just for the sake of feeling those buzz words coming out of your mouth. It's fine to mention that you might have tried some things hacking around on your own time, but I would recommend taking ownership of the stuff you have production experience with, and keeping the conversation focused on that meaningful experience above anything else.

Have opinions! If you've been using javascript all your life, but feel totally blindsided when someone asks you what your opinion of javascript development is, you might want to take some time to sort out your feelings on that topic. Why is your web framework/language of choice the right one for you? What aspect of it would you like to see change in the future? Do you need to love your programming tools in order to love your job? Have you experienced a microservices architecture in production? Do you think it's an improvement over a single monolithic application? Dynamic or Strong Typing? Tabs or spaces? You get the idea.

Having opinions, while being open to debate, will help you be a better developer, and open the door to good conversations in your interview or with your fellow teammates. Being complacent and not taking a position will give the impression that you are not passionate about your craft, which is usually the truth of the matter.

Find Out Where They're Headed

Ask Engineering Leadership to describe the state of the company and what success looks like one year from now. What process/people/technology changes would that include? This is a great question that very few engineers think to ask that could surface information that otherwise might not be covered. If the answer resonates with you, you'll build excitement around the position. If not, perhaps it reveals a red flag that you hadn't otherwise uncovered.

In Conclusion

As a Full Stack Engineer, you are in very high demand. You owe it to yourself to interview a potential employer about the role and organization as thoroughly as possible in order to determine whether or not you actually want the job. Hopefully you gleaned something of value from this post! Good luck on your next interview!

© Curtis Branum