If you’re learning to code, there’s always going to be more stuff for you to discover and understand. You’re not going to always know all the answers and that’s absolutely ok. So how do you react in the scenario when an interviewer asks you the question…
Do you have experience with [specific technology]?
…when you don’t have experience.
Initially, you’ll probably feel afraid or pressured to say yes. With technical topics, lying or misrepresenting your skill-set is a one-way ticket to rejection. So how do the people who get the offers take care of business?
Lying and saying you have skills you don’t have is obviously not a good thing to do. But simply saying “no” during the interview process is generally pretty bad too. The interviewer may not expect you to say yes, but they don’t want you to say “no” flat out. If someone asks if you have skill with a specific technology and you say no, it creates a pretty awkward ending of the conversation on the topic. Instead, you should remember that it’s your job to lead the interviewer into what you want to talk about and take control of the situation.
Stating “no, but…” and leading the interviewing down a different path turns what initially would be an awkward ending to a conversation into something entirely different. And it shows that even if you don’t have the experience they’re looking for, it won’t be an issue if and when they hire you.
There are a number of ways to spin a “no” into something different and positive. One strategy is to connect the question to a skill that you’re currently great at. Alternatively, you can just indicate that you’re interested in learning the topic in more detail. If you have a surface-level understanding of the topic, it can be helpful to indicate that as well. Here are some examples:
Interviewer: Do you have experience with Python?
Interviewee: No, but I do have experience with ruby. I’ve looked at Python’s syntax briefly and it seems very similar to the ruby language, which I do have experience with. There appear to be a lot of common principles between Python and ruby.
Interviewer: Do you have any experience with Java?
Interviewee: No, but I’ve really wanted to work in an OOP language like Java, since it is a strong type checking system.
This powerful, but simple technique does a great job communicating a few things:
First, it shows that you’re honest and you’re not misrepresenting your skill. You might not have experience with every single technology out there. Nobody does. Being honest about what you don’t know makes the interviewer trust you when you say the things you do know.
Second, it proves that even though you’re not an expert at a particular topic, it’s not going to be a problem.
Third, it allows you to refocus the interview on the topic that matters the most: the things that you do know and have a lot of experience with.
Fourth, it shows a certain level of confidence with your ability to learn new skills. These days, the ability to learn new things is generally more important as a developer than your specific skill-set.
You’ll become a better interviewer when you figure out a very important skill: the ability to control the narrative and focus the conversation on your strongest attributes as a developer. By directing the flow of the conversation, you’ll increase your own self-confidence. That’s because you’ll limit the number of awkward silences and begin to feel in control, because you are in control.
If you’re controlling the narrative of the interview, where should you lead the conversation?
Before you answer this question, put yourself in the hiring manager’s shoes and think about the process from their perspective. The following is their reality:
First, if they have a job opening, it means they have more work than they are capable of doing with the team they currently have. They may have lost an existing team member, or just have additional expectations from their managers.
Second, in addition to doing the job they’re currently understaffed to do, they need to grow their team. This means not only sourcing, but screening and interviewing candidates.
Third, they’re probably not very good at hiring. They would never tell you this, but they were likely originally hired to lead coding initiatives, manage the dev team, deal with product teams, and work with QA teams. Most teams that aren’t undergoing massive growth should probably expect to hire more than 2 or 3 developers a year, so the typical lead developer doesn’t have a lot of experience with interviewing candidates.
Most hiring managers just want it all to end.
This is good news. This means they probably want to offer you the job. In the interview, you should focus on de-risking yourself as a candidate. This means your energy should be spent on removing doubts in your abilities.
Try to focus the conversation around your experience working on a team with other developers.
Some developers don’t play well with others. And they’re a nightmare to work with. This means that you should talk about your experience in working with other people, and you should make it clear that these problems won’t be an issue. If you talk about technical considerations, like tools (think: Slack, Trello, GitHub), in addition to the social dynamics of the team, it can grant you further credibility as a developer.
Talk about projects you’re currently working on that you’re excited about.
You should definitely be working on a side project while you’re interviewing. And it should be a project that you’re genuinely excited about. Here’s why:
It’s a lot easier to be a happy member of a development team if you genuinely enjoy the craft of programming. If you’re genuinely excited by the project you’re currently working on, you’ll find it easy to authentically speak with a voice that showcases that passion.
When the interviewer asks you if you have any questions, ask them questions.
It’s also important that you genuinely care about the answers to the questions too. What are your thoughts about their response? Start a dialogue about the topic.
What are your thoughts on the company’s stance on test driven development, for example?
In-demand developers generally don’t come off as overly eager to accept the first offer that comes their way. Instead, they demonstrate that they care about the details of the work environment. Ask questions about the position, the role, and the company.
By re-orienting the interview process in the right light and focusing on becoming the strongest developer possible, you should be able to nail the technical interview.
Not sure what matters when learning to code? Check out this blog post: Behind Closed Doors: How You Can be an In-Demand Developer.