Ask HN: What should an ideal developer interview process look like?

My most enjoyable interview was for an internship in college. I had a take home coding challenge where I had to write some simple code to fetch information from an API using whatever language I liked. I was given a week to do it, but it only took me an hour or so to meet all of their explicit requirements. I liked that there was no time pressure in that regard.<p>After the week was up I went into the onsite and in the &quot;technical&quot; portion of my interview two engineers went over the code I had written for the assignment and asked me about design choices I had made and what I would do if constraint X was added or feature Y. It was all very open ended and much more of a true discussion than an interview which I really appreciated.<p>I think this kind of format is ideal for interviews. The assignment requirements were simple enough that you could fulfill them easily and in your most comfortable language without any time pressure, but you could also go above and beyond and show that you really knew your stuff. For example, in the instructions they didn&#x27;t explicitly ask for error handling on the input, but both of the engineers I interviewed with really liked that I had included it. You weren&#x27;t penalized if you did just the bare minimum because you had the opportunity extend and build on the assignment during the onsite. I felt enabled to showcase my knowledge and justify my design decisions and that that effort was rewarded.

Many people here will disagree with what I&#x27;m about to say, but if you&#x27;re going to give a coding challenge...<p>I <i>like</i> hackerrank&#x2F;codility style coding challenges.<p><i>gasp</i><p>They&#x27;re timed. They&#x27;re run against a standardized test suite. And they have support for many languages.<p>It&#x27;s really unfortunate the number of companies that give custom take home coding challenges that run the gamut. The problems with which are manifold:<p>- Inconsistent technology and language choices by candidates<p>- Time spent varies wildly and is easily underestimated by companies - and 4-5 hours for an unpaid coding challenge in an early round with a company is a significant investment<p>- Good candidates will de-prioritize your company against others that move faster<p>I know that I only answered a small subset of the question, but it&#x27;s very difficult to lump all developers together and come up with a single, wholistic, and ideal interview process. From the nature of the role (IC&#x2F;Lead&#x2F;Manager) to the technologies&#x2F;specialty to the company&#x27;s mission, the process will need to be customized to some degree.<p>However, do not think that your custom coding challenge will somehow be the perfect key to assessing developers.

Respectful of my time. Think of dating - if after 3 dates, you still are not sure if you like somebody, maybe it is better to call it quits. I had companies call me in for more than 4 interviews, distributed over several days. Not respectful.<p>Coding: I actually like coding tests in interviews. Then I know my potential future colleagues will also have had a coding test. The company cares at least a little that my colleagues can code.<p>Just don&#x27;t take the coding test too seriously. Don&#x27;t expect me to write correct syntax on a whiteboard, for example. It should be more about having the right ideas, or even be able to discuss possible approaches if a solution isn&#x27;t obvious immediately.<p>Also, make it a little challenging - no computing of Fibonacci numbers or FizzBuzz.<p>I liked one where I was asked to implement Quicksort (not that original, but OK), but they also gave me a definition of Quicksort along with it. That seemed fair.

Check out my open source code. Call some of my references. Verify my past employment and make me an offer.<p>It’s really that simple.<p>If 3+ professionals are willing to vouch for me and I have 20 verified years working at major tech companies, do you really think I’m a guy faking I know how to code?

- Clear timelines on the interviewing process. Some companies show no respect for your time. Telling me to pop by the office to &quot;chat&quot; at a specific time and then telling me your agenda for a 4 round technical interview on the spot is not going to inspire any sort of trust.<p>- Ask me questions that actually apply to the job. If I&#x27;m building an iPhone app, please don&#x27;t ask me to run through a gauntlet of white-boarding&#x2F;coding challenges that don&#x27;t apply to the job. Have me walk through something I&#x27;ve built or talk about how I would build a theoretical iPhone app. Most of us aren&#x27;t building software for self driving cars so please quit acting like we are.<p>- If I&#x27;m writing code or solving problems, give me an ideal scenario to do my best. Let me use my own computer (not one that you just handed me setup to your preferences.) Potentially let me do it at home (where I am comfortable and not in an unfamiliar place.)<p>- Gauge confidence on the technical stack<p>- Don&#x27;t say we&#x27;ll be in touch shortly and then ghost. You can say goodbye to someone without false promises. I&#x27;m likely to tell fellow developers about how the process went.<p>- Have people with decent social skills interview<p>- If I ask questions like, &quot;What should I be prepared for?&quot; please give me a basic agenda or guidance. It&#x27;ll go much better for both of us.

I find the move to take home tests extremely unfair. Anyone with dependents will typically need to block out most of a day of a weekend, or risk doing it in intervals through their week.<p>Got a decent CV? Good luck trying to juggle applying for more than 2 interesting opportunities at once.<p>We mostly hire full stack web devs. IMO It&#x27;s impossible to really test the abilities of each candidate across the changing landscape of front end, back end, DB &amp; devops tech within an interview process that doesn&#x27;t use a vast amount of time for everyone.<p>Instead, we don&#x27;t whiteboard or code at all in our process at the moment, and try and get it all done in a face to face hour or two by:<p>* Taking their experience at face value. Examples: If they have been coding for a couple of years, don&#x27;t waste everyone&#x27;s time with fizzbuzz. Assume they will be able to adapt to our source control system, if they have been using a different one.<p>* Insisting on real world examples when asking competency questions.<p>* Asking generic questions about code, such as &quot;What is clean code?&quot;, &quot;what should you take into account for password security for a web app?&quot;, and looking for their ability to communicate as much as their actual answer.<p>* Looking for areas of strength and weakness to compare across candidates, rather than trying to catch them out.<p>* Scoring highly for enthusiasm, flexibility and a willingness to learn over pure technical knowledge.<p>I appreciate this approach wouldn&#x27;t work for all organisations but we&#x27;ve done really well out of it.

The ideal process is having one that actually exists.<p>Most startups basically try to wing this without any definition of how they want the interview process to work. IMHO this is about 50% of the problem. On the flip side, large companies appear to be overburdened by process (anecdote example - I&#x27;ve heard from several people that getting into Google takes 6 months on average, along with the notorious b-tree whiteboard process).<p>That being said, I think Aline Lerner[0] and Triplebyte[1] have some good ideas on the topic:<p>[0] - <a href="http:&#x2F;&#x2F;blog.interviewing.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blog.interviewing.io&#x2F;</a><p>[1] - <a href="https:&#x2F;&#x2F;triplebyte.com&#x2F;blog" rel="nofollow">https:&#x2F;&#x2F;triplebyte.com&#x2F;blog</a><p>I don&#x27;t think implementing either one of their services is a silver bullet, but are likely n% better than what most companies are doing.

An interview is designed to answer three questions.<p>1) can you write software?<p>2) can we tolerate writing software with you?<p>3) can you tolerate writing our software?

I have a slightly related question. Imagine that you were being head hunted by a company and that they&#x27;ve decided that they <i>definitely</i> want to hire you, even before the interview. Let&#x27;s say they can afford to pay you whatever you consider a &quot;reasonable&quot; salary (not high, but not low either).<p>How would you like the interview to go so that you can decide if you want to work there?<p>Interestingly, <i>I</i> would like to see a variety of people that I might potentially work with. I&#x27;d like to pair program with them. I mean, <i>really</i> pair program -- with each pair writing some code. I&#x27;d like to write some code and see how they react to it. I&#x27;d like to see them write some code to see how they approach it. I&#x27;d like to work though some simple conflicts to see how they react.<p>I&#x27;d like to see some code (and I&#x27;m willing to sign an NDA). I&#x27;d like to work through it with some of the people who work on it and ask questions. I&#x27;d like to see how firmly they hold on to the existing code and how open they are to new ideas.<p>I&#x27;d like to talk to a few people in management. I&#x27;d like to see a few plans (again under NDA). I&#x27;d like to see what kinds of statistics they collect and how they think those statistics help them.<p>Finally, I&#x27;d like to talk to management about how they do reviews and see some statistics about attrition rate, typical pay raises per year, how many stocks <i>actually</i> vest before people leave (yeah, yeah, NDA).<p>That would be awesome.

I notice a lot of these answers focus on the technical or coding challenge. As a hiring manager, that&#x27;s critical, but technical competency only accounts for about a third of the qualities my team is evaluating in a candidate.<p>I&#x27;ve given this question a lot of thought over the last couple years as I&#x27;ve lead teams that have needed to get organized and expand quickly. Here&#x27;s my summary taken from a Google Slides presentation I put together titled &quot;Hiring in a Time of Cargo Culturalism&quot;.<p>It starts with Principles and Guidelines:<p>- Hiring cycles will be structured and as short as possible.<p>- When we start a hiring cycle, we will finish it by hiring the most qualified applicant who accepts our offer.<p>- Every applicant will receive a response within 48 hours and be updated on the status of their application at each step asap.<p>- The hiring process will be as transparent as possible.<p>- Objective and fair-minded measures will displace biased and bigoted ones.<p>- Every applicant will appreciate their experience, even the rejected ones.<p>- The process will be agile and adapt over time to improve and meet the specific needs of the organization.<p>- Onboarding will begin with hiring.<p>Then an outline of my team&#x27;s current Methodology:<p>- A thoughtful and literate job posting will accurately describe the job and foreshadow the company culture.<p>- Simple challenges and honeypots will filter serious candidates from the applicant bots.<p>- At the end of every step, we will inform the applicant what comes next. Courteous templated responses will be promptly delivered.<p>- Two interviews. No more than three. The coding challenge will represent a genuine work sample. It will be no more than one or two hours.<p>- Candidates will be evaluated using a simple quantitative assessment of core competencies (see Ch. 21 of Kahneman’s Thinking Fast and Slow).<p>- Final decision will be a collective decision of the hiring team.<p>- After hiring cycle is complete, hiring team will hold a retrospective.<p>I&#x27;ve hired over a dozen developers this year. They haven&#x27;t all been homeruns but no strikeouts either. A few singles or walks. A lot of solid doubles. And that&#x27;s mostly what my company needs.

One thing that I took away from my flight instructor is that she had me say aloud everything I was thinking and doing. If I said, for example, &quot;those trees might cause a downdraft on the approach&quot;, then, if I did not handle it well, at least she knew the issue was with my execution and not in recognizing the possibility.<p>I don&#x27;t often interview developers, but when I do, I try to get into a situation where the candidate leads us through solving a programming problem, and the issues that come up. The most satisfactory case was where the candidate and I jointly investigated an issue that neither of us had the answer to.<p>Unfortunately, this is not an approach that many people have much experience with, and it seems unfair to penalize people who find it disconcerting, but when it works, I think it is most satisfactory approach for all concerned. It is not easy to automate either the practicing for or execution of this style of interview, which may or may not be a disadvantage.

After many years of winging it, I developed what I think is a pretty robust interview process, inspired by Pivotal&#x27;s RPI. If the candidate makes it through a quick 15-30m remote screening, I call them in to the office for pairing session.<p>* The session takes place at a pairing station - two keyboards&#x2F;mice, two monitors (mirrored).<p>* We work through a fake problem that is relevant to real-world problems that we actually work on. No brain teasers, no complex algorithms. Basic software engineering using some of the tools the company uses.<p>* The problem is exactly the same for every candidate. This is essential; you need to be able to compare apples to apples. You can&#x27;t use &quot;real work&quot; because real work is different every week.<p>* The stuff I look for is pretty mundane - can they name things sensibly? Do I have to push them or do they naturally drive out behavior with tests?<p>It takes 1-2 hours. It&#x27;s partly a way of evaluating candidates, and partly a way of communicating &quot;this is how we develop software at this organization&quot;. Some folks really respond well to it. Some don&#x27;t. That&#x27;s ok.<p>At the end of the pairing session. I know 100% if I want to extend an offer. I&#x27;ve gotten some really great hires out of this. My bad hires ended up bad for reasons unrelated to technical ability (like, their life was a trainwreck).

Counterintuitively I think the problem with hiring is actually a problem with firing. Hear me out.<p>Everyone is so focused on finding this mythical perfect candidate, instead of giving people a chance. Which is really another way of saying &quot;We&#x27;re afraid to fire people.&quot;<p>Culturally, we should hire and fire more freely.<p>I once got a call from a company that said I was an absolute perfect fit for what they were doing-- would I consider a 6-month contract-to-hire? I had been in my job <i>10</i> years and told them no. They were so flabbergasted they called back and asked if I wouldn&#x27;t consider it, that the CTH was simply to see if I was a &quot;culture fit.&quot; I told them in plain language that if I was such a perfect candidate, they could hire me straight out. That I&#x27;d been in a job 10 years, was obviously happy, why would I jump ship so they could dangle employment as a carrot in front of me?<p>I can&#x27;t tell you how many jobs I&#x27;ve not gotten because I didn&#x27;t get some gotchya question-- or in some cases understood more than the person interviewing me.<p>The abusive hours need to end, as does the concept of &quot;culture fit&quot; which is just a proxy for age, race, religion, binger drinker status, etc.<p>We need to stop judging people and trying to feel better about ourselves by dismissing people who can&#x27;t answer questions we just googled ourselves. Almost every company I&#x27;ve ever talked to claims they only hire the best candidates. That simply, cannot be true.<p>How is anyone supposed to grow if you can only get a job you&#x27;re an expert in? And when what you&#x27;re supposed to be an expert in changes every two years?<p>The answer is, culturally, you&#x27;re not.

My favorite coding interview ever is still from many years ago when I interviewed at Pivotal labs.<p>It was an in person pair programming session, with the interviewer driving.<p>Most importantly, it was collaborative, whereas many interviews often feel adversarial.<p>It also tested how you communicate, since you weren&#x27;t the one typing.<p>However, it still tested your coding skills, but because the interviewer was &quot;on your side&quot; with respect to the desired output code, it wasn&#x27;t a dealbreaker or stressful situation if you forgot the signature of an important method or function.<p>But it also touched on actual coding skills, while not requiring you

After getting burned a few times too many, wasting days of work building entire applications (at worst) or even simply a few hours (at best), I won&#x27;t be doing anything longer than a 20-30 minute fizzbuzz take home exercise. I will also never waste a day of leave on a company, unless it&#x27;s the opportunity of a lifetime and I feel I have an almost guaranteed job offer if I jump through that hoop.<p>My ideal interview proccess thus is:<p>1) Talk to me for 30 minutes (not your HR, an engineer that is trained for this task). Fizzbuzz me if you have to, but preferably at this point in my career, don&#x27;t. 2) One or two onsites that last a maximum of 2 hours and are early or late in the day, so that I don&#x27;t have to waste a day of leave. Don&#x27;t fizzbuzz me or ask me edge cases on your language of choice in this. Don&#x27;t come with a checkbox of things you want to hear. Have a discussion with me and actually pay attention to the things I have to say that aren&#x27;t strictly part of the answer to your question.

In my current role I had what I consider the best interview I have had to date. I had a brief non technical video interview with the software director. Then I was assigned a programming task, essentially to create a site focused on a specific task using a given set of technologies. Once done, I sent the interviewer the url to the site and a link to the code on git. The next day I had a code review and video interview with the original director and several Sr. engineers to review my code and answer relatively technical questions on my design decisions and code.<p>I thought this was perfect, they did not waste much time on the original interview, essentially just determined I was not insane and would be an ok fit for the team. Then via the assignment they were able to see me build something from start to deployment including database development and server deployment. One of the required technologies was a javascript framework I had never used before, they knew that but I spent 8 hours (I really wanted the job) reading a book on it before starting the project and they appreciated it. I had a couple of options on server side stack and they were able to observe and question my decisions. In the code review they were able to see how I handled criticism and reacted to stress.<p>Whole process from scheduling the first interview to the job offer took 4 days. No white boarding, no obscure technical jargon. They met me (virtually), learned if I could code to their standards and made a decision. In my mind it was great. Via the same process they interviewed someone else I recommend and very professionally and politely turned them down, someone who in my mind was a pretty solid engineer but he just lacked the specific skill set they wanted. While creating the requested application, he knew he was not going to get the offer, which is great as you as a developer are then able to determine for yourself if you are a good fit for the role. No mess no fuss.

As the person being hired: the process should help me reject workplaces that I would not enjoy, succeed, or grow at. I should get accepted into any place that satisfies the above criteria.<p>As someone doing the hiring: the process should help order applicants by the value they will provide to the company, accounting for future growth and current abilities.<p>In both cases it should do so as quickly as possible, to avoid wasting my time. Sadly, neither of these are really realistic, but starting from these first principles, you can see a few simple things that can improve the process: Early rejection in both directions, settings expectations, and that the interview is a two-way street and while some interview strategies may work in one direction, they will alienate the other side so quickly they are ineffective on the whole.<p>I have some ideas regarding the rest, but nothing that hasn&#x27;t been mentioned elsewhere.

I would give them opportunities to show their skills at real-world tasks:<p>- Version control. Given a terminal (or Explorer with TortoiseSomething) and an existing project, make some simple changes and commit.<p>- Testing. Given a simple piece of code, its tests and either a bug report or feature request, explain at least in high level terms how to move forward.<p>- Code review. Give constructive feedback on how to improve any aspect of a diff.<p>These tasks indicate an understanding of code and facility with communication beyond the very basics, and you&#x27;ll never finish learning them, so I believe they are appropriate for any non-entry level position. They are also sufficiently open ended that the candidate has to prioritize getting at least something done on all of them.<p>After that, unless they are completely hopeless I&#x27;d arrange coffee or lunch (on company money of course) with at least part of the team they&#x27;d be working with, so they can tell if they are at all compatible.<p>Needless to say, give the candidate plenty of options for a suitable time, let them know exactly how long it&#x27;ll take, coordinate the time with the team, show up on time with a computer—which the admin team has wiped and you&#x27;ve just had to copy a few files onto—and find somewhere quiet and comfortable for them to work.

The interviewer should ask the candidate, in the candidate&#x27;s own words, to walk through solving a problem proposed by the interviewer. No whiteboard. Just a simple conversation. The candidate must be provided the opportunity to organize their thoughts with notes on paper and have a short pause of time to think through an answer.<p>Problem solving is a fairly universal thought experience not limited to writing code. The goal is to ascertain whether the candidate can break down the complexity of a problem into simple steps, organize their thoughts into a clear flow, communicate clearly, and finally recommend a valid solution.<p>You don&#x27;t need to test whether the candidate can actually write code, because this is built into the nature of the exercise as qualified by the feasibility of the proposed solution. This exercise also implicitly tests confidence, creativity, experience, and approach style.<p>Most importantly though, it separates the competent from the incompetent. No amount of framework foolishness and dependency baggage will communicate a solution for you.

I think the most useful interviews are ones with three parts:<p>1) Casual talk. Does this person have basic communication skills and are they someone you want to deal with regularly for a long time?<p>2) Give them an actual coding project to do. Pay them for it. Pretend it&#x27;s just like real work (it should be).<p>3) Review their code with them. (both to make sure they are the ones who wrote it and to explore their thinking process)

Most interviews have asymmetric costs. There’s a potential payoff for both parties, but costs are higher for the interviewee (time off, prep, work done).<p>I recommend trying to make the cost&#x2F;benefit more symmetric. One way of doing this, is offering compensation for real work. Essentially, hire interviewees to do a small amount of useful (a day?) and evaluate them based on that.<p>This isn’t going to work for all interviewees, but where possible it feels like a better way of doing things to me.

I like asking candidates to give me a code review on a pull request. Because of IP concerns, I normally do this with an OSS project I’m involved with.<p>Sure, they don’t know the codebase, but they won’t know the codebase that they’ll be working on in a month if hired either. I want to see how they think about creating software and whether they notice potential defects or tricky areas.

The interview should not focus on assessing basic competence, it should look at relevant experience and understanding of the business in question as well as communication and teamwork style.<p>Of course in order to <i>get</i> there would require a working certification system. Requiring candidates to write fizzbuzz in person over and over is a waste of your time and theirs, but it exists because nobody&#x27;s managed to crack a &quot;fizzbuzz certified&quot; system that employers actually trust for this. The fraud pressure is quite high and nobody wants to pay for it if there is a possibility that someone might benefit - 1000 candidates applying to 100 employers results in a huge amount of waste, but requiring the candidates to pay for certification cuts out a lot of good candidates, and paying on their behalf <i>and allowing someone else to use that result</i> is seen as unacceptable.

In the end, I&#x27;m always trying to have a &quot;discussion about code&quot; with the candidate. I ask questions that really are easy, but require a certain amount of listening. This way I understand how the candidate behaves in more abstract discussions.<p>Some examples are things like:<p>- Walking the candidate through an outdated API (that the candidate isn&#x27;t familiar with, but should be able to understand given the nature of the job)<p>- Walk the candidate through code that converts a database query into objects without an ORM. (Candidates who can&#x27;t do this are incompetent. Really.)<p>- Discuss commonly-known details of exceptions &#x2F; error handling in the language that the job is for<p>- Discuss commonly-known details of memory management in the language that the job is for<p>- Discuss API choice tradeoffs in an API that the candidate should be familiar with. (I like to pick serialization APIs built into the library in the language we will use.)<p>Also:<p>- I try to emphasize how I would do with my interview at the candidate&#x27;s level of experience<p>- I have 2nd chances, and will usually stay on the phone for the scheduled interview out of respect. (There are still certain points where I will cut an interview short.)<p>- Make a decision to hire quickly.<p>Usually works well.<p>Signs to reject someone:<p>Figuring out how to use the teleconference software is an unofficial part of my interview. (Most of my interviews are conducted via teleconference because I&#x27;m on a global team.) There are candidates who take 15 minutes to figure out that they can type their phone number into the teleconference web site and it will call them back.<p>Candidates who want to answer a different question, or keep asking, &quot;why can&#x27;t I use XYZ&quot; technique usually aren&#x27;t hired. Again, the purpose is to have a discussion about code and demonstrate understanding of the discussion. I don&#x27;t want to hire someone who can&#x27;t adapt when the correct solution to the problem is some tool &#x2F; design pattern &#x2F; API &#x2F; ect that isn&#x27;t the candidates first choice.

I have had good success with an assignment based interview process. I have written about it in length here - <a href="https:&#x2F;&#x2F;abhyrama.com&#x2F;2018&#x2F;11&#x2F;17&#x2F;startup-hiring&#x2F;" rel="nofollow">https:&#x2F;&#x2F;abhyrama.com&#x2F;2018&#x2F;11&#x2F;17&#x2F;startup-hiring&#x2F;</a>.

Interviewing is an adversarial process, as such, there can be no ideal way to conduct it. It&#x27;s like asking for the best way to have a divorce. Any imposed solution means at least one person is leaving something on the table, and so it won&#x27;t be ideal.

The best interview process I&#x27;ve read about is the one detailed here: <a href="http:&#x2F;&#x2F;www.nomachetejuggling.com&#x2F;2011&#x2F;05&#x2F;27&#x2F;a-different-kind-of-technical-interview&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.nomachetejuggling.com&#x2F;2011&#x2F;05&#x2F;27&#x2F;a-different-kind...</a><p>And sadly I haven&#x27;t once seen it in action. I really wish I could go through such process, or implementing it in whatever company I work at (or create).

The best one I had was where we had more of a discussion about things rather than go into a question and answer session. It was an enjoyable experience to talk to people who are working in a similar field and had seen similar things.<p>On the other hand, I dislike interviews where interviewers come up with a question-answer sequence. So, if you misspoke even a single word they outright reject you. And mostly, I find this in places like TCS, Wipro, Infosys etc.

When I was at Bytemark, we decided it was important that you knew up-front exactly what the demands on your time would be, what challenges there would be, and we don&#x27;t deviate from that:<p><a href="http:&#x2F;&#x2F;careers.bytemark.co.uk&#x2F;full-process" rel="nofollow">http:&#x2F;&#x2F;careers.bytemark.co.uk&#x2F;full-process</a><p>It&#x27;s also anonymous until the 3rd stage, so you (by and large) interview remotely and without anyone knowing your name &#x2F; gender.<p>(this dates from 2015)

A process that I&#x27;ve seen have some success (years ago):<p>Start with a very, very simple initial phone screen or take-home test, intended to basically verify whether the candidate can write any code, at all. Max 1 hour, weeds out more people than you&#x27;d think.<p>For the first in-house interview, ask the candidate to code up a problem that is representative of your company&#x27;s work and requires coding a significant amount, ideally 100+ LOC. The problem should not require any major leaps of intuition, dynamic programming, or recursion – all of these are areas where people do way worse when they&#x27;re nervous, and this is an engineering interview not special forces training. Let them bring their own laptop, give them the prompt, and have them code, although they can ask the interviewer questions at any time. When they&#x27;re done, go over the question in detail with the expectation that their code compiles and runs, discuss extensions, etc. Max 1 hour. This interview should answer the binary question &quot;can this person promptly produce meaningful working code and discuss it intelligently?&quot;<p>For the next in-house interview, do a deep dive into a technical project that the candidate worked on that they&#x27;re proud of. They describe it and you ask questions. Keep asking questions, especially getting at the &quot;why&quot; behind different decisions, for as long as you can – you&#x27;re trying to get to the borders of their knowledge and intelligence. Look for mastery of the area, thoughtful decisions, and communication skills. Max 1 hour. This interview should answer the question &quot;is this person a thoughtful, effective, smart contributor on a project?&quot; A good answer should make you think &quot;damn, that&#x27;s really smart, I wonder if I would have thought of that?&quot; at least once.<p>End with a final behavioral interview, intended to sell the candidate. This is also a last gut check on whether they&#x27;re insane, dangerous to themselves or others, extremely arrogant, etc. Also use this time to ask the candidate questions about what really matters to them to improve your closing rate. 30 minutes, and can be combined with the step above.<p>I&#x27;ve liked this system, YMMV. It&#x27;s a relatively efficient process, doesn&#x27;t have weird tricks, and based upon a longterm analysis of candidate outcomes was quite effective (this included an analysis of candidates whom we rejected and who rejected us).

I wanted to add my 2c that in the mix with whatever else you have, I love a take home.<p>It’s actually building something in my element, IDE, docs, just like real life. You get a chance to show you care with the details.<p>A whiteboard interview is not like RL as your entire career is on the line so shouldn’t be the main KPI, your brain is not working as usual. I don’t even hate presenting to groups or anything, although I do hate presenting unprepared.

I&#x27;ve often thought about this, and based on my own experiences this is the process I would like:<p>1. Test language-specific knowledge - it&#x27;s not a bad thing to not know all the small quirks or details of a language since they&#x27;re generally not too useful, but when someone does know them it tends to be a good sign that they really enjoy coding and learning. And of course there is a certain minimum amount of knowledge that should be required - listing Java as &quot;proficient&quot; on your resume while not knowing the difference between abstract classes and interfaces might indicate a problem.<p>2. Design question - just a simple toy problem like &quot;how would you design the book management system for a library?&quot;. It&#x27;s easy to use such a problem to probe into some different aspects of programming like concurrency and databases, just to see how much the person knows.<p>3. A not-crazy-hard algorithms questions - people often say algo questions are irrelevant to actual work, and I agree with that. But I think algorithms are really a core part of the CS curriculum at every school, so getting completely stuck on a medium-difficulty algorithm question should raise some flags.<p>4. Resume-specific things - it&#x27;s always nice for an interviewer to show that they&#x27;ve actually read your resume, and it can be a good way to convey some strengths that aren&#x27;t otherwise evident.<p>I guess my philosophy is to interview in a way that can test the depth of a candidate&#x27;s knowledge while not being obnoxiously tedious or memorization-focused. i.e. someone who has written a lot of production code should do better in an interview than someone who&#x27;s just memorized every problem in Cracking the Coding Interview. So, ideally with the screening round clearing the first part (language-specific knowledge), and then 2 or 3 subsequent interviews that cover design and algos.

Don’t wait for the candidate to show up and then start a conversation about an algorithm (or technology or mathematics) that they may not be familiar with haven’t used in some time. Offer of some topics for discussion before the interview (e.g. Quadtrees, tries, infinity) that they can study, or read a white paper about and have some increasingly in-depth questions, applications and conversations about one or more of these topics.<p>No one is ever expected to solve an unfamiliar problem in a 60 minute meeting. Generally a story&#x2F;feature with technological unknowns are pointed for several days and are in the developers current wheel house, yet we expect a candidate to use most of their energy and facilities in a social situation with people they’re unfamiliar with and solve whatever random algorithm, riddle or puzzle that you Googled the answer to before the interview.

Speed and no trivia &#x2F; bullshit interview question. Interviews should be assessing me on the skills I’ll need to get the job done, not recanting some data structure or algorithm to solve a problem that’s unlike anything I’ll ever actually deal with.<p>Ask me about my past projects and decisions I made and mistakes I made and what I’d do differently. Sit down with me and actually code with me and get a feel for what that’s like. Ask me to how I’d design some actually realistic system, and drill into the details of each.<p>I shouldn’t have to train to pass an interview. Prepare, yes. Practice a bunch of problems unrelated to the job at hand, no thank you.

Describe what the job entails, ask me if I believe I can do it, and then hire me if I agree. Fire me later if I was wrong.

1) A test that tries to mimic what the developer would be doing in the actual job as closely as possible. This is what most interviewers fail at - they seek out stupid proxies like whiteboarding rather than simply trying to mimic real life.<p>2) &gt; 45 min &lt; 3 hours long pairing test or test otherwise done in the presence of the interviewer.<p>3) Minimal setting up development environments, frameworks or test environments. No boilerplate should be required during the test.<p>4) The test is improved iteratively. Catch bugs during each interview process and fix them in subsequent interviews.

I can tell you was a non-ideal interview process looks like from the &quot;coding challenge&quot; POV. I had one company pose a &quot;dev challenge&quot; of taking a multi-million row public sample data set and the goal was to generate a report from it. This was for an operations job &quot;but everyone has to take the dev challenge&quot;.<p>Part of the problem I had with this was that I didn&#x27;t feel like it was even a dev challenge. I&#x27;ve hand coded reports before and that has always led to a world of pain. I also felt like it was a data sciences challenge, not a dev challenge, and my data science is really rusty.<p>I spent most of the 1-4 hours they said most people complete it in, just thinking about the problem. &quot;If I had to solve this problem in my company, first thing I&#x27;d do is look at Crystal Reports. The last thing I&#x27;d do is open a file and type &quot;import sqlalchemy&quot;.&quot;<p>I set up a repo that did all the operations stuff (remember, it was a Ops job I was applying for), and put together deployment parts to set up a test system and load the data into the database, configure everything, etc...<p>A few weeks later I finally got the parts all to work and was able to solve the problem in an 80x25 screen worth of SQL. I suspect I was the only applicant that solved it in SQL.

For front-end positions, if I were interviewing myself, a 1 hour interview, as follows:<p>1. &quot;Imagine you are building a simple Gmail clone (search header, sidebar, action navbar, main content area). Walk me through how you would approach and implement this.&quot; (20 minutes: What architecture choices do I make? What tradeoffs am I comfortable making with this? Do I ask questions about the audience? How do I handle state management? How do I approach tooling for this? How do I approach testing for this? Lots of specific questions along the way..)<p>2. &quot;Tell me about an interesting article you read recently on a tech topic? Which resources do you use to stay current in the front-end space?&quot; (10 minutes; Am I committed to learning and staying abreast on an ever-changing landscape. Can I impress me with quality resources I&#x27;m in tune to? Also, can I effectively convey ideas at a high level; can I critique it and walk around the topic from various vantage points.)<p>3. &quot;Could you pull up your github and walk me through your last few public commits.&quot; (15 minutes: Gives me a chance to see my code, talk about the process of writing it? Are there tests? etc)<p>4. &quot;Would you mind code reviewing this [FizzBuzz-like] code and tests? Then, what would your next iteration on it be?&quot; (15 minutes; Am I a good team player? Can I communicate effectively? Can I spot areas for improvement?)<p>5. &quot;Finally, could you provide me with a list of past&#x2F;current co-workers&quot; (0 minutes; With this I will be able to assess what my peers thought of me? Work ethic? Pleasure to work with? Ego? Best qualities? Shortcoming?)<p>I suppose if the first question is switched, this could be used for any position.

After the initial phone screening for a full stack engineer, we send a take home questionnaire that doesn&#x27;t require any coding - but rather presents a set of questions that span across different domains (development process, databases, product, infrastructure).<p>The candidate selects 3 questions to answer from the set of questions. We expect them to take ~15 minutes to answer each question using the English language.

Our Android dev task: write a login&#x2F;signup dialog. Shows that you have layout skills, networking skills, general Java skills, etc. Candidates either bomb it or nail it, no mis-hires yet after about two years. You get a real good sense of experience level, confidence, and &quot;I like clean code&quot; attitude.

Speed.<p>Obviously not a complete answer, but I think it&#x27;s a component that isn&#x27;t being mentioned here. Disclaiming that I don&#x27;t have much experience (still in university).<p>One of my internships went from &quot;applying -&gt; interviewing -&gt; accepting&quot; in under 24 hours. Impressed the hell out of me. It was really the reason why I ended up accepting their job. 24 hours is obviously abnormally fast, but a week or two doesn&#x27;t need to be.<p>One of my friends ended up rejecting an offer both from Google and Apple because the interview process took too long with no responses. They got a good offer in the mean time, and after waiting over a month for a response they decided they had to go with it. (They followed through with the rest of the Google&#x2F;Apple interview process anyways for the experience... which was basically just host matching and getting an offer).

It should be clear about what they&#x27;re looking for, should be collaborative (I want to see if I can work with them), it should be respectful (ending it early for not a good fit is not a good reason), they should allow for you to talk to your strengths and not let it be a we are pushing you to failure.

A friend of mine is a UI designer and I really like how she gets interviewed. Her first interview during an onsite is to give a presentation about herself and her prior work. The audience are the 3-4 designers who will be interviewing her that day. This helps her set the tone of the future interviews and also gives an opportunity to show case her best work. We never get this chance during software interviews. I feel software interviews are like QA testing. The interviewers will each enter edge cases and see if you break under any one of them. Your resume might as well be shredded by the recruiter, cause it never gets read by the interviewers. You never get to paint a fair picture of yourself and that is quite frustrating.

Ideal, though unrealistic, would look like this.<p>Phone call from interested employer to ask a few questions back and forth. If things seem good set up an interview.<p>At interview, show potential employee where they will be working, what they would work on, then sit at a table for the interview. Potential hire knows their ability level and is honest with the employer about it. Employer knows exactly what they need in the hire and is honest with them about it. They come to a mutual decision about whether they are a good fit for employment there.<p>Interview done, and both parties know what to expect from each other afterwards.

I read many of the comments. There are lots of good suggestions. I believe these skills should be checked as well.<p>- to be able to explain something (whatever the candidate knows) by drawing boxes+arrows on white board<p>- to be able to write short and clear messages especially emails in corporates<p>- to be able to learn something new in a limited time<p>- to be able to document something clearly<p>- to be able to hack arhitecture&#x2F;framework&#x2F;existing mechanisms when necessary<p>- to be able to design something so that it will require minimum hack in the future (similar to O of SOLID)

I&#x27;ve seen many different formats used.<p>1. Focus on open ended questions with very little programming<p>2. Give very difficult algorithm questions 3. Take home assignment<p>4. Knowledge based questions<p>5. Brain teasers<p>By far I think the most useful is take home assignment as it is the most fun, relaxed, and realistic way to measure someone&#x27;s ability to code.<p>I don&#x27;t think algorithm questions are that realistic because usually they are unrealistically difficult.<p>Mixture of take home and knowledge based questions with maybe some algorithm questions of realistic difficulty is best.

The current role I&#x27;m in did a great job. There was a technical phone interview, but the in person was with the entire team and they gave me a ton of time to interview them and just have a conversation. It was fun and informal and I started the role with a pretty realistic idea of the people I&#x27;d be working with. The only thing I&#x27;d change is adding in time to actually shadow someone in a similar role and doing some pair programming.

<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18514637" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=18514637</a>

I will answer short and complex technical questions but I will not do technical tests anymore. Managers who are too lazy or not technical enough to know my skill level based on a conversation with me are not the kinds of people I want to work for. I&#x27;ve worked for a lot of companies and the most successful ones didn&#x27;t make me do any tests. There&#x27;s definitely a correlation.

1. Test for basic competence to make sure they know the language - what’s OOP, the difference between a class and an object, etc.<p>2. Whiteboard database design of a problem. I’ve found that it weeds out people who can’t model a solution. I also ask them to write queries that can answer simple questions.<p>3. A sample skeleton of a project with failing unit tests. They have to make the unit tests pass.

Ideal process for me is being placed in front of other engineers and discussing what I did in the past and how I understand their challenges. Meeting the team I’m working with is a plus to see if we are a match. I don’t do tests and stop the process before it gets to that. I also consider talking to HR a waste of time. The company should sell itself to me.

I like the following points touched:<p>1. Can you review code?<p>2. Can you work with product on requirements for X?<p>3. Can you design a system?<p>4. Walk me through the process to debug situation Y.<p>That&#x27;s it.

The top two comments are currently the most <i>complained-about</i> strategies (whiteboarding and take-home assignments). I think the best conclusion here is that for all the issues with the process, it&#x27;s not like there are a bunch of way better solutions just waiting in the wings.

I&#x27;ll tell you what really improved our successrate. We implemented a small IQ test and a small relevant coding challenge. Failure in one of these got you disqualified immediately. We started weeding out sub-optimal candidates real quick and were able to focus on the star talent.

I documented my ideal process here: <a href="https:&#x2F;&#x2F;tech.residebrokerage.com&#x2F;how-we-hire-software-engineers-4cb5034ad09a" rel="nofollow">https:&#x2F;&#x2F;tech.residebrokerage.com&#x2F;how-we-hire-software-engine...</a>

Am I the only one who feels strongly that people should be paid for their time to do coding for you in interviews? I feel like every company has some small tasks they can have a potential employee take on.

Take home coding challenge, timed if possible. The on-site should be standard whiteboard style questions, but focusing on problems that are more related to the job.

It would be just like a Vulcan mind meld and when it&#x27;s done the interviewer would say, &quot;Yeah, you&#x27;re good.&quot;

I wish I&#x27;d had &quot;a real plan&quot; in jobs past as an individual interviewer in a series, instead of a vague goal like &quot;talk about his technical chops&quot; or &quot;see if she can work across teams&quot;. I turned out not to be very good or consistent at either freestyling questions completely OR reporting reliably whether a candidate was &quot;successful&quot; in my area without planning and consistency.<p>I&#x27;m a former developer, turned hiring manager for a very technical support team and employ several things I feel are fair and useful and I believe would also have been in that past life.<p>0. repeatable interview process. When comparing candidates, the comparison should be apples:apples. &quot;check for culture fit&quot; isn&#x27;t; &quot;ask questions 1,2,3 of each candidate, with goals of finding out x,y,z and help to N degree if requested&quot; is. Leave room for the candidate to demonstrate personality and style of course, as well as (short) tangential conversations that come up during the Q&amp;A process. The goal isn&#x27;t to make it robotic&#x2F;automatable.<p>1. There is a take home exercise. It has a clear scope:<p>- accomplish goal X (create a website)<p>- with tools like Y (your choice of static site generator)<p>- in Z fashion (public github repo)<p>- in less than 4 hours.<p>Encourage questions before candidates begin the exercise, so that people work on the right problem rather than guessing wrong. Don&#x27;t force a timeline (&quot;you have until the job closes which won&#x27;t be sooner than a week from now&quot;), and use an objective grading rubric for each section of the task.<p>Here&#x27;s an example of the objective rubric: 1 point for grammar, 1 point for each of two distinct points of content, and 1 point for providing the context as to why those are important points. Few of the questions have only one correct answer and it is not always obvious to candidates what we&#x27;re looking for in an answer; but it is known in advance to the grading committee what is being sought, e.g. &quot;perspective over plot&quot;.<p>2. interviews are in slack. We&#x27;re a remote team who communicate 95% via writing, and it doesn&#x27;t matter if you stutter or what you look like or how you present. Get comfortable in your PJ&#x27;s with a cup of tea, or use your standing desk if that helps you feel sharper. It only matters how you communicate in writing.<p>Once again, the interviews are structured - &quot;interviewer 2 will ask these 5 questions&quot; and the criteria for success aren&#x27;t &quot;this woman was well spoken&quot; but instead &quot;she showed ability to think on the fly about something unexpected, demonstrated empathy in communication, and made a compelling argument for her proposed solution&quot;. Not quite as objective as the take home test, but still &quot;gradeable&quot;. And, in case of a hard choice between two candidates, other stakeholders in the hiring process can review the transcript of the chat, providing their grade considering the pre-specified criteria, to help decide.<p>It&#x27;s not ideal, but it is practical, allows for cooperative interviewing (anyone can help a candidate start the well-documented interview process; anyone can do any stage of the interview and know that we cover all the questions we want asked before the end), and encourages consistent judgment.<p>It&#x27;s worked well for us so far and people have appreciated it; it also lets us give concrete answers to &quot;what could I have done better?&quot; to candidates we reject who ask for a follow-up. I feel pretty strongly that you spent your time working with us (particularly on the take home exercise) so I can spend time explaining how you could improve (often it is useful to other applications for other jobs: &quot;your code should have comments to explain confusing things or highlight clever things&quot;, &quot;consider using git for revision control rather than only committing your completed project&quot;, &quot;you&#x27;d benefit from using a grammar checker&quot;). We&#x27;ve had many repeat applicants who answer better with each iteration.

- For someone fresh out of college: Don&#x27;t change anything, the current process is perfectly designed for college grads. So Leetcode it is and whatever the google&#x27;s, facebook&#x27;s, etc, are currently using to hire &quot;the best of the bests&quot;.<p>- For someone with 2 to 5 years of experience: A candidate should have a choice between a full day onsite, working with the hiring team on a mini feature or a bug fix. Or, a 1 week project assignment with a shared&#x2F;public repo between the hiring team and the candidate. In this case the candidate could work remotely on the evenings&#x2F;weekend. Code should be reviewed and pushed into the repo at the end of the assignment period. Collaboration along the way is highly recommended for the candidate. The hiring team should be at least available to answer the candidate during the process. The onsite would ONLY be a lunch with the team to get to know each other. If the candidate chose the 1 week assignment, he or she would have to stop by for the last step if everything went well, which would also be a lunch with the team to get to know each other.<p>- For someone with 5 to 10 years of experience: Same as 2 to 5 years of experience, but would involve more technical choices from the candidate. This could also be a feature or a product optimization task, etc. Requirements have to be very high level and the candidate has to make design choices and define a scope as well as delivering a working prototype. If the candidate is closer to 10 years of experience, he or she should assign a coding task to at least one member of the hiring team and make sure to help and review the work. This process could also work for +10 years of experience as a Dev, or even a &quot;Tech Lead&quot;.<p>- For an engineering manager: No Leetcode please! Stop now! :) The candidate should take over the current sprint from the hiring team, or part of it. This could also be a sprint exclusively designed for the interview process. Stories could be made up or could be real stories from the team backlog. This could be a 1 week project assignment. As a Hiring manager you should be able to keep track of stories and to host standup meetings remotely with the team (5-10 min conference calls all week for example). The team would simulate blocking issues and conflicts between peers and the descriptions of these problems would be sent to the candidate for review. You would have to show up onsite and host 1-1&#x27;s with the related folks in order to go over these problems to try to fix them. This would also include a team meeting to share the status of the project with everyone. During this day onsite, they might also simulate a mini hiring process for a new Developer. Team members would be the actual candidates and you would be the interviewer (a quick 15 min interview for each candidate). Other hiring managers would be involved in this process as well where you would discuss about the candidates and make a final decision.<p>That&#x27;s it. As you can tell, this would require companies to do a lot the work in order to set that up. Unfortunately, not enough energy is allocated to hiring new people. Companies rely on the existing and broken process started by Google in the late 90&#x27;s... this was the only company asking academic and weird puzzles to candidates. Also, I cut a lot of corners because my post is already way too long, but you get the picture...

No whiteboard code, no algorithms questions. If you want them to code, let them do it on their own time in a comfortable environment. The industry needs to stop the bullshit leetcode meme that millenials are propagating.

no whiteboard

That depends on the needs of the company doing the hiring.

I&#x27;ve spent alot of time thinking about this, and I&#x27;ve concluded with this:<p>Hire local people minimum wage to learn and teach each other coding structured around your company&#x27;s codebase. Once they get to know the basics, have them work on your company&#x27;s open source projects. Identify the ones who actively help others and convert them as a full time software engineer.<p>It takes an average person about 1 year to learn enough basics to contribute to a codebase, and paying someone minimum wage only costs about 30k &#x2F; year so it works out financially on both sides.