Job interviews are what you make of them — even if you’re a new software developer. VP of Business Development and former Head of Job Placements at Flatiron School Rebekah Rombom shares a few tips on how to ace your next technical interview and get hired for the unicorn of an employee you really are._Hi, reader. I’m Rebekah. I help run Placements for Flatiron School, which means I work with a team of people to help our grads get jobs—everything from helping them think about how to approach a job search in a totally new field, to getting feedback from the companies where they interview. But let’s start with some full disclosure here: I’m not all that technical. I would fail your technical interview with flying colors. I’m definitely not going to give you technical prep tips—there are tons of resources out there to help you prepare (and if you’re in one of our immersive classes, you’ll have spent three straight months writing code). But here’s the thing: technical interviews are not all about the code you can write or about summoning programming definitions really quickly. Far from it. At Flatiron School, 97 percent of our job-seeking students get jobs. So at this point, we’ve helped them successfully go through hundreds of technical interviews. Apart from giving them prep tips and mock interviews, here’s what we tell our students before sending them off to potential employers.
1. Employers are basically trying to figure out three things with a technical interview:
-
Will you perform well in this job?
-
Could I/my team work with you every day?
-
Are you smart?
There’s a lot packed into each one of those, and if you ask around, the answers to them will vary slightly—but this is basically the gist.
2. On the other hand, if you’re at a technical interview, you should have three explicit goals:
-
Advance in the interview process. This means you’ve reasonably proven all of the above, or provided enough evidence for them that you get another interview
-
Learn something
-
Contribute something
Goals two and three are important for a few reasons. Mostly, they put you in a position that’s way closer to the reality of working than if you were just gunning for goal number one, to advance in the interview process.
At an ideal job, you’re always learning and contributing every day. You’re not trying to get a job once you have a job, so if all you’re doing in an interview is trying to get another interview, you probably won’t have much of a chance to show off how great you’d be as an employee or coworker. It’s also really difficult to convey that you’re a great employee when you are acting out hypothetical situations. It’s much easier to just do the stuff you’d do if you were actually being a great employee. Show, don’t tell.
One inevitability of interviewing is that not all interviews are going to go well, but the experience is really what you make of it. If you’re just there to get the job and get out, you’re missing a huge opportunity! Think of it this way: you’re already in a room with a more experienced programmer who has set aside time to talk with you about code. Why not learn something? Be engaged, ask questions, and take advantage of this valuable time.
And on the third goal, contribute something: if you look for ways to contribute, you’ll definitely be acting like a good employee or coworker. You’ll almost certainly learn something, and you’ll probably increase your chances of moving on in the process. Being ready and excited to contribute is one of the most important qualities people are looking for in an employee or coworker. Who won’t want to work with you?
So what does all of this mean in reality? Here are some examples:
Scenario 1: You aced all the questions, and everything’s going great. Your technical prep work is paying off. Congrats!
But think about this: If 10 people interview, and half of you get the technical questions right, and half don’t, then you’re still up against four other people. What does the interviewer do? How can he distinguish between all of you?
This is a great chance to contribute. It will take some additional effort to figure out how to do that—which means you can’t just go home and celebrate your slam dunk interview. It takes work to stand out.
When it comes time to ask questions, ask the interviewer what the company’s biggest challenge is when using their preferred framework or database. Research solutions. Write a blog post about it. Or go home and create a cool visualization of a problem you solved, deploy it and send it to them. Write and send a thank-you note for your front-end interview styled in object-oriented CSS.
You’ve almost got this in the bag. After you walk out of that room, don’t stop interviewing for that job. Be the only person who did something amazing. Make yourself an absolute no-brainer.
Scenario 2: You have absolutely no idea what this person is talking about, and haven’t since she started saying technical things.
It’s tough to be in this situation. You’re probably not going to move on in the interview process, and that’s hard to deal with while you’re in the actual interview.
But if you try, you might walk away with all sorts of goodies. What you’re going to want to do here is ask lots of questions. There’s an enormous opportunity to learn something—don’t let it pass you by.
“How do you implement merge sort in PistachioJS?” the interviewer asks.
Instead of smacking your palm against your forehead, pause. Think for a second, and maybe say something like “Hm, I’ve never heard of merge sort, and I’ve never heard of PistachioJS—is that a front-end JavaScript framework? Do you mind if I ask a few questions about it before we continue?” Then ask more questions.
You might never get to merge sort, but you’d better believe that if you go home, study up on Pistachio, figure out how to implement merge sort, write a blog post on it, and add some tips for beginners about how to get started with Pistachio by using it to implement an algorithm, you will impress the pants off of that company.
Perhaps, after you do that, they’ll hire you and give you lots of responsibility and ask you to build all the trainings for junior Pistachio devs. They’ll put a unicorn statuette on your desk when you start, because “oh my goodness, how did we possibly find such an impossibly incredible team member?!”
But maybe they won’t. Maybe they won’t acknowledge the work you did at all, and will just send you a rejection email that starts with “Dear Candidate” and does not even mention your brilliant blog post. Really, that’s okay, too—you learned something, you contributed something, and you’re going to crush your next interview.
This post was written by Rebekah Rombom. Stay in touch with her on Twitter or LinkedIn.
