Getting Hired at Faithlife

Interviewing is hard. It is difficult to measure the whole of a person’s experience, expertise, and potential in such a short period of time. As hard as it is for me, I know that it is even harder for you. I do my best to make everyone comfortable, but it is hard to help people get past the nervousness. I think it will help if you are prepared. So, in an effort to help you do your best, I’ve prepared a few notes on getting hired at Faithlife.

Your Interviewers

First, a little bit about your interviewers. We are all engineers actively contributing code at Faithlife. We all volunteered to spend time with you and we all want you to do well. If there is something we can do to make you more comfortable during your interview, let us know.

How to Apply

The Minimum

Send us your GitHub, LinkedIn, StackOverflow, or a quick note. If it can be established that you meet the requirements from what you sent, you will hear from a recruiter.

Make an Impression

Make a good impression. It may be enough to get you a phone interview if you are a little short of the requirements on paper or carry you through a misstep in a subsequent interview.

Before you do anything else, do some research on Faithlife. Be able to answer this question: “Why do you want to work at Faithlife?” You will be asked this question in at least one of the interviews; likely all of them. You should be able to answer it. Write a cover letter (which answers the aforementioned question) and attach a resume. If you want to stand out when I evaluate your application:

  • Be interesting. A well written cover letter will make your application stand out. Write something that highlights your personality. Help me get to know you.
  • Contribute to one of the Faithlife open source projects
  • Contribute to someone else’s open source project
  • Do something else interesting. When I applied, I spent about an hour putting together a simple Bible search sample program using Lucene and C#. It was very basic, but demonstrated that I could write functioning code and knew something about Faithlife’s products.

Phone Interview

You got a response and your first interview has been scheduled. Great job! We are going to sit down for 30-45 minutes and chat. My goal will be to evaluate whether you have a basic understanding of data structures and proficiency with your preferred language. I will ask some questions and you will write some very basic code. FYI, when I ask you, “what is your preferred language?” which language you choose will not have any impact on your outcome. It will just tell me which questions I should ask. Choose the language you want to answer questions about. Your preparation should include:

  • Practice answering interview questions on data structures and your preferred language.
  • Practice writing code on one of the many practice sites. Pick your favorite, but here are a couple examples:
  • What is important to you about your working environment? The people you will be working with? The projects and products you are working on? When you have the opportunity, ask good questions.

Homework

We are experimenting with replacing a portion of the in-person coding with a homework project. If you are selected to participate, you will be assigned a small project to complete on your own time. Pay attention to style. Make sure it compiles and functions as intended. Take some notes. Be prepared for an in-person code review with questions focusing on decisions you made, implementation details, etc. If you have time, do the bonus work.

Panel Interview

Nailed it. Your panel interview has been scheduled. You will be meeting with 3 engineers for about an hour and a half. We will discuss your past work and you will write a lot more code. Remember, your interviewers want you to do well. We are all pulling for you. Your preparations should include:

  • Review any recent work that you’re proud of and be ready to discuss it in detail. Demonstrate your passion for these projects and what you learned from each.
  • More practice writing code on one of the aforementioned practice sites.
  • Practice testing your code. Pay attention to base and edge cases.
  • Practice talking through the code. Demonstrate that you understand what it’s doing and explain why. An incomplete solution that is well defined with a plan explained is usually better than a complete solution that is not articulated clearly.
  • What is important to you about your working environment? The people you will be working with? The projects and products you are working on? When you have the opportunity, ask good questions. Sound familiar? Don’t be afraid to ask the same questions. Get some different perspectives.

Pair-programming Interview

Congrats! The process is selective and you are among a very small number of candidates that make it to the pairing interview. You will be spending a day with us at either the Tempe or Bellingham office. What to expect:

  • When you arrive someone will show you around our campus and tell you about the different departments. Grab some coffee, or if you agree with me and think coffee is foul, grab a soda.
  • The interview portion will involve 2 pairing sessions, each lasting around 2 hours. You and your partner will be working on a problem, either real or from a set of interview pairing projects. We are evaluating your ability to communicate, collaborate, and ship working code. Your preparations should include:
    • Become familiar with one of the languages we use during this interview: C#, JavaScript, Objective-C, C++, or Java. You will be evaluated based on your experience, but building a basic understanding before you arrive will make you productive faster.
    • Before you get started, talk through the problem with your partner. Ask questions and build a plan together. We are evaluating your ability to communicate and collaborate as much as your ability to be productive.
    • Plan how you will test.
    • You may not finish the project. That is ok. Use the time you have to demonstrate your ability to solve problems with code productively and collaborate.
  • If you are with us on a Thursday, you will have an opportunity to attend “Demo day.” No need to prepare a demo. All of us (the engineers) and a few folks from the management and executive teams meet weekly to show off what we are working on and learning.
  • After demos, you will head out to lunch with a few engineers. This is a good time to ask questions about the culture at Faithlife and get to know some of your potential coworkers. Plan what you want to talk about, show passion and interest here.
  • Ask the good questions you prepared again.

Interviews with the Development Manager and the CEO

These may be held the same day you are on-site or at a later date, depending on availability. I haven’t performed any of these interviews, so I don’t have much advice. Ask good questions. Research the people who are interviewing you. Bob (our CEO) has written many helpful articles; like this one. The research will give you insight into how Faithlife runs and will likely inspire a few great questions. Good luck!

The Aftermath

If it went well, you have a start date! Congrats!

Connect with your interviewers and the other folks you met at Faithlife. Introduce yourself and ask for advice on preparing for your first day. If you have trouble finding those folks, connect with me. I would love to chat with you about your experience interviewing and answer any questions you have about working here. During your first few weeks at Faithlife, take some time to reach out and invite your interviewers to lunch (if I was one of them, I’ll buy). Ask them what you could have done better. Tell us how we can improve. This is the only time we can give constructive, personal feedback about interviews. Any constructive feedback you have in return is greatly appreciated. We all want to get better. Embrace openness (core value!) and help us get there.

If it wasn’t a great fit…

Interviewing is hard and we don’t want to take a chance on a bad placement. If we aren’t a confident “Yes!” the answer is “No.” We pass on some possibly great candidates because there just wasn’t enough evidence in the process to convince us. We value growth (core value!), so we are working on improving our hiring processes. If you have any feedback about your experience, we would love to hear it. These are the two most common reasons we have to pass on people and what to do about them:

  • Candidate hasn’t been pursuing mastery of their craft. They didn’t show evidence of enthusiasm for software engineering. If this is you:
    • Start reading. This is a good list to get you started.
    • Learn the ins and outs of the languages you are using day-to-day. You should have a firm grasp of how those technologies work, why they work that way, and where those technologies start to break down.
    • We move fast. Constant growth is an expectation. If you aren’t already actively pursuing knowledge and improving your technical skills, start.
  • Candidate doesn’t know their own weaknesses or limits. If this is you:
    • Growth (core value!) requires constant self-evaluation and the pursuit of actionable, critical feedback. If you aren’t aware of your shortcomings, you may not be doing either of these, start.

Keep pushing. Give it a few months or a year, then give it another shot. There isn’t any rule against re-applying. The next time you apply, tell us about all of the things you have done in the interim to improve. Recovering and learning from failure shows maturity which is an important part of being an effective engineer.

Conclusion

Remember, it is safe to assume goodwill. We want you to do your best. We know it is a difficult situation and we want to make it as comfortable as possible. Take your time, take a deep breath, and take us up on our offer of a beverage. If you need it, take a break. Best of luck!

Thank you Auresa Nyctea, Dave Dunkin, Leigh VanderWoude, Patrick Nausha, Todd White, and all of the other folks that helped put this together.

Posted by Jared Wood on February 03, 2017