As a senior software engineer, I typically get to interview potential candidates for the companies that I work for. And more recently, as a startup founder, I get to interview candidates for my own organization. And during the past 15 years, I've gotten to interview alot of people. Some good, some great, some pretty bad.
So to help you out with your future career interviews, I've compiled this list of 6 things that I am particular about whenever a new candidate walks through the door.
None of these are deal breakers in the end, as your overall skill usually outweighs most other things. But if anything, they might help to make the interview process a less stressful experience.
6. Longer answers
Every interview is essentially an exchange between 2 or more parties in a QA style fashion. And the number of questions isn't infinite usually. I typically get around 7-8 questions out per candidate ranging in topic from their previous work experience to more personal questions about how they work.
Some people tend to answer with a single sentence for every question, usually filled with "hm's" and "ums" in between, and then leave it at that hoping that it was enough.
The idea being "I answered..now leave me alone".
Every single question though, is an opportunity to impress the other person. The best candidates that I have interviewed typically answer in longer format, often adding real-world examples to drive the point home and essentially, they give me less work overall. I don't have to stop and think whether the answer made sense or not.
So my suggestion is to add some color to your stories. You don't have to give away any past corporate secrets, not at all. But share a few words about other times in which you found yourself in a similar situation.
Having said that, there is such a thing as "an answer that is much too long". Typically those long answers jump around from topic to topic and sometimes don't really have anything to do with the original question. Because if you're telling a good story, then the answer is never too long.
So stay on topic, but share as much as your comfortable with sharing.
5. Specialized skills
There's a good chance that most of the jobs that you will apply to will list a plethora of programming languages and frameworks. The company might only be using one of those languages, but if you know another language, then you might also be a good candidate.
- C++
- Java
- JavaScript
- C#
- Go
- C
- Assembly language
- Any similar
The main reason why companies do this, is to increase the number of potential candidates that they get. You're more than likely going to see your favorite language on the list and apply.
That's the idea behind it anyway. But I personally will almost always favor someone with the exact knowledge of whatever stack it is that we are using. It saves the team time in helping the person catch up to a new environment and overall it's a much less stressful time for the developer as well. To me, the following list is way more important.
- Node.js
- PosgreSQL
- JavaScript
- React
And that's really it. If you're an expert in C++, there probably isn't much that you can do when working with React's functional components. And there's also a good chance that you've never heard of the term JSX.
Not to say that you can't learn these things effectively. But that learning doesn't come without a cost to both yourself and to your potential employer.
So apply to jobs that match your exact skill set at that time. You'll have a much easier time during the interview and you'll have a huge advantage over the people that know a completely separate language.
4. Real world experience
The real world corporate environment is way different then what you'll get to experience in either a college setting or a bootcamp setting.
The languages typically stay the same though. You'll still have to write for loops and if-else statements in both. But you'll be doing so in a completely different context.
Which is why having any kind of real-world experience is crucial for landing a job.
I've encountered many junior developers who still code the way that their professors did in their fundamental programming class. Often times things such as documentation, readability and error checking and validation get ignored leaving for a codebase that will inevitably have to be refactored at some point.
You wouldn't launch your own e-commerce website knowing that your code is not secure or that it is difficult to read. You would inevitably have to research best practices and start to incorporate those into your day to day work.
And in similar fashion, when you're working in a corporate setting, you are more than likely going to work on a mature project that brings in a substantial amount of income to its owner.
But more importantly, you'll be working on a project with other developers. It isn't just your code that matters in this situation. You are coding for a team.
And that's where real world experience comes from. Whether you are working on your own personal projects or on an open-source codebase or on a client's project, the same principles will apply throughout.
3. Showing your work
This one isn't required, but it does help in speeding up the process. And by showing your work, I don't just mean having a filled in activity chart on GitHub that an interviewer may or may not look at.
There's alot more that goes into web development than simply just writing code and doing daily commits.
Most developers that come through my doors, even at more senior levels, usually don't have any kind of online presence in terms of a portfolio or personal website.
So it's hard to gauge what they've actually done and what they actually know.
This is a good opportunity for you to highlight what you think your specialty is as well. If you have strong design skills, then this would be the time to share that.
If you've built complex systems for either yourself or a past employer, then this would be the ideal time to talk about it.
2. Problem solving
More than likely I will probably ask you at least 1 programming question during the course of the interview. That's usually the standard from what I've seen in other corporate environments.
There's a good chance that it might involve a few basic programming operations and not much else. This is usually in the form of a word problem involving some data set and some operation on that data set.
But I'm hiring for a more specialized position, as mentioned above, then I could just as easily ask a candidate to build out an entire page given a set of requirements.
And if you need to spend some time practicing and improving your coding chops, then by all means do it. You never know what you're going to get asked during a coding interview, and focusing too much any one particular area, such as binary search trees, could backfire in the end.
Websites like leetcode.com are a fantastic resource that can prepare you for even the toughest coding interview questions.
1. You're interested
Some people want to work at a company because they like the company. They've read good things about the place and they can see themselves working there.
And that's the kind of person that you want working for your company. Because odds are that person isn't going to just get up and leave after 1-2 months (which does happen).
Which is why a big part of the interviews that I conduct revolve around soft skill questions, essentially looking to gauge your overall interest in working there. But really, I'm looking to gauge your overall interest in working with technology in general.
I've met plenty of developers during my time that truly did not enjoy programming, but they did it to pay the bills. And that lack of interest showed in their work, as they weren't typically the most standout developers.
There's nothing wrong with just looking for a job because you need to pay the bills, not at all. We've all been there at some point in time. And truth be told, those are some of the best jobs that I've personally had.
But there is definitely something off putting about someone who isn't interested in their field at all. That dissatisfaction is what leads inevitably to poorly written code and to a not so fun work environment. So whatever reason you may have for wanting to work at a particular company, be sure that the person on the other end can see it clearly.