Development Job Search Hiring Managers | 2018-01-10
Why Software Developer Interviews are Broken and What you can do about it
For example: Big 4 interviews are usually focused around ad-hoc coding challenges, they ask two questions and many get stuck on the first (more simple) question. I find I struggle at this because there is one correct answer, it’s usually one to four lines and if you see it great you move on. But after banging my head on the desk a few times, I freeze up and can’t complete it.
This is strange because at work, I talk through my direction to solve a problem, discuss it possibly brainstorm, and follow through with that. But the pressure of a couple lines of code will solve it and that I’m not seeing it (yet), is tough to overcome. I dislike questions like this: “Can you complete this in 5-10 minutes? Every engineer here has.” Whoa buddy, okay that’s awesome lets dive into the problem without the external pressure.
Definitions also are tough. I often get asked what’s the difference between abstract classes and interfaces. If you studied this or have a cheat sheet handy, it’s simple. But I work 40 hours a week and have a life at home. If my work doesn’t cover interfaces or abstract classes in the last couple of months, I struggle remembering the textbook answer. Instead, I relate my responses to problems I’ve worked on because that’s how I remember things. Personally, some interviewers don’t care for that during phone screens, while during an in-person interview some response well to it.
For me, I think that interviews are a mess and tough to navigate.
Here’s a few things I do so I can come prepared, or at least have an idea what they’ll be asking.
Using a recruiter or researching, meeting others, and submitting on your own.
- Location - is it within commute distance? If not, do they offer relocation assistance?
- Technologies - does it align with my past experience? Are they flexible?
- Salary - does it fall within my range?
- Team environment - is it a startup with 3 employees? Do they work in sprints/agile? How big is the team? What are the roles?
Phone interview or Phone screen
This is the mess I was mentioning before, they can ask you anything, but there are a few things I try to do that helps me prepare:
- Distill down what they are looking for, via the job description. Essentially delete any fluff and keep the key skills/technologies they look for.
- Ask the recruiter or internal HR what style interview it is. Give examples (general overview of your experience, code definitions, ah-hoc coding challenge)
- Have a 30 second intro of yourself explaining what you are (full stack, frontend, backend), how many years of experience, core languages, what kind of teams you’ve worked in, etc.
Have a cheat sheet of questions to ask them. A few of my favorites are:
- What have you delivered on recently?
- How much influence do engineers have over features/tasks vs maintenance?
- What tools or frameworks are you using or looking to use?
Make a cheat sheet of your experience, grouped via languages. If they ask about web services or Vue.js, just scroll down to that corresponding section. With each bullet point, list a challenge you had with it, what you did in it, etc.
- Here’s an example: ASP.NET Viewstate performance bottlenecks - eliminated unnecessary requests and complex filtering.
- Challenge - Keeping the UI interactions exactly the same, but reducing the overhead of viewstate by removing calls when we already had the information.
More importantly, understand from their tone of voice when to hurry up, or a 3-5 sentence story of an issue is what they are looking for.
- This may mean to clarify or to bluntly ask them what they are looking for, but answering it wrong will mean wasted time.
- Jot down what they share, what they are looking for and combine this with the job description to get a clear understanding of what they want. Use this to your advantage by reviewing it right before the “In-Person interview”
In Person Interview
- Take time off for it, wether your sick, going to the dentist, jumping on a call one random afternoon, just work late and make up your time.
Find out what you should wear. Many people suggest being professional, wearing a dress shirt and slacks. But i’ve had mixed results and heard “He’s trying really hard” after being told to dress professionally.
- Aim for one step above what they are wearing and go with your gut.
- Some places expect the traditional blazer, dress shirt and tie, while others are more casual and they wear untucked button downs. Figuring out which one it is, is tough. Ask what to expect from the interview.
- Will we be coding?
- Where is it? Is there a parking spot for visitors? Can I take the bus in a resonable time?
- What is the name and role of the team members I’ll be meeting with? (memorizing them or writing it down on a sheet of paper, helps me know how to respond -- high level vs specifics)
- What will the format of the intervie be? Will I need to know OO definitions or be preparred to white board code? - Sadly, HR usually responds with. “A mixture of these”. But it's sometimes helpful
- How long will the interviews be?
- Show up at least 15 minutes early and do what you need to do to get in the zone. If that’s listening to music, doing push ups in the bathroom stall to ease some stress, read the job description and your resume cheat sheet one last time, your goal is to be relaxed and be ready for anything. Sometimes a recruiter will meet you before or after and “walk you in”.
- Print out your resume for each interviewer, plus one extra and have a blank sheet of paper ready to jot down notes. It’s old school and probably not necessary
- Make a 1 page cheat sheet with questions and answers they might ask, print it out and bring it with. Have 5-10 questions for them at the bottom of it. Write one sentence describing their company and if possible what they are building.
- At the start of the interview, have these three sheets in front of you. No one has ever said for me to put those away or looked down on me for being prepared in this way. It’s a great strategy to glance down, see what experience bullet point references their question and go. This decreases the chance of logically building yourself into trouble (because you’ve thought responses through ahead of time).
After the interview
- Email a thank you to HR. If you go through a recruiter, ask them to forward this email. Sometimes HR sends this to their team and that’s awesome, other times it’s kept just to them. But even though you can find emails for each person you interviewed with, please don’t mass send a thank you. If you’ve been going back and forth with a hiring manager, send one, if not, just send it to HR.
- I keep a google doc of every style of “Email template”, so it’s easy to reference. Once you’ve written one, you don’t need to write another.
- Here’s how mine starts and ends: “I wanted to thank everyone for their time, I really felt… Please let me know when you expect to have a decision….
- If they haven’t responded when they said they would, send a follow up email. It’s easy because you already asked them when you should know by.
- Generally speaking, the sooner they respond the better but bigger companies interview a ton of engineers at the same time and have to meet to keep/toss out applicants.
- If you get any feedback, tweak that specific area and try again. Often feedback can be body language, tone of voice, eye contact. Not all interviews are the same, but I try to increase my chances by pivoting easily.
- Treat each interview as a baby step towards the end goal, you won’t be perfect the first time, talking at a mirror at home isn’t the same as talking through a problem with a senior engineer.
- Try to understand what they look for, after each interview review what you struggled at before, iterate and improve on each interview. Whoa, that was a LOT of information.
So why are software engineer interviews broken?
Every company does phone interviews differently, every in-person interview is different and it’s very hard and time consuming to prepare for each one.