5 Tips for Your First (or Nth) Technical Interview
For Analysts and some Data Scientists (pending what Data Science means to you!)
I had the absolute joy of getting to speak with graduates of General Assembly’s Data Science and Data Analytics programs today on an always fun (👀 ) topic: the technical interview. I figure this is a good opportunity to memorialize some of the insights that we discussed as a group. These are geared towards the new analyst or data scientist.
I’ll start by sharing that I don’t believe technical screens can ever be a true mirror of doing “the job.” I also don’t think you can make them truly equitable across candidates and their individual needs. Hopefully everywhere you interview is conscious of this and does their best to minimize bias and make the experience as equitably individualized as possible.
1. Empathy is the default (if not, run away.)
I’d reckon there’s a 99.99% (this is not a researched stat ☠️ ) chance that the person conducting your technical screen for you at, one time or another, has done one or more themselves. All of us who have done them likely dreaded the preparation and stress of the often necessary “evil”.
Remind yourself this. Your interviewer probably knows what you’re feeling as you enter the interview. Your interviewer likely is really hoping to see you succeed. If you sense they want you to fail, you likely shouldn’t be joining that company in the first place.
So, what does this really mean? Own your technical interview and do what you need to set yourself up for success. More tactically:
If a recruiter sends you an invite to a technical screen without details (who, why, what tools, etc.) then go ahead and email them back and ask so that you can be prepared as possible. You can also do this for behavioral or other interview types!
If no one mentions whether you can or cannot use documentation during your interview, then proactively ask before you start with the first question. Understand those parameters so that you can do your best.
If you sense yourself slipping out of control of your energy during your interview (anxiety picks up, you start to question if you’re failing, heart rate picks up, etc.) then do what you need to recenter. This could look like:
“Can I please have 1 minute to turn off my camera and microphone to recenter?”
“Can I please have a moment to go and grab a glass of water?”
“Can I please turn off my camera and microphone for 1 minute to stretch?”
The answer to any of these could be “no.” That is okay! Asking and advocating for yourself shouldn’t be held against you and, if it is, I’d again question whether that’s the right place for you to work.
2. Visualizations are less about mastery and more about knowing your audience.
A question that comes up often is: “how do I get technically better at data visualization?” Upfront, I don’t know that I’d recommend spending much time preparing for this: in my personal experience, visualizations are more likely to come up during a project-based assignment or not at all.
That said, there are some strategies to consider that I practiced early on in my career to try to get better. They are all oriented in building an intuition on how design choices impact perception since, at the end of the day, visualizations should almost always be catered based on the audience you’ll show them to (a CEO should probably see a different chart than your analyst peer.) By learning more about yourself, you’ll typically build deeper empathy for your audience.
Try working with random public datasets to conduct a self-led visualization brainstorm. Choose one insight you want to highlight and visualize it as many times as possible during a set time period (perhaps 10 minutes per insight.) Optimize for quantity, not quality — changes to color schemes, size, bolding, chart type, etc. all count as variations.
Wait 24 hours, and then come back to look at each visualization independently. Look at each one for 30 seconds and write down your initial takeaways. Are you confused by anything? What stands out? What would you takeaway? What questions does the chart raise?
Do this for a few different insights. Then, go back and analyze the trends you see across your reflections. What did you learn about what tends to work or not work for you when seeking to get a point across through data visualization?
If you can after you’ve done this a few times yourself, share your brainstorms with coworkers or friends and ask them for their initial response (bonus points for folks who do not work with data) to continue building your intuition.
Edward Tufte’s work is always solid in building a foundational understanding of data visualization concepts.
Simplify, simplify, simplify. The newer you are to data visualization, the less you should try to accomplish with a single chart. This enables you to learn quicker what works or doesn’t work. Spoiler: I remind myself this daily and I’ve been doing this for ~8+ years.
3. Optimize for building confidence through technical screens.
It’s easy to try to predict what every company will ask you. You can’t. Even if GlassDoor or Blind or some other site has the current list of technical screen questions, you might be the candidate who receives something different. By optimizing for what you “think” they’ll ask, you might end up neglecting to prepare efficiently.
What would happen if you place your skills on a confidence level of 1-7 (low→high)? Maybe `window functions` are a 2 but `case statements` are a 6. In this case, do not practice case statements — you already have some confidence there. Instead, focus on window functions to maximize your skill and confidence building potential.
Some guidelines on how to optimize based on the time you have pre-technical screen:
If you’re interview is in 2 hours…
Focus on brushing up on 3-5s. You have a sense of the topic but just need to make sure you remember syntax, use cases, etc.
If you’re interview is in 2 days…
Focus on brushing up on 2-4s. You might have low clarity on how to apply the topic, but know that it exists. Do some practice problems to build confidence.
If you’re interview is in 1 week or more…
Focus on 1-2s. Learn new things!
You’ll notice I don’t recommend focusing on 6-7s. This is because there are likely diminishing returns in gaining confidence relative to the other skills at levels 1-5. If you find yourself getting tired or frustrated from practice, use a few 6-7s only to boost confidence and energy.
Technical screens are another repetition of practice to build confidence or learn of a skill you didn’t know you didn’t have that can be added to this scale/to your repertoire. Treat them as such to help shift it from “am I a failure?” to “where can I keep learning and growing?”
4. Unexpected questions are sometimes a signal of success, rather than failure.
Sometimes you’ll go through a technical screen and feel very confident. Then, all of a sudden, it starts to really pick-up in difficulty. You might ask yourself: how did I get here? Am I failing?
The answer? Maybe, but there’s also a strong probability you are not!
Many companies — especially more mature data organizations — will create a standardized list of questions they ask all candidates no matter the level. Then, based on the seniority of the role, there’s an expectation that the candidate gets through a certain # of them successfully. For example, an Analyst might be expected to answer 3 of 8, whereas a Manager and above may be expected to answer all 8.
By empowering the Analyst to take on questions 4, 5, and 6+ if they’re able, the hiring team enables you to exceed beyond their expectations/requirements. This can help ensure leveling is equitable. I’m a huge fan of this method, since titles in data jobs can mean very different things by organization when it comes to technical abilities.
So, if you feel like you’re rocking it and all of a sudden you’re given a very tough question, reframe it as a sign that the interviewer thinks you can handle it. Let that confidence inspire you to do your best at seeing if you can get the solution!
5. Seek out an opportunity to build and grow your technical skills in a nurturing environment.
Data became my passion because of the unique ability analysts and data scientists have to influence hairy and high-risk strategic decisions through their work. Early on in my career, I made the mistake of thinking the exposure to those decisions was the thing to optimize for versus deepening my technical skillset. I ended up on more than one project where I realized: I know what I conceptually should be bringing to the table here, but I just don’t have the technical skills to do it.
It is likely inevitable that you will reach this crossroads at some point in your data career, but it illustrates a broader point: as you grow in strategic influence, your technical skills (or aptitude to quickly learn new ones) can present a huge blocker to getting to be useful to your team and business.
So, as you look for that first data job, I’d highly suggest you aggressively seek a team that has enough structure and maturity to help coach you in those foundational skills. Look for opportunities to work with different datasets versus mastering just 1. Let yourself focus on being Yoda of SQL or Python coding execution. It’s okay to focus there and not work on the most flashy business problem at hand — you might just find that the strategy of focusing on execution foundations accelerates your ability to do the strategic work of your dreams even sooner in your career.
I hope you found some of these helpful or interesting. What tips do you have? Please feel free to share in the comments or over social.