Recently, I published an article about how I landed 7 job offers from companies including Amazon, Oracle, and Google in just 8 weeks of searching as a software engineer with a nonstandard resume. Specifically, I talked about my unconventional strategies to get into the interview room.
I SEO’d my LinkedIn, said yes to everything, got referrals, emailed recruiters (again… and again…) and finally got myself into some interviews. Nice. Now what?
I expected maybe a hundred friends to check out my first post. Instead that number has reached over 50,000 (with thousands of those views coming from The Juggle!), and I received an outpouring of thanks for sharing. So, maintaining the notion that this info is not common knowledge, and may genuinely impact folks’ job searches or even careers, here’s publishing Part 2: The Interview. Enjoy!
——–
Behavioral interviews
A behavioral interview is anytime somebody asks you to talk about yourself, rather than asking you to solve a technical challenge. This could be with a recruiter or a member of the team you’re applying to — there are a few key things I did that I think impacted my success in the interview process.
1. Pivot away from qualification traps
I already talked a bit about this in Part 1 of this post, but I received so many follow-ups that I want to reiterate again and go into a little more depth. I noticed a big discrepancy between the perceived priorities in my behavioral and technical interviews. On the phone with recruiters, I sometimes felt like I was fighting an uphill battle against my paper qualifications. Do you have a computer science degree? How many years of professional experience do you have? Were you an employee of another company while working on this project? Do you have prior experience with each of the technologies in the job description?
On the other hand, the engineers in my technical interviews had less interest in my resume. They asked me to solve technical challenges to showcase my skills and problem-solving process, and I performed well. Most engineering teams are hiring for ability, not qualifications. I was continually put through to onsites, with far fewer questions about a degree or years of experience. Can you actually do the job? Yes? Cool.
Clearly, I had the technical ability to get the job, but I had to convince the primary gatekeepers (recruiters) to believe in me. So, when I say to pivot away from qualification traps, I mean the following: be prepared for any question that would trap you into accepting defeat in lacking a “required” qualification that isn’t actually critical to your competency. Practice reframing the conversation and focusing on your strengths.
Try the following exercise:
- Look at 2–3 job descriptions for positions you’re interested in.
- Make a list of all the “required” qualifications that you don’t meet. 50% of these are probably not required, but they’re often what you’ll be screened for by somebody not intimately involved in the day-to-day of the job. This isn’t their fault — they’re trying to find candidates who are likely to succeed, and these are the only standards they have available to ask about. That’s why you need to volunteer more substantive information on why you’re qualified.
- For each one, brainstorm how you’ll respond if asked about it. Know how to refocus the conversation away from an arbitrary qualification and toward what’s important: your actual abilities.
- Some examples: Do you have a CS degree? “It wasn’t my major back in college, but I do have recent experience with…” What’s your professional experience? “Let me tell you about a product I recently built…” Do you have experience with this technology? “I’ve worked with these similar ones, and am excited to get more exposure to this…”
- Practice this live with a friend. Train to keep your cool when responding to a real person, without breaking down and saying, “I have no experience or skills… But please give me a chance!” Because that isn’t actually true.
Don’t let your impostor syndrome take the mic. You always have relevant experience, it just may not be the exact thing they asked about, so you have to bring it up yourself. This brings me to my next point: transferrable skills.
2. Identify your transferrable skills
Many people think they don’t have the skills needed for a job because they haven’t done that exact thing in that exact setting. In fact, we’ve often used a very similar, transferrable skill in a different environment. Here are some ways I discussed my transferrable skills:
- As a product manager I played a role in coordinating our agile process and sprint priorities. This contributes to my ability to contribute in an agile development environment now as an engineer.
- As a consultant I created predictive statistical models from large datasets. I’m comfortable working with data and statistical modeling and understand the importance of making data-driven decisions.
- On a recent project I worked extensively with <insert similar technology here>, which shares <these important qualities with a technology in your company’s tech stack>.
Your transferrable skills will look different from mine, so you have to dig them up ahead of time and be ready with stories about how they are relevant to this role. For example, do you have prior experience that demonstrates your:
- Problem-solving abilities?
- Writing and communication skills?
- Quantitative aptitude, even if not with the exact tools used on this job?
- Ability to learn new skills and ramp up quickly?
- Business savvy, even if not in this industry?
- Leadership abilities, even if on a different type of team?
Don’t be afraid to talk about your skills. Just because you haven’t done the exact thing they are asking you about before doesn’t mean you can’t do it. Any role has a ramp-up period, and you’re not expected to know everything on day one. If you have broader skills that transfer to your ability to do this job well, tell them so.
3. Show depth of knowledge
After my job search, I asked one of the recruiters I had worked closely with to chat about how folks with less “official” qualifications can describe their experience. They said one of the most impactful things about my candidacy was that, even though I didn’t have many years of experience, I was able to speak to an impressive level of depth about what I had worked on.
To this I owe some big thanks to Hack Reactor’s curriculum. They made sure that by the time I graduated, I was not just saying “Hey, I can build a full-stack app!”, which is now commonplace among bootcamp grads — and therefore less interesting to employers. Instead, I was able to speak at length about performance tuning database queries in a database with over 10 million records, benchmarking database management systems for core query performance, load testing an application at web-scale and identifying performance bottlenecks… etc.
The key takeaway for me was: if you’re selling yourself on skills rather than paper qualifications, be ready to talk in-depth about what you’ve worked on. Especially the decisions you made, the tradeoffs involved and the impact they had on the project, stakeholders or customers.
4. Hype your soft skills (even in technical roles)
In a field like software engineering, it can feel tempting to ignore other qualities you bring to the table, lest they make you seem less technical. The “antisocial genius programmer” stereotype looms threateningly, especially if you’re worried about drawing unnecessary attention to, say, a nontraditional background.
I actually found that companies are hungry for engineers with both technical ability and great interpersonal skills. It’s good for business — so find ways to talk about those, too.
My “elevator pitch” went something like this:
- Here’s who I am as a software engineer and why I love engineering.
- Here’s what I’ve been working on recently as a software engineer.
- Here’s how some of my prior experiences, and the soft skills they demonstrate, make me an even better engineer.
One of my talking points was my prior background as a product manager. I emphasized my ability to interact with stakeholders, work well with product teams and understand the user stories and personas that we’re actually building for. I also talked about past leadership experiences and how I work effectively on teams. Smart businesses want their engineers to empathize with the users they’re building for, collaborate effectively with teammates, think creatively and potentially become leaders one day — and these types of skills are often in short supply.
Multiple offers I received explicitly cited these traits as on par with my technical competence in my desirability as an engineer. They didn’t value me less because of it: au contraire, I had passed their technical interviews and added even more value with the additional skills I brought to the table.
Technical interviews
For Software Engineers, a technical interview can take many forms: whiteboarding, system design, building quick full-stack apps, debugging, you name it. It depends what roles and what type/size company you’re applying for, so I won’t go into detail about specific interview types. I’ll talk in relation to my personal interview process, but you can apply these principles to whatever you expect to see in your interviews.
1. Practice like you interview
I realized early on that my biggest challenge was not just solving the coding problems, it was doing it in an interview setting. I would get completely thrown off as soon as I had to code on a whiteboard or talk out loud about my thought process. So when I practiced, I tried to recreate the interview setting as much as possible so that I’d be 100% ready on the actual interview day. I can’t stress enough how much of an impact the following strategies had on my interview performance.
- Set a timer
Time management was one of my biggest weaknesses. I was too verbose, and found it tough to budget my time between planning, diagramming and coding my solution. One friend made me set a timer, and it made a world of difference in my interview performance. I set it to 25 minutes — even less time than you’d normally have in an interview— so that the usual 45 would feel luxurious in comparison. I learned a lot about where I was wasting precious minutes and how to keep my cool when I was running out of time.
- Practice without your integrated development environment (IDE)
In most interviews you’ll be coding in a bare-bones text editor like CoderPad, or on a whiteboard. A friend who interviews candidates at Google told me that many people get nervous coding from scratch like this, and then don’t perform as well on the problem as they could. So I started doing all my practice on a whiteboard or without all the extras: no snippets, no beautifying formatters, often no syntax highlighting, so I wouldn’t get tripped up in the interview when I didn’t have them.
- Practice with another human being
The best possible way to practice coding challenges is to do them in front of another person. I had two friends with whom I scheduled regular practice interviews. We would each present a problem to the other person, set a timer and solve it out loud as if in a real interview. When time ran out we’d cut it off, give detailed feedback and switch places.
I became much more comfortable solving problems in an interview setting, and I learned about my weak points from the feedback. We drilled problems from Cracking the Coding Interview, Leetcode, and even practiced System Design prompts we found online. Figure out what you’re likely to see in your interviews — for example, frontend interviews may ask you to build React components— and work on that style of problem.
Another site I started using at a friend’s suggestion was Pramp. You schedule a practice session, and they match you up with somebody else. Each person delivers an interview question the site provides for you and then solves another, and after you’re both done you rate each other’s performance and provide feedback. You receive a certain number of practice sessions free — and if your partner thinks you were helpful as an interviewer, you get a bonus credit. As a side perk, if you do well in your practice interviews, they might even start matching you with real interviews at companies they partner with. Pretty cool. This is my personal invite link for an extra free credit, or you can just head to pramp.com yourself.
- Practice out Loud, Even By Yourself
I wanted to practice even more on my own. So guess what? I set my timer, read the question and talked out loud to an imaginary interviewer as I drew diagrams and code on a whiteboard. When time ran out I took notes on areas I could have improved. This was still infinitely better than just grinding Leetcode problems because for me, solving it out loud was the hardest part.
2. Treat it as collaboration, stay in the driver’s seat
At some point in an interview, you’re bound to draw a blank or get lost. So how do you get started or un-stuck without showing your insecurity or betraying the inevitable fear, “what if I don’t figure it out in time?”
To handle this, you need to set a collaborative tone with your interviewer. Act like you’re both working together to solve this challenge at work, and you’re simply taking the lead. Perhaps they’re a client or customer coming to you with a problem. Setting this tone inspires confidence in your abilities, and puts a positive spin on any time you take to pause and think. Ask questions with confidence and in an affirmative tone of voice. “Is it safe to assume <x>, or is there a different structure I should be looking at?” “Would you like me to implement <y>next, or <z>?”
One of my biggest hurdles is that at the beginning of a problem I need a few minutes to think quietly and figure out my approach. In an interview setting I would create a long, awkward silence, which looks like I have no clue what I’m doing, or I’d launch into an attempting a solution too quickly without thinking it through.
I realized that I could continue working out loud without missing out on my thinking time by saying something like, “I’m just going to brainstorm a bit.” I’d then go through my brain dump out loud: “I know I should be able to get to <x> time complexity in an optimal solution… I could use a hash map here, but it’d introduce this issue… A binary tree structure would allow for logn search time but doesn’t meet this other condition…” etc. I still took the time to think, but projected confidence and stayed in control of the problem-solving process.
3. Use helper functions (avoid writing boilerplate)
In coding interviews you’ll almost always need some annoying code to perform a trivial but necessary task, which takes 3 minutes to write, clutters the board, and distracts you from the main problem. Do not try to write out every trivial functionality from scratch, especially not on a whiteboard.
I frequently asked: “Is it alright to assume I have access to a helper function that takes in <x> and <y> as arguments, and returns <z>?” Seriously, 90% of the time they said that sounds great. They weren’t interested in watching me write simple code that wasn’t part of the core logic of the problem. A great example is creating an initial empty board for a game. Nobody wants to watch me make a 2-D array filled with null values in JavaScript. Just assume a function called getEmptyBoard(rows, cols), and describe out loud what it would do. Then invoke it in your code to get your game board, and make a note to come back and implement it at the end if there’s time.
Assuming these helper functions saved me tons of time and energy in my interviews, which I now had available to solve the real problem. My interviewers got to spend more time evaluating my actual problem-solving process. Everybody wins.
4. Use helper functions… again
Helper function bonus! Some programming languages may be lacking built-in libraries or classes that are beneficial to solving certain problems. For example, I did my interviews in JavaScript, which lacks native classes for some data structures. Should I have used a programming language I was less comfortable with to avoid getting stuck?
No need. I’d just ask “Is it safe to assume I have access to a class called <classname> with the following properties and methods?” Again, this was almost always fine with the interviewer — they didn’t want to watch me implement it from scratch just because it doesn’t exist natively in JavaScript. I wrote out the basic skeleton for the interface I needed it to have, and then moved on to use these assumed methods in my code. Bada-boom.
Whether you’re looking for an engineering job, or something in a different field, I hope these techniques help and best of luck!
(This article was originally published on Medium.)
Written by:
){kind=link}