My thoughts on how to conduct practical interviews for Software Engineering candidates.<\/p>\n
Any professional software developer has been through it, standing in front of a whiteboard reciting some algorithm you are supposed to have memorized, that you have never once used for anything in your career. \u00a0Obviously, that isn\u2019t a good test of ability. Classical software interviews are <\/span>clearly a different skill<\/span><\/a> than software engineering. \u00a0<\/span>Talented engineers get rejected for silly reasons<\/span><\/a>. \u00a0\u00a0How do we make this better?<\/span><\/p>\n The first problem, to me, is <\/span>untrained interviewers<\/span><\/a> misinterpreting the idea that <\/span>false negatives (rejecting good candidates) are \u00a0better than false positives (hiring bad candidates)<\/span><\/a>. \u00a0This has been a topic of discussion for a <\/span>very long time<\/span><\/a>, probably since the early days of computer science. \u00a0\u00a0I agree that an incompetent engineer is more of a liability than an asset, for many reasons. \u00a0\u00a0What I don\u2019t think is right is what we call a \u201cfalse positive\u201d. To explain, we need to define what a good candidate is, and then infer what an interview should entail.<\/span><\/p>\n There is a lot more to a bad hire than just poor technical skill. \u00a0Poor personality, poor communication, and an inability to adapt are all far more damaging traits than not being a top notch programmer. \u00a0Poor personality and communication negatively affect other engineers morale and make their jobs more difficult and stressful. Inability to adapt leads to dated ideas and eventually your technology falling behind the competition. \u00a0\u00a0Quickly summarizing, <\/span>a good candidate must be technically skilled, adaptable, communicative, and personable. \u00a0<\/b>I\u2019ve found that <\/span>many companies<\/span><\/a> ignore some or all of these factors, often relying completely on random technical puzzles to determine who to hire. \u00a0You would be better off hiring with resumes on a dartboard.<\/span><\/p>\n I\u2019ve recently gone through the process myself and come to some conclusions based off my experience. It\u2019s not absolute, but I\u2019ve been on both sides of the interview table and I think I\u2019ve found \u201cMust Do\u2019s\u201d, \u201cCould Do\u2019s\u201d, and \u201cMust Not Do\u2019s\u201d in an interview that will make interviewers better judges of candidates.<\/span><\/p>\n Technical Skills <\/b>– The candidate must write code, on a computer, using any resources they would normally have. \u00a0I don\u2019t think you can interview an engineer without asking them to code, but the code should be simple, straightforward, and relatively easy to manage in the time allotted for the interview. \u00a0In this part of the interview, correctness and completion are not important, it\u2019s much more important that they know how to use the tools at their disposal, the basics of programming language, and how to consume information from the internet.<\/span><\/p>\n Adaptability <\/b>– The candidate could show they can pick up a project and understand what it is doing. \u00a0This may be redundant if the technical skill question(s) are exceptionally well written, but the point is clear. \u00a0The candidate should be able to show they can learn and understand something unfamiliar and parse the information, quickly.<\/span><\/p>\n Communication<\/b> – The candidate must explain, in detail, the design of a project they have built. \u00a0They must be able to explain the design decisions they have made. They must explain what alternative designs were considered and explain the trade off well. \u00a0This interview is about communication, not the choices they made. If they can explain themselves rationally that is more important than if you agree with their design decisions.<\/span><\/p>\n Personality <\/b>– The candidate must show they are easy to get along with. \u00a0He must be personable, driven, and empathetic. The candidate must interview with the team he will be working with, and meet his future manager, PM, and peers. \u00a0You should <\/span>never <\/b>have to introduce a new hire to his new manager. \u00a0The fact that companies do this regularly baffles me.<\/span><\/p>\n Specific Technology<\/b> – Tl:dr, If you are interviewing for a DBA, ask a database question. \u00a0\u00a0Ideally, this shouldn\u2019t be necessary, as most engineers are smart enough to pick things up on the fly. \u00a0I would suggest only doing this if the role requires daily use of whatever specific technology this role is. \u00a0I\u2019ve seen UI interviews for engineers who will never once touch JS in their job. I\u2019ve also seen SQL interviews for a React JS frontend only role. \u00a0That is not useful.<\/span><\/p>\n This should be made very clear before bringing candidates in, otherwise you are wasting both your time and the candidates time.<\/span><\/p>\n Public Presence \/ Evangelism<\/b> – Ask about a public <\/span>GitHub profile<\/span><\/a>, or open source contributions. \u00a0Maybe blog posts they have written. \u00a0Not every engineer is in a position they can do these things, but if it exists it\u2019s a great resource to the interviewer. It lets a candidate show his communication skills, his passions, and his philosophy.<\/span><\/p>\n Server Architecture<\/b> – This should be covered in most cases by the technical communications section above. \u00a0I know the modern web design question is extremely popular nowadays, but the answer is extremely formulaic and not a good judge of an engineer. \u00a0REST Api + Normalized DB tables + Load balancer \/ App server \/ DB \/ Queue, etc…. It\u2019s something that can be easily practiced and doesn\u2019t actually tell you much about the engineers knowledge.<\/span><\/p>\n Irrelevant Technical Skills<\/b> – One of my interviews in my last job search was a bunch of math and physics brain teasers. \u00a0This is completely not relevant to the software engineering job at almost any company I can think of. \u00a0It\u2019s extremely important not to waste time vetting a candidate on something that does not matter for their job. \u00a0As an interviewer, make sure you are actually gathering useful information every minute of the interview. You do not have enough time to waste on irrelevant skills.<\/span>\u00a0\u00a0<\/span><\/p>\n Large Homework projects <\/b>– Do you want an engineer to be biased because he spent more time on the homework project than the next guy? \u00a0If you want to give a project, it should be both timed, and less than 2 hours. You do not want to bias against people who do not have time to spend 30 hours on a mock website for you. \u00a0It will probably scare the talent away anyways.<\/span><\/p>\n Tricks<\/b> – If your problem can be found in <\/span>CRACKING the CODING INTERVIEW<\/span><\/a> it\u2019s probably not a good question. \u00a0If it requires an algorithm the candidate learned 10 years ago, it\u2019s probably not a good question. \u00a0Nothing you ask should have a \u201ctrick\u201d or an \u201ca-ha\u201d moment to figure out the solution. By doing this all you do is bias towards people who have spent time studying for the interview, and biasing away from people who actually spend their time developing software. <\/span><\/p>\n Veto<\/b> – Never let one engineer veto the hiring decision in an onsite interview. \u00a0This is to protect the interviewer from their own emotions. I\u2019ve seen an interview say no before they even meet the candidate. \u00a0If you see an interviewer doing this regularly it may be time to take them out of the interview panel.<\/span><\/p>\n Single Answer Questions <\/b>– Do not ask an abstract question, perhaps about a product decision, then fail the candidate because they did not answer how you would have. \u00a0Separate ways of thinking are healthy and should be encouraged, not shunned.<\/span><\/p>\n I\u2019ve seen that many companies, particularly larger companies, do not do a single thing in the \u201cMust Do\u201d list. \u00a0It\u2019s very easy to get lazy and forget what the point of an interview is, and it\u2019s also very easy to use unskilled and untrained interviewers as the company grows. \u00a0I understand. But you must fight that. It\u2019s important to train the interviewer well, using well defined standards for your company. It\u2019s important to keep the interview process predictable, consistent, and applicable. \u00a0Do you do everything in the \u201cMust Do\u201d list?<\/span><\/p>\n As for the candidates out there, just remember that the process is a little broken, very inconsistent, and there is no way to get every job you apply for. \u00a0Practice, play the game, and don\u2019t get too sour when you come across a bad interview. There are still more CS jobs out there than candidates to fill them, so there should be a place for you.<\/span><\/p>\n References<\/b><\/p>\n http:\/\/stevehanov.ca\/blog\/resume_comic.png<\/a><\/p>\n https:\/\/github.com\/poteto\/hiring-without-whiteboards<\/span><\/a><\/p>\n https:\/\/sockpuppet.org\/blog\/2015\/03\/06\/the-hiring-post\/<\/span><\/a><\/p>\n https:\/\/techcrunch.com\/2015\/03\/21\/the-terrible-technical-interview\/<\/span><\/a><\/p>\n https:\/\/salesforce.quip.com\/2UKIAhvKyZf0<\/span><\/a><\/p>\n https:\/\/triplebyte.com\/blog\/how-to-pass-a-programming-interview<\/span><\/a><\/p>\n https:\/\/triplebyte.com\/blog\/how-to-interview-engineers<\/span><\/a><\/p>\n<\/h3>\n
Must Do\u2019s<\/span><\/h2>\n
<\/h3>\n
Could Do\u2019s<\/span><\/h2>\n
<\/h3>\n
Must Not Do\u2019s<\/span><\/h2>\n
<\/h3>\n
Conclusion<\/span><\/h2>\n