The Do’s and Don’ts of Nailing that Developer Interview
Let’s start with what this isn’t: this isn’t another puff piece about maintaining eye-contact and follow-up emails. Please don’t misunderstand me, those pieces are very important and you should absolutely read a few before your next interview. However, every type of job comes with its own set of requirements. To this end, my purpose today is to help fellow developers land their dream jobs by addressing the specific measures that can make or break them as a candidate during an interview at a startup. As a development manager that’s conducted hundreds of interviews for different developer positions over the last decade, I believe that my experience and perspective may be able to contribute some practical value to this discussion.
I’ve decided to write about this to explain why so many candidates that look amazing on paper fail to make it past the interview process. The truth is, my peers and I often find ourselves frustrated by what we view as easily avoidable mistakes from our side of the desk. So let’s see how we can avoid them.
I’m focusing on startup tech interviews in this piece as this is where my expertise lies. Nonetheless, a lot of this advice can be also used in corporate job interviews as well.
The recruitment process for a young startup company is different from that of an enterprise. First, time is a much more valuable resource in startups. No matter how complicated the tech, startups can’t afford long learning curves and are looking for fast adapters. Second, team and “cultural” fit plays a far larger role in startups, given the close proximity and collaboration required to succeed.
In hindsight, I realize how mistaken I was to have mostly focused on technical skill in the past. Today, I’m a lot more interested in seeing how well the candidate fits the above criteria. Moreover, I’ve come to appreciate just how important motivation is. Overall, this means that I now look at a candidate’s “soft skills” far more than I used to, rather than just evaluating their ability to produce good code.
This means that these days, when I’m looking for candidates, I’m looking for demonstrated excellence, ambition and learning skills. Anyone can write that they have qualities on paper or say the word “I’m a fast learner”. Instead, it’s far better to communicate this via brief case studies of your success. How? By framing your experience as cause and effect. As an interviewer, I’m looking for stories of impact backed by hard facts and data wherever possible. For example, How did that widget you designed improve the product or service you were working on? How did the optimization you learned about help improve performance, stability or even simplify the code? How did you go above and beyond in your role and what was the result? Where were you forced to adapt your skills and how long did that take?
Now, for more tips to land that next job at that kick-ass startup company :
Do your homework
Like I said earlier, a big chunk of our processing goes into determining whether or not you’re a good cultural fit. This requires research. Spend some time learning both about the company itself in addition to the domain they’re working in and problems they’re trying to solve. Read the information on their website, read their blog or related resources, check out the rest of the team and scroll through their social media. You’re not expected to become an evangelist for their cause just yet, but you are expected to at least be able to ask relevant questions and have a conversation about the company. Otherwise, you risk coming off as disinterested and uncurious- and nobody wants to hire a developer lacking in curiosity.
Highlight your CV
This may sound obvious, but enough candidates have veered off topic enough times for me to explicitly address this. Interviews should focus on your motivations, experience and achievements. They are not an opportunity to list off dozens of technologies without relating them back to you in a meaningful way. Recruiters and headhunters may be looking for buzzwords, but tech managers know to read between the lines. Technology is a tool to achieve something. I’m curious to learn what that something was and what you have achieved.
While we’re discussing CVs, let’s add a quick note for the junior developers reading this: please don’t use words like "proficient” or “experienced” before the title of software engineer. You’ll get there, but you need to earn more stripes first. Also, avoid linking your GitHub account if all you have in there is a ‘Hello World’. That just caused a person who has to read through hundreds of other CVs to waste a minute of their time for inevitable disappointment.
Ok, now that you have a solid (ideally one-page) CV emphasizing what you know, and not just a grocery list...
You should be able to explain your accomplishments clearly and confidently while demonstrating a deep level of understanding of their context. It can be a feature, design, project, complicated bug fix or anything else, as long as you’re prepared to discuss it for 10-15 minutes and answer technical questions. You should be able to answer questions like: What could you do/ have done better? How would you improve it today? Note that a candidate who can’t describe their previous job or study project won’t even get as far as the technical questions. It’s also important to concentrate on what you did, and not what your previous team or company did. Remember, I’m interviewing you and not your teammates.
Take a challenge and prove yourself
Say that for, one reason or another, you were given a test exercise to complete in the hiring process. This is an opportunity to prove yourself. Approach this challenge half-heartedly, or present it in a way that will be hard to understand, and you most certainly won’t make the cut. This is the time to give everything you’ve got, triple-check your work and turn in an immaculate result. This test isn’t pass/fail. Impressive implementation and a good solution is necessary for standing out, and you will be tested on seriousness and willingness to succeed, writing habits and technical creativity.
Last but not least, be positive!
I can’t tell you how many people have used their interview as an opportunity to take a huge dump on their past employers. And I can’t express how unprofessional and negative this is. Employers do not need to hear you take down others for their own validation. We don’t need to hear how bored you were in your previous job (best to frame it as “unchallenged”). We also don’t need to hear how much you hated your coworkers or how the organization’s set up interfered with your success.
I’m a developer like you, not a psychologist. Having a negative attitude makes an interviewer question your chances of succeeding in the position you’re applying for. It makes us wonder if those hurdles are going to follow you to your next position. It also gives off very bad vibes and creates negative associations.
This is, of course, only my perspective on how you should prepare for landing that tech dream job. All of these tips are just my opinion on how developers can succeed. If they seem obvious to you, it’s most likely because you’re already doing them well and set to land that position! If you have any questions or are looking for further advice, please don’t hesitate to be in touch!
Schedule a Demo
Ready for better data access governance and universal data protection? Schedule a quick, private demo today!
Recent Blog Posts
- You Have Data, But Is It Accessible?
- Satori Joins Snowflake’s Accelerated Data Governance Program
- The Datamasters: Data Owners vs. Data Stewards vs. Data Custodians
- Using Satori & Collibra To Boost Data Governance and Security
- The Redshift-Tableau-Satori stack for DataSecOps in Data Analytics
- Custom Classification: Common Use-Cases
Posts by Tag
- Access Control
- Data Governance
- Data Protection
- data democratisation
- Snowflake Data Warehouse
- data security
- AWS Redshift
- Data Science
- Sensitive Data
- Snowflake security
- Data Classification
- self service access control
- Data Policy Management
- Policy Management
- Row Level Security
- Athena Security
- Data Custodians
- Data Masking
- Data Owners
- Data Stewards
- Human Element
- Least Privileges
- Policy Engine
- RSA ISB
- Redshift Security
- Redshift data access
- Snowflake Roles
- Snowflake’s Accelerated Data Governance Program
- data lake security
- role hierarchy
- rsa conference
- rsa innovation sandbox
- snowflake stages