Questions to Ask During An Interview

I've had a lot of jobs, and, over the years, I've been refining my list of questions to do my best to ensure that the company I'm interviewing at is a good fit for me. I just went through the job search again, and asking all of these questions helped me determine that Test Double was the right place for me. I cannot stress enough the importance of asking questions in the interview. When I was first out of college, it sounded like I needed to ask questions to impress the interviewers. The truth is that interviewing is a two-way street, and asking questions is how you can find out if the company is the right fit for you. Not asking the right questions is how I've ended up at a lot of places that just weren't right for me in the long term. You should feel free to either use this list verbatim or use only the questions that are relevant to you and your needs. I also listed additional resources at the bottom. I also keep this list up-to-date on Github.

Culture

  1. How does the engineering culture differ from the overall company culture?

  2. Can you give me an example of a mistake you've made here, and how it was handled?

  3. How often do you pair?

  4. When something goes wrong, how do you handle it? Do devs get shamed for breaking the build?

  5. How are disagreements solved - both technical disagreements and other kinds?

  6. What happens when personalities clash?

  7. How flexible are work hours?

  8. What tools do you use for remote collaboration?

  9. How do they work together and ensure good communication and collaboration?

  10. Can you tell me about what I can expect from the interview process?

  11. How many hours do people work in an average week? In your busiest weeks?

  12. How often are there emergencies or times when people have to work extra hours?

Dev Process

  1. Who sets deadlines and what happens when people fail to meet them?

  2. Can you walk me through your development process, from a ticket or task to code on production?

  3. What checks and balances are in place to make sure people don't make big mistakes or repeat mistakes

  4. What is your build process like?

  5. How does this team plan projects and create deadline estimates?

  6. What is the median age that an issue will be open for?

  7. Who is responsible for doing deployment? How often do you deploy?

  8. Is there a written roadmap all developers can see? How far into the future does it extend? How closely is it followed?

  9. How often do you have meetings? Are there any scheduled/standing meetings?

  10. What’s your approach to technical debt?

  11. Describe your deployment process – how do you find bugs in your team’s code?

  12. Do you have a QA team?

  13. Do you have style guides?

  14. How does engineering work get assigned?

  15. How are technical decisions made and communicated?

  16. Would I need to be on call? How often? What is the SLA? How often do people tend to be paged? How often is it a real emergency?

  17. What does your stack look like? What languages/tools/etc. do you use?

  18. What sort of growth is available for senior engineers?

  19. How does your company support the growth of junior engineers?

Soft Skills

  1. Technical capabilities aside, what soft skills would make someone successful in this role?

Company

  1. Are there times of the month, quarter, or year when the team is most busy?

  2. Tell me a little bit about your team onboarding process.

  3. How is employee performance evaluated?

  4. Is there a budget for employee education/training/development/etc.?

  5. Is there support for conference attendance?

General

  1. What accomplishment are you most proud of since joining the company?

  2. What size is the team?

  3. How many total development teams?

  4. How much vacation do people get? Sick leave? Are they combined or separate?

  5. Do people check in when they’re on vacation? How often?

Additional Resources

Culture Queries

The Cut: Best Questions to Ask in a Job Interview

Julie Pagano's Job Search Retrospective

Julia Evan's Questions I'm Asking In Interviews

Julia Evan's Compensation Questions

The Mental Impact of Tech Interviews

I just watched this excellent talk by Zack Zlotnik (given at Code & Supply in Pittsburgh). I think every developer involved in the interview process should listen to this talk. Even if you aren't involved in the interview process, if you have interviewed anywhere, this is a great talk to watch.

Two slides in particular really struck with me:

In my experience as both an interviewee and an interviewer, all of these points are 100% true. Usually, about half way through my job search, I'll feel worthless and stupid, sure that no one will ever hire me. I've had an interviewer interrupt me midway through a white boarding problem and tell me that I wasn't quite the level they were looking for. Could I do the job they were asking? Definitely. I know I have routinely performed well in every job I've been given. However, white boarding routinely terrifies me and I've only gotten slightly more relaxed the more I've done it. I've always done better in a pairing session or, heck, just coding on a laptop in front of people. I've seen people hired through whiteboard interviews who are not good at their jobs. Zack has some good suggestions on how to improve the interview process that I think everyone should take into consideration.

Getting Your First Job As A Software Developer

Preface

This post is aimed primarily at people who are transitioning to another industry, not new grads. New grads will probably get something from this post, but they are not the primary audience. With that said, this post will discuss primarily getting a job as a web developer since, not only is that what I have experience with, web dev jobs are usually the ones that junior developers can get.

Getting the Interview

In some ways, this can be the most daunting part. I'm going to break this up and hopefully help you to see that you (yes YOU!) have what it takes to apply.

Getting Your Resume Ready

One thing I always tell people is to make their existing jobs as technical as possible. For example, when I was applying to my first software developer job, I made my job at Home Depot (which was a PM job) sound like I did way more development. I did all the things that I put on my resume, but I emphasized the more relevant tasks and did not mention that my day to day was mostly working in Excel. Did you optimize a process at work? That shows how you can problem solve! Did you write a script to help you analyze data? Definitely add that. Also, writing actual code is not the only skill needed by developer. Chris Doyle, CTO of Pretty Quick, does a good job of summing this up (slightly paraphrasing from tweets):

There are many valuable dev skills besides code, many of which you probably possess! Start there.[1] Also, your dev skills may be relatively small, but it doesn't mean they aren't already useful.[2] A junior developer sent me a cover letter identifying a potential UX improvement in my site, saying "This is something I could help you with."[3] That was such a concrete demonstration of initiative! They were an immediate favorite who was ultimately hired.[4]

For new developers, I expect to invest in their training, so it's really about "are they going to multiply or waste effort".[5] I do consider their current ability and have a low minimum bar, but gaining confidence in trajectory is much more important.[6]

What are these other valuable dev skills? Chris has created a whole list of developer competences. Don't worry if you look at that list and feel like you are missing a few. However, this list should help you decide what to include on your resume. For example, if you are currently in a customer support role, you are probably very good at suggesting possible causes for bugs! For more of my thoughts on resumes, see my post on the topic.

Creating Your Portfolio

This part of applying to jobs because less critical as you have more relevant experience. For example, a visit to my github or gitlab pages would make one think that I never coded! False... all my code is just proprietary and I invest my time in PyLadies vs OSS. Works for me because I have former employers and coworkers who will back up the quality of my code. If you are starting out, you need to show it. As Carlos Alonso said, as a junior developer, "your public code is the most important part of your CV." Dustin King recommends "writing a small game or other fun demo and putting it up online with code." Your project doesn't have to be huge, but you should have a friend QA it and make sure that there aren't glaring bugs. My project ended up being a choose your own adventure game that was part of going through Zed Shaw's Learn Python The Hard Way. However, I would recommend going a step further and building your own web app prior to applying. See the end of my "Getting Started As A Developer" post for more suggestions on how to get started with that.

Finding Jobs To Apply To

How do you even find jobs that are available? There are many great job boards out there, my favorite being Stack Overflow Jobs. But don't stick with just one. Search any job board that you can find and, as Christian Steinert says "try not to only consider common tech companies. Others (like financial services) might offer interesting stuff." At this point, most companies have at least a few software developers on staff. If there's a company you love, look at their job board. If it looks like they have a few technical jobs, reach out! Being passionate about a company's mission/product can often get you pretty far. As an example, if I lived in San Francisco, I would be hounding Betabrand until they hired me. If you have extensive experience in a field, look at companies with that focus so that your past experience can be even more beneficial. For example, if you are a biologist by training and looking to switch to development, you might find a place like AddGene to be a good fit. I, personally, have also enjoyed working with recruiters, like Talener in Boston. At bare minimum, they will get you in front of a ton of companies and get you in for interviews. Even if none of those pan out, it will be good practice and you will be better prepared when you find a job you are really excited about. Also, don't forget to milk your own personal connections! Do you know anyone who works at a company that's hiring devs? Contact them, see if they can meet you for coffee (buy them a coffee), and talk to them about what it's like to work at their company and their hiring process.

Now that you have a long list of job postings, you maybe are starting to notice that they all seem to say that you need experience with all these different languages, maybe one of which you have used... how can you ever be ready? GOOD NEWS! Most job postings are wish lists. Yes, even the parts that say "Required" are often negotiable. If a job sounds interesting, you should apply. Let whoever is reviewing your resume determine whether you are qualified. The only phrase that should give you pause is "Senior". If a job posting is looking for a "Senior Application Developer" or something like that, the hiring manager is unlikely to hire a junior person instead. Even so, if it's a company that you are really passionate about, reaching out will not hurt.

Acing the Interview

Before

One way to prepare is to work through a list of common interview questions and maybe a few exercism problems. Almost every interview I've had has also asked questions about SQL. Given that every job I have had has required me to use SQL in one form or another, I would recommend learning a bit before applying to any job. If you aren't up to speed yet, work through exercise 12 of Learn SQL The Hard Way. It looks like most of the lessons probably aren't too time consuming and it will be well worth your time!

During

I wrote my own "Job Search Retrospective" last September which talks about some of the things that I did in my most recent round of interviews that made me feel a lot more confident. As a junior, the most important thing to remember is that it's ok to say "I don't know" or "I don't know, but I was reading about this recently and I think it is [x]". An employer who you actually want will not be expecting you to be super knowledgable about development at this point. Stay calm on just make sure all your awesome qualities are on display. Most importantly, don't forget to ask questions!

After

If you aren't sure that you did very well during the interview, don't despair! You still have time to make a good impression. Going back to Chris Doyle, he had a person who sent in a refactored version of a coding exercise they did during an interview. This is such a great demonstration of initiative and also that you continue to consider and think about your solution even after you have "solved" the problem. It is good to send an email to the interviewer and thank them. That's a perfect place to add in "and I've been thinking about that problem that we did and I think the solution could be improved by [x]".

Starting the Job

Getting the Offer

The only advice that Mr. Sam Phippen threw out really struck a cord with me:

Charge. More. People entering the industry consistently underestimate their reasonable salary band by about 20%.

This hit me because, as of recently, I was underpaid by about 25%. To get an idea of what other places are paying, look at sites like Indeed and the recent Stack Overflow Developer Survey. If you find out after the fact that you have undervalued yourself, you can fix it, but it takes a while. I speak from experience.

Doing the Work

Never feel bad about asking questions. Take advantage of the senior devs that you work with and learn as much as you can from them. If your company supports pairing, pair program as often as you can. You will learn so much more so much faster that way. Also, take charge of a project or a feature. That doesn't mean you have to do all the work, just that you are taking responsibility for making sure it gets past the finish line. Along those lines, @codepaintsleep says:

Don't get stuck with grunt work just because you're junior. Push your knowledge when there's more experienced people to help! Also, don't write off grunt work as grunt work. Learn from everything!

To give an example of how you can learn from everything, I am covering for a coworker and working support this week. I am not doing any actual coding. However, the amount that I have learned about how our system works and what our users want in just a week is incredible. Learn. From. EVERYTHING.

Postface

I hope you got something out of this. If you think I missed something, feel free to comment on the post or contact me.

Job Search Retrospective

Wow what a month. I’ve been interviewing for a little over a month now. Two weeks ago, I quit my job (post on that mess coming up in a a few more months) and somehow got a job offer the same day. This has definitely been my shortest job search (time when I submitted my first application to first offer), so I wanted to share what I think has been different.

Finding Potential Employers - Recruiters & Networking

So first things first… I may run a fairly large meetup group, but I’m actually pretty bad at networking. If you are a networker and can go to a ton of meetups and talk to people, that’s the best way, hands down. First interview I got was because I went up to someone who I knew was hiring at a conference and talked to them.

If you aren’t much of a networker (like myself), working with recruiters is the way to go. If you are in one of the areas they serve, I have had really good luck with Talener, their Boston office in particular. They have put me in front of some great companies and I’ve had a ton of in person interviews as a result. 

Many people say that you don’t get anywhere from submitting your resume just from the company’s website. NOT THE CASE! I got my last job like that and, during this search, I got a great interview by doing that.

Now that the interviews are lined up…

Interviews!

The biggest change is obviously experience. Time definitely makes each round of interviews a bit easier! There were a few other things that made it a bit easier though. 

The first was inspired by Julie Pagano’s own job search retrospective. I’ve never been very good at asking a bunch of questions, but I looked at the questions she and Julia Evans asked and took a bunch of my favorites. I had a notebook and wrote out all the questions and all the answers. This helped immensely because, not only did I find out more about the companies and how they worked, but it also helped turn the tables a bit to have me interviewing them. 

The second was that I finally actually thought of a good answer for ‘Tell us about an interesting/challenging problem that you have solved and how you did it’. I was asked variations of that question at almost every interview and this is the first year I felt I had something to talk about. I was just talking to a junior dev about this question and, really, anyone who has solved any problem with code should have an answer to this question. If you have a project, you must have created it to solve a problem. If you had a bug in your project and fixed it, there’s your problem. Sure, it’s not the most interesting, but you will get better and better answers as you gain more experience, and employers recognize that.

And the one thing you cannot forget in tech interviews, WHITEBOARDING. Three years into this and whiteboarding is still nerve-wracking and I still feel like I’m awful at it. One thing I have learned: how the interviewers interact with you while whiteboarding tells you a lot how they would interact with you when actually problem solving on that job. If someone is making you feel stupid while whiteboarding, then you probably don’t want to work with that person. On the flip side, If you are having a bit of trouble and the person interviewing you is actually helpful, then that is the type of person that you want to work with.

Overview

Interviewing is tough. No matter what level you’re at, you’ll get people who will tell you don’t have enough experience for the job. Don’t sweat it. It just means it’s not a good fit… you’ll find a good fit somewhere else :D

Stop Undervaluing Yourself

TL;DR - Almost all interviews suck, don’t undervalue yourself because your interviews aren’t going that great.

I had a talk with one of the women in my programming group last night. She has a masters in CS, almost 2 years of work experience, and was still referring to herself as a junior developer. I spent about 30 minutes just repeating to her that she was not junior, just a regular developer… who does have experience! And education!

What prompted this total downturn in self-confidence? Interviews. Unless you are at the top of your game (in that case, good for you!), programming interviews are some of the most stressful things ever. More so than most other jobs, a rejection usually ends up sounding like they just don’t think you are smart enough, versus not a good fit. During my last round of interviews, right before I got a job, I had a bad run and starting feeling like I was in the wrong industry, stupid, and that no one would ever hire me again. On a normal day? Almost never feel like that. But both times I’ve done extensive interviewing, that is always the end result.

Why do I bring this up? Because if you are interviewing right now, don’t let the interviewers get you down. It’s not your intelligence or talent that they are rejecting. No one can really get to know you during an interview. At some point, you’ll go into an interview and they will ask only questions you can answer (or can figure out eventually) and that will be the place that is a good fit for you. Not the place that asks you weird logic puzzles until you are so mentally exhausted you can only babble on about how ‘code is nice’. Interviews aren’t just for the company… you are interviewing them. If the interview is super stressful, then it’s probably not the right place for you… but you will find that right place!