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

Changing Careers

I have basically written this post before. However, I recently got the following email:

I'm an electrical engineer looking hard at web development bootcamps. How was your experience transitioning from engineering to software?  Did you do a bootcamp, self study, or something else?  The bootcamp is full stack and looks pretty comprehensive, but I'm just so nervous about such a big commitment. 

and oh boy did I feel like I had more to say. I ended up writing enough that I felt like maybe I should go ahead and put it in a blog post as well. I’m going to add some annotations to this to make my intentions even more clear. Here goes (again):

I actually found transitioning from engineering to software to be fairly easy. Hiring managers are more likely to take you seriously (versus if you had a philosophy degree [1]). Granted, a lot of what I’m going to say is assuming you currently have a job. If you do not, a boot camp is not a bad idea. If you do, a boot camp is 100% not worth it [2]. I’ve heard many people who went to boot camp say that they valued it for giving them projects and deadlines but that they basically taught themselves. If you require external deadlines to learn, that’s about all a $15K boot camp is going to give you. Here’s what I would recommend:

1) Find a language that does what you want to do. If you want to do more data-focused work, choose python. Web development? Ruby. Systems programming? Rust or C. There are a lot more (so. many. languages), but you want to make sure it’s common enough that there are resources and you can get a job. Then learn it. Not completely, but enough to get started on projects.

2) Practice and get feedback. Exercism.io is perfect for this. You can do exercises in any language and, once you’ve submitted your solution, get feedback from mentors and also give feedback to other users.

3) If possible, code at work. Automate tasks that you do regularly. When I worked at MailChimp, I was able to write scripts to automate log parsing. Again, this might not be possible! But think outside the box, because if you can do this, it can go on your resume under your current job.

4) Have one or two good projects on Github. These are projects you want to show a potential employer to effectively prove you can code. It doesn’t have to be huge! If you wrote a great script that is really useful, that counts. If you wrote a web app, that counts. Just get some friends to review the code, maybe do a bit of QA on the app and open up issues for things you want to fix.

5) Another alternative (or in addition if you are feeling extra ambitious) is to find an open source project or two that you find interesting and contribute. In many ways this is better because it means someone else will have reviewed your code. But it’s often harder to find a project that you feel confident putting up a pull request.

6) NETWORK. Oftentimes bootcamps tout this as a benefit of the bootcamp, but really they just send you to local meetups. You can do this on your own! Meetups are almost always free.

7) Review some basic CS concepts. I hate that people interview this way, but enough people do that it’s worth your time to do a small amount of studying. This video series by Rob Conery covers most of what you need to know, but you can also do a lot of googling because everything is out there.

8) Just start applying to jobs. Even if you don’t feel 100% ready. You’ll be applying for junior positions and no one interviewing you should expect you to know everything (or even most things). You might get questions that feel that way, but they are just trying to gauge your knowledge level. Or maybe they are assholes! But then you don’t want to work there.

Annotations:
1. There is nothing wrong with a philosophy degree! One of the best developers I know has a degree in Classics. However, many developers still think that having a liberal arts degree means you are less technical and will have more trouble as a developer. This is not true, but you might encounter it.

2. I know this is a strong opinion. And it’s just an opinion. I know great developers who went through boot camps. However, I am quite certain that they would be great developers without the boot camp.

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.

On Interviewing Developers

Just read this excellent article by Eric Elliot, Why Hiring Is So Hard In Tech. Here’s my favorite part:

Interviewing

These don’t work:

• Puzzles and riddles

• Whiteboard code tests

• Big O notation quizzes

• Detailed quizzes about the mystery corners of the language

These work great (in order of value):

• Pair program with candidate on an actual issue from your ticket queue (let the candidate drive)

• Code samples / OSS contributions

• PAID Sample project assignment (err on the side of paying fairly — say $100+/hour for estimated completion time — if the problem should require 2 hours to complete, offer $200)

• Review past work / portfolio

• Read candidate blog, publications, watch candidate talks

• Ask candidate for input on a real problem you’re currently working on

• Ask specific questions about software problems and solutions from candidate’s resume
  

IMHO puzzles and riddles as part of coding tests are the WORST. First off, no one is thinking their best during an interview. Second, solving riddles is (bizarrely enough) not a regular part of a dev job. Neither is whiteboarding (at least not like it’s done in interviews) nor chats about Big O notation. If you are interviewing developers you should ask questions that relate to what they actually might do. Recently, when I’ve been talking to candidates, I have been talking about actually problems that we have and it’s definitely helped me judge how great a candidate will be by their suggestions.

If you are looking for a job as a developer or hiring one, you should absolutely read this article.