As we saw in one of the previous blog posts, it is as hard for the employer to find a developer, as it is for a developer to find a job. Yet, don’t worry about any other candidates they might be looking at, as we have learned that most of them cannot program even if their life depended on it. As a software developer and advocate Dan Kegel puts it, if you can successfully write a loop that goes from 1 to 10 in every language on your resume, can do simple arithmetic without a calculator, and can use recursion to solve a real problem, you're already ahead of the pack. This week, we talk about more curious things: the minds of people who interview you. What are they looking for, and how do they make sure what they find in you and other candidates is what they need? Since you know you’ll end up being hired somewhere anyways, when you go to the interview, have peace of mind and focus on making it easy for them to figure out whether you’ll in fit in the role they have open. Sure enough, that’s why any interview conversation usually breaks down into two themes - technical skill and teamwork.
Peace of mind
xpanding on the interviewing formula proposed by Joel Spolsky, there are three groups of candidates: not qualified, having enough skills, and rockstar developers. Paradoxically, you’d have more chance to get a job if you simply have enough skills, rather than if you’re a rockstar. The reason is that most companies have specific teams, thus it makes more sense to hire someone who is a good team player with sufficient technical knowledge because it is the team that gets the work done after all. Rockstars are more problematic in this sense since they are less interested in teams and focus on the individual impact of their work. This leads to a variety of downsides (Steve Konves has a really good piece about it). But it all boils down to the simple truth - a team of people with partial knowledge do a better job for a company than outstanding individuals with an all-encompassing level of expertise. What this means to you is, you don’t compete with those who are unqualified and who are overqualified. The skilled interviewers use techniques like FizzBuzz test, so by the time you’re entering the interview room, you can be sure that the hard part is already over.
Now, you’d need to be able to talk about the choices you made about the tooling and framework you have used in the code case studies you bought to the interview. They might want to ask you about recent projects you worked on. In case you haven’t, look yourself up on Google - that’s what many interviewers would do before meeting you, so the questions they ask might come from what they saw there. Apart from that, make a note of how the whole interview process looks like. Spolsky suggests having six company members interview each candidate, and having longer one-on-one conversations that could last up to one hour. Five of those company members you’d be talking to would ideally be developers, rather than managers. Does the company that interviews you also go through the process like this, or people that you meet appear not to have any technical knowledge at all? If not, any specific reason why? Do they ask any illegal questions - anything related to race, religion, gender, national origin, age, military service eligibility, veteran status, sexual orientation, or physical handicap?
“A team of people with partial knowledge do a better job for a company than outstanding individuals with an all-encompassing level of expertise”
Teamwork
Put in fancy language, this is about leadership and initiative. In other words, thinking about how you can make your teammates’ lives easier, and being proactive about any idea you have about it. As Toptal’s hiring guide suggests, prospective employers want to know your bigger picture and how your vision fits into the team you’d be working with. But at the end of the day, what they want to know is that you’re going to treat your colleagues well, and won’t dump the company after a month two. teamwork is tough for them to test, so they’d need extra help from you here. Tell them about your involvement with open source projects, developer meetups, Stack Overflow or other forums you’re active at. If you haven’t had a chance to do anything on that front, spend a few hours before the interview to locate such projects or meetups to give an indication which ones interest you and how you plan to get involved. The hiring company would be interested to know how do you ask for help in forums when you need to, how do you help others to solve their cases, and how you tackle disagreements. One easy way that will quickly get you into the community is to locate projects on GitHub and practice debugging the recent version of the code. This is also a good way to prepare for a “debugging exercise” that is commonly used in the interviews - again, this will be more about the prospective employers to find out how you’d go about solving the problem, rather than actual answers.
“Walk an extra mile to explain things well, without assuming people know technical details of what it is you’re working with or tools you use”
Conclusion
It may sound strange but the best thing you can do is to forget that you’re in an interview. Simply focus on helping the interviewers to see that you’re smart and can get things done. Talk about what are your top professional interests and priorities - this will scream at them that you care about your work. Walk an extra mile to explain things well, without assuming people know technical details of what it is you’re working with or tools you use. And be prepared to say a few words on why you did things in a certain way, what did you forget, and where are the bugs in the test cases you might be asked to solve write during the interview.
