Interviewing in tech is hard, especially when you're just getting started. Years ago when I was getting my start I had a lot of the same issues many of you have likely had, and failed hard in several interviews from several major companies, but after a decade or more of experience and several hundred interviews conducted I have a few things I would have told my past self.
Hopefully a few of these observations help you on your own journey, and give you ideas of how to practice, but remember that everyone's experience is different. What works for me, and what my views are, may not necessarily work for you or your interviews.
With that in mind, let's get started.
Perspective of the Interviewee
This first article will cover advice I would have given myself as an interviewee seeking jobs, and covers some of my current strategy in how I approach job hunt. (No, I don't plan to leave my current role any time soon)
Which Companies?
Yes. Plural. You should be considering multiple options, because not everything will work out. Maybe you just had bad luck with the interviewing panel, who knows, but you can do everything right and still not get an offer. Maybe you get multiple, and then you can use that to negotiate better salaries, bonuses, and stock options. It's always good to interview multiple places.
Dream Jobs Later
One thing I tend to do is rank companies I want to work at on a scale of B, A, and S:
- B Rank - I like the company, but may not be familiar with their stack, tech, or it's outside of my comfort areas.
- A Rank - I've actively considered joining this company in the past, they have similar tech stacks and values to what I enjoy working in, and I may have a few friends working there.
- S Rank - These are my dream jobs, ones that are long-shots with harder interviews. Likely some of my heroes work there, and several friends, making them very tempting.
Typically I will start to interview around at B rank before I go for dream jobs to get in practice, and potentially get offers on the table to start considering. The key thing to remember here is that unless I would seriously consider working for a company I will not interview with them and waste their time and mine, but I would be a liar to say I don't favor some over others the same as companies favor some candidates over others.
Once I've warmed up a bit and stretched into interviewing I may start putting some of the dream jobs into the roster and see what happens. By this point I may have a few offers on the table I can use as negotiation for better rates, and in some cases I may well take those offers instead.
There have even been cases where I was told something by people at a company or discovered something through interviewing that moved them up a few ranks in my consideration. Sometimes a dream company manages to do something which raises severe red flags and I run. You can only really tell from speaking to folks.
Ethics
For me ethics are important, so I tend to avoid companies which I disagree with politically, socially, and ethically. Palantir, Facebook, and others are automatic no-goes for me. Some others like Github and Shopify I'd love to work at but I really don't like some of the things they support around aiding human rights violations and white supremacists. Those are hard lines for me, and it does narrow the pool a lot, but I'm ok with that decision.
Issues around human rights, racism, political apathy, mental health, LGBT+, and other topics will most certainly get me to drop a company from consideration.
Networking
Networking is the single most valuable source of information I have on jobs, and Twitter tends to be the number one place I watch. If I'm thinking about leaving I'm reaching out to all of my good friends to talk about what they're working on and if there happens to be a Brandon shaped hole somewhere at their company.
Often times that'll lead to several potentials and a lot of interviews with some great places, as well as a lot of good information on company culture. Some roles don't even exist publicly, and for some companies if you're senior enough they may well just make a role to work with you if you have an interesting value proposition for them.
Now that all said, it's important to pay back favors. Retweet people looking for jobs, help others, and invest in the community. There are some amazing folks out there, and who knows, maybe some day you're hiring and one of them reaches out to you too.
There's always that running joke that people are always trying to get the old band together, and some folks just love working with each other. I have a list myself of folks I'd jump at the chance to work for, and lucky for me I have a lot of them working with me already. There have been several cases where ex-coworkers have reached out to me or me to them, and several of them have even come to work with me over the years.
As an aside I do not mind answering questions and networking with folks, but my DMs on Twitter can be buried in messages at times. If we do not know each other and you want to chat please make sure to leave a bit of context and have some specific questions. Saying "hey" or asking for mentorship out of the blue doesn't tend to work very well, especially if it requires a lot of time commitment and I don't know you yet.
Pre-Work
Practice Practice Practice
One of the most awkward times interviewing is when you're not comfortable with your tools and language of choice. Ideally you work out your nerves before interviewing, and get to a level of confidence in your tools to where you can translate your thoughts into working code.
For me I tend to practice a lot on Codewars and Exercism. There are other sites, but I find myself incredibly hostile towards sites like Leetcode which focus on magic tricks and hidden requirements. Quite honestly for me if I hear a Leetcode problem I'll likely halt the interview and walk out as we're both wasting each other's time.
The goal is to not necessarily solve hard problems, but to feel like you have a decent working memory of your language. For me in Ruby that might include things like Enumerable, Hash, Comparable, String, and a few other common libraries.
It's also good practice to reimplement some of the nicer library functions like Enumerable#tally and other utilities, as some interviewers will consider those too easy and ask you to reimplement them anyways. Might as well get some practice in on them early.
Research the Company
If you want to work for a company it's a good idea to know why. Is it their mission, their stack, the people you know there, or something else entirely? You should know about some of their business model and what makes them tick, and especially for more senior roles how you fit into the picture to help them get where they want to go.
Day of the Interview
When interviews were being done physically I always liked to show up an hour early and wait nearby at a coffee shop to unwind and get ready if possible. Do note that only works for me as I have the time to do so, and may not work for parents or others. This isn't a major thing, but helps ease nerves of showing up late.
The main point is give yourself a breather if at all possible before the interview, and don't rush into it without at least a few minutes break to get in a good headspace.
The Interview Questions
Eventually you're in front of your interviewer, and they're going to ask you a question. Be sure to listen thoroughly to that question, and if possible request that they give you a written or typed copy to reference, because this will be important.
Do note that these primarily cover live-coding interviews versus take-home assignments, of which I have little experience with, but similar concepts may still apply.
Question the Questioner
The first step for me is to drill into the question, and ask clarifications to make sure I understand exactly what the interviewer wants.
That includes restating the problem in your own words to make sure you have an understanding of what's being asked. Sometimes you find out a few assumptions you've made aren't accurate and that can save a lot of time.
Writing tests first (similar to TDD comes in exceptional handy at this point. As you ask questions of your interviewer codify them into tests and get your interviewer to confirm that they in fact represent the problem as they want to see it solved.
Things like validations, input types, edge cases, potential future direction, time constraints, and other items are great things to ask here.
If you have all of those criteria in written tests with your interviewer agreeing that that reflects the problem it eliminates a substantial portion of potential marks against your solutions. The first step to any problem, especially in the job, is to understand exactly what the problem is. Interviews are no different.
DANGER: Do not start implementing solutions until you understand the problem, because if that understanding is flawed and you ignore your interviewer that will likely fail you.
Narrate Your Solutions
While you're solving your problem make sure to explain your thinking. Why use if/else versus a Hash, why encapsulate in a class versus helper methods, why are you choosing to do things the way you are?
This goes back to asking questions. Interviewers aren't statues, you're allowed to ask for feedback, even on solutions.
In some of these cases you can even ask about what you think the next part of the solution might be, as many problems tend to be multi-part. Maybe knowing changes how you design something, will there be more than just a few inputs like this? Will the system expand? There's a lot you can learn here.
By making your thoughts known you're giving the interviewer critical insight into your thinking process, which is valuable signal. It also allows them to spot potential issues before you get too far into the weeds.
Be sure to also watch your interviewer for how they're reacting. If they're furrowing eyebrows and trying to interject or guide you another way something may be going very wrong.
Then again some interviewers also have very specific solutions in their heads, which while broken is something you should still watch out for. It all comes back to making sure you understand what they're asking and listen even while working on solutions.
It's a Two Way Conversation
Communication is critical to senior level positions, and as such how you communicate and collaborate with your interviewer will likely come up. If you keep talking over them, even if due to nerves, and ignore suggestions without talking through them that's going to hurt.
Software really isn't a solo journey, and your interviewer is there to work with you, hopefully not against you. I can't say that's always the case, but when it isn't you dodged a real red flag.
Be sure to ask about things that aren't clear to you, up to and including why a problem might be written the way it is.
One candidate, when they noticed the random nature of some parts of the problem, asked about how important it was to ensure test consistency with seeds or other consistency methods to ensure it always ran the same way, which was a gap in one of my problems, and earned them some bonus points. Very rarely are our questions static.
No Golf Allowed - Clarity First
Interview code, while time constrained, should be as clear as possible. That means avoid the shorthand, focus on making your code readable because that will be judged.
Constants, helper methods, abstractions, classes, and other language tools can be leveraged to really make your code shine. If you find magic numbers, raw strings in comparisons, or other items that aren't clearly named they may be easy targets for cleaning up your code.
This also means avoid using abbreviations and shorthand names for variables, methods, and other items. It won't take too much longer, and chances are it'll save you as well in the future if you slip somewhere.
Maintainability, readability, and ease of later use are still important even under time constraints. Don't paint yourself into a corner with shortcuts.
When it Goes Wrong
Things crash. It happens. If they do knowing how to debug, what to look for, and how to isolate problems will come in a lot of handy. In Ruby I tend to use a lot of tap and puts (print-like) debugging for quick checks, and a debugger if it gets much more intense than that.
The big thing here is to maintain calm. Step through your solutions, talk through what the code is doing out loud, and if you have those tests above try and isolate what causes the break. Error messages and logs are invaluable here, make sure to read them.
Pieces of the Puzzle
Some problems are really hard. If you don't know the solution to the entire thing say so, and start breaking that problem down into smaller problems you know how you can solve. The goal here is to have some working code rather than failing to get anything at all working.
Interviewers in general are looking for some signal, and even if you don't solve the problem itself it looks a lot better to have some of the parts of it working.
Solve and test the small parts first and build up your solution from there. This also makes it easier to find where bugs are over time as those small parts are much more likely to be implemented correctly than one giant function.
Also that giant function probably won't look too good in terms of clarity.
Mentoring on the Fly
Sometimes your interviewer won't know the language you're programming in, or may ask about things. Sometimes they do and they just want to see what you do when they ask. Either way there are definite advantages to making sure your interviewer understands why you might solve something a certain way in a language or tool they're not familiar with.
There have been some candidates which have taught me quite a bit of Go and Rust, and I'm not particularly proficient in either.
Do note that if you're condescending or mansplaining in any of this that's going to dramatically backfire and likely end your chances right there. Keep it humble, and don't assume the competence of your interviewer. This isn't something you should do with everyone.
Time for Questions
So you've made it to the other side, you're still alive, and it's time for questions. Some see this as fluff at the end, but it can be a valuable opportunity to learn more about the team, the company, and the culture you might be stepping into.
There have been times where some serious red flags dropped from questions that had me running for the door that I may never have known if I hadn't asked.
These are just a few questions, but may help with ideas on things to really drill in on. I'll probably miss several good ones, so if you have ideas do feel free to comment with your favorite questions to ask!
Do they like the company?
One of the more common questions, and don't believe anyone who is unfailingly positive about things. There's always something they don't like about the company, and something they'd like to fix about it. It's best to dig in here a bit and find out where they think gaps are. It's also concerning if they turn around and bash the company for the next few minutes.
What are mentorship and growth opportunities?
Especially as a more junior engineer you want to know if there's a solid path upward for you, and mentorship to help you get there. As a more senior engineer it might be that you're interested in mentoring (you're never done learning, mind), but either way if there are no solid systems you can find out about that's concerning. It means promotions, raises, and other items will be difficult and likely recognition for your work will be hard.
How do they approach mental health and current events?
Look, the world has some messed up stuff, and some times that gets to be too much and people need time. Does the company take care of those folks? Does it give them time and space? Does it have resources in place to get them the help they need?
A company that does not openly talk about mental health, current political events, and how employees are doing overall is not a place you want to work for. You're more than your job and your output, you're a valued human being and you should find a company which keeps that forefront.
Support for the Vulnerable
Does the company support vulnerable people in the work force? What are their policies on bathrooms and trans acceptance, transitioning, and other concerns? How they treat the most vulnerable is a sign of the integrity of a company.
Do they stifle discussion of vulnerability, or embrace it? Do they label these vulnerabilities as "political" and deny the validity of their humanity? These are real issues, and now more than ever is the time to make sure companies are on the right page about this.
How much vacation do people take?
Unlimited vacation sounds great until you realize the team average is 2-3 days a year. If they have a work hard play none culture that's concerning and you'll burn out real quick on it.
Oncall rotations?
How often are you expected to be on call? Is that paid time? How bad is it and is there a culture of being buried in pages, or actually paying down those concerns?
Documentation and Onboarding?
Some companies are really not great at documenting things, or having onboarding processes for folks to get ramped up at the company. That might not be a deal breaker, but it means it's a steep climb to reach base level productivity. It also may indicate the engineering culture there isn't great and doesn't value knowledge sharing.
Do note docs are hard, so honest answers here about current efforts are things I deeply appreciate. No one has it right.
Build vs Buy?
Some companies have this bad habit of building things in-house rather than buying existing solutions. Maybe they have good reasons, but more often than not someone wanted a promotion and inflicted a byzantine monster on the rest of the company to get it. Bonus points it that person abandoned the tool afterwards and didn't document things, those are real valuable things to know, especially if you're being interviewed as the cleanup crew.
Language choices?
What does their stack look like? Is it locked down, are they evaluating new options, do they have policies on any of this? Some tend to be a carbon-copy of Google, some tend to be free for all with contracts. Some, if you're unlucky, can't decide between the two. Those are good things to know especially at senior and above levels where it might be your job to reconcile that.
Deployment and Testing?
How's the deployment system look? Is the software tested? What insurances do they have that what they're shipping actually works, and how quick can they roll that back if things go really wrong?
Some companies take multiple days to deploy, and without a very specific set of steps the entire thing catches fire and takes out half of production. Those are things to watch out for.
Development Process
That's great, they have deployments, but how does that code go from someone's head to production? Do they have a ticketing system, agile, scrum, waterfall, or what? Are they using design documents for larger features or winging it? How do features get approved and reviewed? Are they keeping accessibility in mind? There's a lot here to dig into.
The Results
Now comes the hard part. You can do everything right, nail the interview, wow the panel, and still get those frustrating words that they've decided to pursue other candidates. It sucks, it hurts, and it can be demoralizing to even the most seasoned engineer, let alone more junior ones who're facing streams of it.
It's ok to fail. Heck, in the past I've been rejected from Apple, Amazon, Facebook, Google, Microsoft, Stripe, and more than I can remember (or care to.)
Sometimes if you're lucky you get some feedback, and sometimes you never hear a word back.
Wrapping Up
Now there's a lot to consider in interviews, but this is part of how I look at things, some of the questions I ask, and what I tend to look for. These might not all work for you, but I hope you've found some value in these experiences of mine.
If you have any questions feel absolutely free to comment, and I'll get back to as many as I can.
The next post will focus on my perspective as an interviewer and what I tend to look for.
Top comments (1)
This is a fantastic read and resource!
I'm struck by the "Time for Questions" section.
As someone who has pivoted from artistic pursuits (and the service industry to pay the bills), I'm still formulating my language around questions for the interviewer while orienting myself to the unique concerns of an interviewing software engineer in today's world.
I'm definitely putting these questions in my back pocket for all future interviews.
Thank you for this post! <3