Why Technical Interviews Work (And Why They Don’t)

Some developers see technical interviews as just part of the process that they have to put up with when they’re looking for work. Others think they’re great, and a great deal more think they’re the worst thing to happen to programming since <insert most hated programming language here>.

Frustrated ProgrammerHaving made a business out of helping people prepare for coding interviews, let me be the first to say this: Technical interviewing isn’t perfect and I don’t think it is the way to interview a candidate. However, it has its benefits — if you understand why a company is asking such questions.

By technical interviews, I mean interviews were managers ask software developer candidates to write code on a whiteboard and solve algorithm problems. For example, a typical question might be something like, “Write code to rotate an NxN array in-place (without using additional memory).” Or, “Design an algorithm and write code to find the longest palindrome in a string.” It might even be something like, “Write the binary search algorithm.”

A lot of candidates object to such questions, arguing that if you have such a problem in real-life, you’d just look up how to do it. That’s fair – except that’s not why you’re being presented with such problems.

Here’s Why

A company asks coding / algorithm questions not to test you on specific knowledge. They don’t really care if you know how to find the longest palindrome in a string. If you happened to know the solution off the top of your head, it wouldn’t really earn you any bonus points. Or, at least it wouldn’t with a good interviewer.

Employers ask these questions as a way to “sample” your problem solving and coding skills. They don’t particularly care if you know how to solve that particular problem, but they do care about how good you are at solving challenges that you haven’t seen before. So, they throw a bunch of questions at you that are hopefully new to you. By asking you a bunch of different questions, they can sense how strong of a problem solver you are in general.

In some cases, you’re absolutely right when you say you could look up the solution if necessary, or call an API to do something if there’s one available. Unfortunately, you won’t be able to do that in all problems in the real world. That’s why these questions exist.

Is this process perfect? No. Some companies put too high a standard on performance here, thinking that there’s a substantial difference between a candidate who does well and one who does very well. Some focus so much on these questions that they don’t look at factors like your references, personality, work ethic, prior experience, etc. And, there’s a lot of great engineers who just don’t “test well” on whiteboard coding interviews.

So these questions aren’t perfect tests of your ability, but there’s good reason to ask them, at least until we can measure a candidate’s ability strictly by his/her resume. I’m not holding my breath for that day, though.

Image: 123RF

48 Responses to “Why Technical Interviews Work (And Why They Don’t)”

  1. I’d like to see tech companies interview people with a little more smarts than just coding tests.

    A lot of the startups in Silicon Valley like to put everyone through a 4-hour interview process, no matter what their technical position is, where they spend some time on code challenges, and testing the candidate with trick questions and meeting team members and talking about how they would do things. This method is really annoying on a lot of fronts. It devalues actual work experience, and accomplishment, and completely misses the potential capability of the candidate for work over the long term. If the candidate is a contractor it can be reasonable to meet certain short-term thresholds on coding, but an employee candidate is more about potential than just skills. You should be able to consider a candidate for hire within a one-hour in-person interview. Trying to find out every possible flaw in a candidate wastes everyones’ time. You should focus on knowing about a candidates’ success, why they want to be here, and try to get a feel for where they are headed. These kinds of questions allow a manager and leaders the opportunity to learn if a candidate can actually align with the company, the team, and the work.

    The most important skills to me are people skills. Work experience is important, but far more important is the passion in the candidate to want to do the work and their “want” to work with others. I can take a less-experienced person with a lot of drive and passion and get more contribution than somebody who has low drive and a lot of experience. To me, drive is worth more than accumulated experience.

    My expectation as a candidate when I walk in to their business is to learn about why they selected me as a candidate, what the “job” is all about, who I report to, and what kind of team, if any, I’m going to be a part of. Meeting the team is important, but I also like to think that I’m probably not going to be selected if the hiring manager doesn’t like me, end of story. There are also probably team dynamics that the hiring process is going expose, and team members don’t always interview with an objective agenda. In fact I’d wager that a lot of teams actually find the interviewing process annoying as much as the candidate, and may actually approach the candidate with a certain amount of contempt. The hiring process belongs to the hiring manager, and if they cannot make good hiring decisions, no amount of team input about the candidate is going to help. The hiring manager should set the agenda on why the candidate is being considered and stick to that expectation. The team needs to fall in line with that, end of story. You can also weed out a lot of information about a candidate in the phone interview without having the person even showing up in person. You should know by the end of the phone interview if this person is a real candidate you want to hire. Candidates who show up in person should be the ones you’re actually considering for hire. Your team should know the hiring managers’ expectations, and stick with those expectations to drive the process.

    As to interviewing candidates, if my team has read their resume, the expectation is that the candidate can do the things they say they can. A couple of trick questions is ok, but I’d rather find out more about the person than whether or not they can code the answer to a trick question. We’re living in an age of “no-reason-necessary” to cut people loose, with the abundance of “at-will” contracts, so it shouldn’t be a difficult thing to focus on how the candidate will fit in to your organization, and set expectations for how they will succeed. I believe the success of the new team member lies with the manager, and how they groom that new team member. Over time they will align or they won’t. Even the military gets this. They hire, put people through basic training, and some people don’t make it. Others that do, evolve and stay with the team.

    I’d like to know more about how a candidate can start a project and what kind of framework of work process they would use to work on the projects we would have for them to do. I know we’ll enforce a lot of our own processes for them on run-the-engine, so we don’t need to worry too much about the mundane. I need to know if the candidate can align to the core business, and follow along and work with my team. This is first. Secondly I need to know if the candidate can work on the projects, and how much of a gap exists between what they’ve experienced, and what they need to learn. This makes it much easier to pick a candidate. You don’t always need to pick super-stars in coding when you can get somebody with less experience that can grow into the job and show their eagerness to prove themselves. You get a more dedicated team member who will grow into the work. A candidate that shows willingness to learn new things is far more attractive to me than anything else.

    • I’m not sure what you mean by “trick questions.” Trick questions are rarely asked.

      A typical algorithm question would be something like “Design an algorithm to search for an element in a 2D matrix, where the rows and the columns are sorted.” This isn’t a trick question because the interviewer isn’t trying to trick the candidate. The interviewer is trying to get a feel for how good the candidate is at solving new problems.

      The goal of these question is to discover how good a candidate is at problem solving. This is to find candidates who can grow into the role, even if they don’t currently have just the right skill set.

      I agree that these questions largely miss the candidate’s personality. However, I’m not sure that just chatting with the candidate gets at that either.

      And unfortunately, while we live in a world in which companies *can* cut people loose for no reason, we also live in a very litigious society which makes companies scared to fire people.

      • Gayle,

        Your typical algorithm example question is a perfect example of a trick questions. you wrote
        “Design an algorithm to search for an element in a 2D matrix, where the rows and the columns are sorted.”

        It’s like asking what order should you change the six wheels on a car if you get a flat tire. The answer should be “does not computer, the question is flawed” because you shouldn’t have 6 tires on a car and if you get a flat you shouldn’t change all of them, you just change the one that’s flat with the spare and get on the road till you reach a garage and get a new tire. Let me explain. . .

        “Why does the car have 6 tires?”
        “Why do you have a 2D Matrix sorted on both rows and columns”?
        – Most of the time data simply isn’t that agreeable for example the 2D array I show below. . .

        Adam, $20
        Bobby, $10

        If you find this kind of data is sorted on both rows and columns the appropriate question is who messed it up and what do we have to do to get the data integrity someone else messed up before asking me to do this and why are you asking me to do something that will make the problem worse. . . . Maybe you mean “Sortable”? or maybe you mean it’s one dimensional data that should have been encoded as a one dimensional array because that’s a possible error made in the design that can result in a 2D matrix that is found to be sorted on both rows and columns. It’s hard to actually imagine a business scenario where you get a 2D array with data that is sorted on both rows and columns simultaneously.

        “Why do you want to change all 6 tires on a car because you got a flat?”
        “Why do you want to sort through an entire array to find an element”?
        – You want to find bobby and look up how much money he has so you don’t search the money column, just the name column. . . . generally you only sort through a single column or row of an array to find an element and then you use that to find a corresponding element that is different by a row or column. I can imagine a rare need for this in web design to show a table that you can filter based on a search field. Ok, sure and if you have a trailer hitch on your car you need to rotate all 6 tires for the trailer too because it happened to break down at a gas station where they had a replacement tire and it’s a certain type of trailer and weight load that matches the car so you rotate all tires now and the garage mechanic didn’t know that. . .

        • Steve,

          It is not a trick question.

          Here’s a matrix where the rows and columns are sorted:
          10 20 30
          11 21 31
          12 22 32

          It is not a trick question to ask how you would efficiently find an element in such a matrix.

          Now, if an interviewer is looking for a candidate to say, “But you shouldn’t have an array that’s sorted on its rows and columns,” then sure, it’s a trick question.

          Likewise, it’s not a trick question to ask (though it might be a stupid / irrelevant question), “Suppose you have a car with 6 wheels, all of which are flat. In what order would you change them?” As long as you’re actually looking for an order of the wheels, it’s not a trick question. If you’re looking for a candidate to object to the question, then it is.

          • Not a trick question.

            You conviced me. Sorry for the impression my comment might have given others about your technical interviewing skills. I was wrong to say that was a trick question. . . Mostly. . .

            Your matrix example confirms an assumption I discarded as unlikely, which is that this is a pure math, or optical/science instrument cluster data set. Those are some of the few business use cases I know of where your question has any practical application. Assuming I knew the industry or need was for processing instrument data and using matrix math theory then yeah, my trick question claim was kind of objectionable.

            On the other hand, the one of the definitions for identifying a trick question is that the correct answer requires making an assumption that is not held commonly by the question asker and the answer. So if you ask this question of a programer applying for work on a CRM (Customer Resource Managment) or other non-science engineering field it does seem like a trick question deserving an answer of “what went wrong with the data before me”. I work with that area and trust me asking questions like that is often essential to getting the job done right and preventing a lot of pointless re-coding.

            I agree your final point that “If you are looking for a candidate to object to the question it’s a trick question.” I think that’s a problem with many technical interviews that they are disingenuously used to test a candidates non-technical behavior. As you suggest, a failure mode of the technical interview is that it is sometimes used to test a candidates social skill in identifying and compliance in promoting as technically valid the solution preferred by the interviewer.

            In your case, your wording makes me suspect you’re aware of the this failure mode and mentioned the “objection” part as a general caution and not one you place incorrect emphasis on.

            —– As for the question solution ————

            Someone here stated that the a good answer is to state some guess to the question. . .

            Pick a point in the middle of the array, and search in the direction (towards top left if smaller or bottom right if larger) based on the value for fastest results. You need to keep searching adjacent cells till you bump up against a too large and too small cell for every row (or column) or else reached the matrix bounds. Depending on the data you could get 0, 1, or many matches. Processing efficiency matters in large science data sets. In this case the most efficient algorithm depends a lot on data and efficiency of loop and logic statements but there’s some formula using expected ratio of N(matched)/N(total) to optimize search routine and we care if it’s a very very large matrix as often happens with science data.

            Then the suggestion is point out that research can provide better perfected solutions as well as syntax. . .


            ——————– digression? —————–
            This is much more detailed than most people go into, but seems on topic for the subject of “why technical interviews work and why they don’t.” Bullet points are great for agreement or disagreement, but you need a page to introduce a new or unfamiliar concept.

          • I find that question quite easy to be fair. A good answer would be:

            1. Look in the first row and find the maximum number that is not higher than the number we are looking for.
            2. Look in that column for the number we are looking for, by using any divide and conquer algorithm.

            Now that took me not more than 1-2 minutes to figure out and I can even explain the complexity of the algorithm out of my brain: It’s O(n) + O(n/2) ≃ O(n). But in an interview my brain would be frozen. I just don’t cope well under the pressure of eyes. Even at school I would not be able to answer to simplest questions when the teacher was staring at my eyeballs. In such situations I only did good if I had practised at home. That’s why I did remarkably well in presentations.

            Does that mean I might never find a good job? Maybe. I think I am an above average programmer but the technical interviews, they always made my brain spaghetti and that’s what I probably get out to the interviewers (and get rejected).

      • Dejay Clayton

        Technical interviews are a very valuable tool within the hiring tool arsenal, although they seem to highly polarize the programming community.

        I use technical interviews to discover the following about the candidate:

        1. Is the candidate capable of discovering the relevant aspects of a technical challenge by successfully communicating with the interviewer? Good programmers are a dime a dozen. Great programmers can meet with team members from completely different parts of the company, engage in constructive and directed conversation to arrive at understanding and consensus, and apply skills and personal experience towards those aims to help identify possibly solutions to the challenge. This stuff happens in real life all the time, and successful teams are composed of members who can see outside of their own sphere of context and discover the wider implications of the discussion at hand.

        Often, when I present technical challenges to candidates, part of my evaluations consist of seeing how well they can communicate and arrive at productive discourse with someone who is not on the same wavelength as them, which is a critical skill for successful developers.

        2. Is the candidate good at systematically analyzing a technical scenario? Some of the bedrocks of successful development, such as identifying and accommodating a separation of concerns, are often learned through considerable professional experience. I want to be able to tell whether a candidate can analyze a problem with these critical problem-solving skills in mind. Or are they going to write spaghetti code because they don’t know where one system component should end and another should begin?

        3. How familiar is the candidate with various aspects of their development expertise? I generally detest evaluations based on rote memorization of syntax minutia, but if you’re interviewing for an advanced JavaScript position, you had better demonstrate that you’ve at least come across closures, “call”, and “apply”, and know how to use them to constructively solve problems. Similarly, if you’re interviewing for an advanced Java position, you had better demonstrate that you know when a problem calls for using comparators.

        Personally, I tend to find riddles and brain-teasers worthless as an indicator of nearly anything. On the other hand, I find that asking candidates to participate in code reviews to be extremely indicative of their overall experience. If a candidate can’t point out the two spots of code where something is hard-coded but should be, and another where it makes sense to abstract a method out one layer of the diagram, they probably haven’t been doing so much during their day job.

    • Tim, I think much of what you say is spot on. These little technical interviews are pretty silly and largely a waste of time. I would much rather look at a candidate’s code sample and/or portfolio of work- where they have addressed a real-world problem in an actual work setting. This is why for developers it is so important to find a way to get something open source up, that others can freely view.

      And, as you say, being motivated and a team player trumps most other requirements, once they have the fundamental knowledge and ability.

    • jaydub

      Tim, you’re 100% correct. I’ve been doing technical recruiting for 15 years, and really think we need to re-work the interview and selection process. You’ve given me some things to think about, toward that goal.

  2. This is always an interesting topic, since you need to determine whether interviewers can “walk-the-walk” and not just “talk-the-talk”. However, my experience is that most interviewers don’t really know how to draft an interview and also don’t know how to interpret the results. Instead, they simply treat you like you’re “on a date” and they want to see if there will be another date. Of course, personalities are important at any company, but you don’t use a technical test to find out.

  3. I’m not at all opposed to coding tests, even though I could have never passed anything other than a simple Fizz Buzz. =(

    But I don’t understand why whiteboards are used. It seems to me like it would be better to sit the applicant down at a computer and have them actually build a program right there.

    • The main reason to use whiteboards instead of computers is that it’s about the general coding and problem solving skills, not about getting every last detail right. Using a computer forces a candidate to know all the little syntax details (“is it list.append or list.insert??”) in order for the program to run. Technical interviews are (or shouldn’t be) about that, so it’s a distraction. It’ll slow down the candidate and not allow the interviewer to spend time where it really matters.

  4. In general, I agree that whiteboard “coding” is bizarre. The tools are there to do everything on the computer.
    However, it’s good to know that you can handle a collaboration session, but then they really shouldn’t care so much about the content ans should ask a question like, “can you spec out how to build a widget?”
    So if they really want to know if you should code, they should put you in a coding environment. If they want collaboration, they should say so.

  5. Dejay Clayton

    One of my favorite interview strategies is to have the candidate perform code reviews on existing code. You can tell so many things about a developer based on the aspects they focus on and demonstrate expertise with during the evaluation of something that’s already been done.

      • Of course there are some companies that know their stuff, but even there, they are often looking for conformists to sheepishly follow their ways of thinking…sometimes that’s fine but other times you need to “think different” but they don’t like that.
        On the flip side, I’ve seen too many companies who know nothing about technology and get taken in by glitzy programmer-wanna-be’s who can trick these poor places into hiring them and then they get stuck with technology that either doesn’t fit their needs or quickly becomes obsolete because it wasn’t built with the proper flexibility needed to grow with the company.

        So obviously there’s a balance in how to determine if a candidate is qualified without losing a great candidate because you tested him/her the wrong way.

  6. Tim, I want to work with you, because you “get it”.

    I’ve been through a highly technical interview for a Technical Program Manager job with a currently popular firm, and I don’t think it was the most effective method to select the candidate that will be the most successful in the job. As an example, the most technically competent candidate who is able to shine “on the whiteboard” will not necessarily be the best at negotiating with stakeholders, handling team member dynamics, and organizing an effective plan to ensure success of the project.

    It’s an interesting predicament that relies heavily on competent interviewers, which is not always a guarantee.

  7. The algorithm question that Gayle mentioned seems legit enough..not too simple that people heard of and not too hard but ego engineers like to throw at candidates. They just have to talk out like their analytical process even if their coding syntax is wrong (should be 80% correct I would say). I have seen anal ego engineers demand correct sytax and optimize algorithm.. which is BS.

    I worked in a company where all engineers must have MS or PHD depending on the department..(say meshing) they are applying for a position, they asked them to show them a webex or what they had done related to the job for about an hour to a bunch of engineers and then ask them question about their project..anywhere from project management, people worked with and also technical as in how they come up with that solution to the problem (coding or whatever)..(like a phd thesis presentation to professors).. that is the screening and then invite them for onsite describing more about their project and get a sense of who they are, work ethics. Never did they tell them to do a white board and ego engineer crap. The result is 99% (no kidding) of all the new employees did perform as expected on the job.

  8. Technical interviews suck. I have built enterprise-level systems with a lot of functionalists and modules, but I couldn’t pass amazon interview. This really young guy, probably with just one year experience, asked me to do some crazy recursive algorithm on a white board, and I could not write the efficient code that he was expecting. No body can convince me that I am not a competent programmer, I have the record, but they didn’t care. I really don’t think these technical interviews are the way to go.

  9. I think technical interviews are best at finding the hidden gems. Lots of employees, like me, have made poor choices in the companies they work for or didn’t get the opportunities to work on award winning projects. Without a technical interview recruiters and HR have only a track record to judge a candidate by. The job history says more about a candidates career management focus then their job duties and core work skills.

    On the other hand technical interviews can be done poorly too so they aren’t a solution every HR dept can use effectively.

  10. Asking basic coding questions gives you what you want from a technical interview. You can obtain a lot of technical and problem solving information by asking questions about the projects a candidate has worked on. The candidates experience and story should count a lot more than just syntax.

  11. Stinger51

    Hiring the best candidate is like the NFL draft — you never really know how the player is going to work out until he’s on the playing field. Despite all the combines and fancy athletic performance tests, etc., etc. we all know there have been many major draft “busts” over the years.

    So it is with companies looking for people. This is not to say that technical interviews are not important. We don’t want to hire a programmer who doesn’t know how to construct a simple for loop or search through a file. But “Design an algorithm to search for an element in a 2D matrix, where the rows and the columns are sorted.” Really? I couldn’t even begin to answer that question for the life of me, especially during the stress of an interview! But I CAN look it up.

    I understand that the company is looking at how a candidate might work at solving a problem. As you say, “By asking you a bunch of different questions, they can sense how strong of a problem solver you are in general.” But to solve this type of problem I need my computer and all my reference books (on-line or off). That is, after all, what they will be paying me to do — solve problems. And, other than very simple ones, I can’t do those standing in front of a white board. Sorry, I’m like Einstein. I can’t even remember my own phone number. But, as he reportedly said, I CAN look it up.

    Yes, the entire interviewing process sucks, just as the NFL draft does. You can’t really tell, as I’ve said, the difference between a Ryan Leaf and a Payton Manning until you get them on the playing field, no matter how well they might do during any “tests.” In that sense, companies (and sports teams) would do much better with other types of evaluations than just technical (or athletic) ones if they are truly interested in getting a good feel for how someone is going to work out for them.

    My late step father, who was an accomplished civil engineer, used to tell me that a company does not get any really useful work out of you until you’ve been there at three to six months. I used to think he was crazy. But the older I get the more I realize he was right.

    • This is not to say that technical interviews are not important. We don’t want to hire a programmer who doesn’t know how to construct a simple for loop or search through a file. But “Design an algorithm to search for an element in a 2D matrix, where the rows and the columns are sorted.” Really? I couldn’t even begin to answer that question for the life of me, especially during the stress of an interview! But I CAN look it up.

      I agree and disagree..actually, anyone who claims themselves to at least code before should know how to construct a simple loop or search through a file. In fact, it is a very valid question to ask and but when these simple questions are ask, what the interview should focus on it’s the SPEED first and then correctness of the program because they are so simple it should be like like what is 10+10. (or gauge what questions the interviewee will ask back first..or later.. such as do you want it optimize or is it just a simple thing?). (semi-pseudo code such as incorrect syntax, but close enough for like opening a file or something should be fine because those are basically api libraries..and programmers know they look up apis definitions instead of remember it all the time (just like looking for a book in a library)

      As far as the design algorithm question, those should be asked AFTER that pass through those simple ones with flying colors. I think the question ‘design an algorithm’ will scare off the interviewee especially when they are stress, so it should be rephrase to “search for an element in a 2D matrix, where the rows and the columns are sorted”.. once the word design is out of the question, it less stress and allow the interviewee to just do it without optimizing/designing/finding the best way. That question is good enough to see what he does…not by coding, but by thinking.. (does he draw out a simple matrix first and pseudo code, etc). If he writes pseudo code, that should be fine since you can learn the syntax for any language.

    • I’m sure you can look up how to do many things (and you should do that, in the real world). But what happens when you get a problem where the answer isn’t available online? Obviously, a lot of what you’re going to do isn’t going to have an answer available online.

      In this case, if you really couldn’t “even begin to answer” how to search in 2D sorted matrix, then you’re not the right fit for this sort of company.

      I doubt, however, that you couldn’t even begin to answer this question.

      For starters, you *hopefully* realize that you can just search through the entire matrix. That’s “beginning” to answer the question. It’s not a great solution, but it’s a start.

      You might even realize that you can do binary search on each row to find the element. Again, not the most optimal solution, but it’s a start.

      With some work (and with an example up on the whiteboard), you might be able to make some more optimizations. That’s how you solve these problems. You start with a basic solution and then you try to improve on that.

      If you truly can’t “even begin to answer” these questions, then you *aren’t* the right fit for these sorts of companies. You are either unable to solve new problems (or just think you are unable to), or you lack an understanding of the fundamentals of computer science (such as knowledge about binary search).

      Of course you can look up how to do some things — many things — in the real world. But you can’t look up how to do everything. Some problems have just never been solved in precisely that way. Or, it could just be that it’d take you too long to look everything up. Would you want to hire a programmer who had to look up how to write a for loop, while loop, if statement, etc — every time they needed to use it? Probably not. It would be a bit of a red flag (why haven’t they “memorized” this stuff?), and they just wouldn’t make good programmers because it would take them forever to write code.

      • I had a technical interview where I was asked to write html code to show a table and sort it. The interviewer hadn’t thought out the question and wanted to “test my creativity.”

        I started with pointing out users don’t want a table that is creative, they want tables to display information clearly. From a code architecture and maintenance point of view creativity = non-standardized and buggy. It’s bad design to re-create the wheel on every project and leaves other designers with a patchwork of creative unique solutions that’s a nightmare to maintain. I recommended a semantic HTML table with jQuery powered functionality from Datatables.net and said the styling could be done by creating a Themeroller css file that was neat because the css was compatible by design. It would be quick and easy to create, highly usable, and was the better solution to a one of a kind hand made table with unique creative sorting code. In terms of best user experience, best code architecture, best solutions are rarely about being creative.

        The interviewer apparently didn’t know about Jquery Themeroller UI and had never heard about DataTables.net and insisted this was a test of my creativity to solve new problems.

        the interviewer insisted we write out HTML and wanted to test my CSS3 knowledge by having me write code for rounding corners and jQuery for sorting the table and I pointed out a good table has alternating colored lines and you need some fairly complex JavaScript to keep the alternating lines different colors (actually mentioned every 3 lines changing color was the most optimal for readability) even after sorting dynamically since when you change the order you have to go back and re-color the backgrounds. From my past use of the data tables widget it was already built with the functionality and it had been well tested and that was another good reason to use it.

        I think a technical interview is a good way to learn how a person thinks, and what they have already researched and learned. It could also be used to test creativity, but the above shows how this is often miss-used. The website for the company I interviewed at was a mess and they had a slideshow/carousel created with a math library and broken css on the home page. He said he would be impressed with my JavaScript skills if I could write a JavaScript program to play chess. It showed his interest in very creative miss-use of technology. His final verdict was that I couldn’t think creatively for problem solving. . .

        • Part of it being ‘abused’ is due to the ego of the interviewer. If you know more than the interviewer, you will make him look clueless and thus that have a sense to defend himself. But if you are about to softly make it so that he does not feel threaten, than you should be in a good hands.

          For example, after their questions, instead of blatantly saying why do you need to do this as there are other alternatives, or say you can ‘look it up’,etc, you can just answer it first and after that explain actually instead of writing it out, you could’ve use another alternative.. so it shows you have already answer the question and know another alternative.. Or say actually there is another alternative, but you will just answer it anyways. It’s an art knowing how to make it so interviewers doesn’t look bad. But that’s also in life too .. EQ.

          Key thing is not to sound cocky or too concident or condescending.

          As for writing javascript to play chess…if he did ask you to do that in the interview, I don’t think you would want to work with that person if you got into the company. Anyone knows that it’s not a 45 minute thing and there is no way to check if it works on a whiteboard (assuming there is no computers in the interview room).

          • Dejay Clayton

            Actually, writing a chess program in JavaScript is not terribly challenging. However, writing one with strong chess AI is pretty difficult. It’s still fairly easy, though, to write a chess engine that beats an average player on moderately decent hardware.

          • Thanks Ben, that’s good personal advice and would improve my personal success in today’s business world.

            You wrote. . . “It’s an art knowing how to make it so interviewers doesn’t look bad.” I think you nicely summarized why some of the more technically superior candidates object to technical interviews. I think you’re confirming some comments others have made about a common failure mode for the technical interview.

            I have to point out that you’ve misused the word condescending. Condescending is actually the opposite of what my original response was and applies more to your recommended response. It would be condescending to focus on flattering the interviewer by following your advice. To Condescend is when you treat someone as week or inferior as for instance needing to give them an answer that flatters them and hides their ignorance. If I say to someone “your wrong, this is a better idea” it’s not condescending. If I say to someone with a bad idea, “you have a good point I hadn’t thought of that, here’s another idea too” it is condescending.

            I think highly analytical top performers base their self worth and the worth of others on technical skills and abilities of reasoning and character so they often deplore power and authority as a measure of a persons superiority. I think you could be describing a need for humility in presenting answers during a technical interview, which is another hint to why some people get offended by them.

            Sorry if this seems combative, I appreciate your comment and think you made some great points. I think technical interviews are probably and sometimes done well and a good idea.

            p.s. No, he didn’t expect me to whiteboard JavaScript to play chess. At the end of the interview when he asked if I had any questions for him. . . I asked him “if there was one areas of weakness in me as a candidate that he could identify and what it would take to overcome his concern on that area of my ability.” His response was that I hadn’t shown him much JavaScript skill and making JavaScript play chess would impress him. He had actually mentioned in passing during the interview that getting JavaScript to play chess was a personal hobby goal of his to show the potential of JavaScript. In my thank you follow up letter I sent him a link to a Stackoverflow.com discussion on resources and community links for JavaScript chess libraries and projects. No response. No job. The recruiter relayed that the interviewer was unimpressed with my creativity during the exercise.

          • LOL. Mark Twain and I are in total agreement on spelling.

            I’m all about the concepts and I have so little respect for arbitrary rules that serve no function. It’s a great personality trait for doing a tech job well, but for sure, spelling hurts me more than my attitude in the job search.

  12. In the mid-1980s, when I first started working, lots of companies, including the startups of that time such as Cisco, SGI, and Sun, were able to interview people, make offers, and get useful work out of their new hires. They were able to ascertain candidates’ problem solving skills by asking them questions about a recent project at another company, a senior project, a lab project, etc. Candidates used whiteboards to explain their design rationale, give pseudocode for the algorithms they used, argue for/against certain engineering tradeoffs, etc. There was no need to ask people to implement binary trees, quicksort, etc.

  13. I feel compelled to weigh in on this subject. I am currently on the job market, and am working my way through this interview process.

    While I understand that the purpose of this interview process is to find those engineers with the best skills, it seems that, instead, the process is focusing on the minutia. It also seems a bit silly to ask an experienced software engineer to perform basic programming tasks, but especially painful be asked and not perform well (which I have also done in earlier interviews when anxiety chased my brain away).

    It’s especially frustrating to me that these interviews don’t focus on any of the skills that I consider make me a good engineer. Being able to implement a simple algorithm (simple enough to be implemented in an hour) is such a minor part of the job of software engineering. It does nothing to address understanding requirements well enough to anticipate where the likely extensions would occur, architecting code in a way to allow for such extensions, accommodate reuse, and minimize redundant code. It does nothing to address writing code in such a way the the person coming in after you can understand it. And so on…

    Most of the programming tasks I have been asked to perform so far, have been with a very tight clock in an interview, or timed in an automated programming session. In order to accomplish these interview tasks quickly, good programming habits largely get thrown out the window. Some specifically caution you not to try to make your code robust. Just get it done quickly. What is the point of this? I’m not sure getting the best “sprinter” is really going to find you the best engineer, let alone the best fit for your position.

    The last time I was on the job market (and here’s where I age myself) was in 1990. The process has certainly changed since then. Whether it’s for better or worse I am probably not in a position to objectively judge right now.

  14. Jesse Cronce

    I have done probably a hundred technical interviews over the years. I have a standard list of 10 questions ranging from the mundane to the very difficult. When I finish my hour with a candidate, I know whether they will be able to do the job at hand. Whether they will fit with the group, or be able to work with the business partners or organize their work effectively, I don’t know. However, I have never said yes about a candidate who couldn’t cut it technically.

    I rarely even look at the resume during the interview because it’s what the candidate wants me to know, not what I want to know. My opinion is, I don’t care what you say you did for someone else, I want to know if you can solve these simulations of what you’re going to face here. I also start with the hardest question to see how they deal with the pressure. You get bonus points if you’re nervous but bully through and write an answer.

    • Michael Westen

      @Jesse Cronce,

      I really hope your code generates billions of dollars in revenue. You are the perfect example of people I wouldn’t want to work with and I think a team who can out number the amount of features you develop singly wouldn’t either. If I was your manager I would consider the amount of contributions made and weight the amount of contributions made with the team cause my friend your are causing your company a diservice using your-opinion-based selection method . A Company rely on teams who succeed as a team and develop velocity over the days based on communication collaboration and team gelling.

      When you hire a plumber to fix your toilette (believe your plumber just want to fix your toilette) do you quiz him on Arquimides thermodynamics principle?

      • Jesse Cronce

        @Michael Westen – Everyone plays a part. Mine is to figure out whether someone can actually do the work. There are several factors leading to the hiring decision, I probe a candidate’s technical abilities as part of a panel of interviewers. I stand by my methods, and I know that weeding out the technically weak brings value to my company. As I do the work every day, I know the skills needed to do the work.

        As for your personal attacks toward me, I get on very well with the team I work with. I try to help whoever needs my help and I view time spent explaining or teaching to have a very high ROI. From engineering to test to manufacturing to field support. I consider “team player” to be part of my personal brand.

        • @ Jesse Cronce,

          You exude overconfidence and the insincerity of the managerial class.

          Saying things like ” I consider “team player” to be part of my personal brand.” is kind of self centered you should know. Just parse the language and look up the meaning of the words to see this is a contradiction at face value. Add to that that you say “I rarely even look at the resume during the interview because it’s what the candidate wants me to know, not what I want to know” and I guess that’s typical of your ideas of teamwork and other peoples motives?

          Also, people who say things like “never” or “always” about their skills are generally not to be trusted as honest. You mention “I have never said yes about a candidate who couldn’t cut it technically” Which makes me suspicious you just don’t admit to your own imperfections or failures. You maybe say things like “giving 120% percent” and claim your good at math too? am I right?

          Or there’s a small chance your actually as talented and insightfull like you seem to be claiming. I don’t know you so it could be possible but you don’t seem to grasp the credibility problem you’re creating for yourself or address it which demonstrates a lack of people skills or ability to understand other peoples perceptions of you as separate from your perception of yourself. Maybe you just slipped in this post? you didn’t say you never wrote anything dishonest or left out things that might detract from your reputation. You seem pretty defensive about being criticized too which is a warning sign in a person testifying to their own self value.

          Well, I don’t really know you so maybe I’m wrong and it’s a snap judgement too so maybe I just got the wrong idea. I just thought you should know your post reminded me more of the pointy haired boss of Dilbert than the wunderkind of tech genius who has social assets too.

  15. I’ve been on a number of interviews of varying kinds over the years. I’ve had my share of “in place string reverses”, “binary searches”, and others. One person asked me to write a specific recursive algorithm and I told them that was not an efficient method of performing the task and that I’d be happy to do so if this was just for a programming test but that in real life it would not be done that way. It turns out they were testing me to see if I’d speak up if I saw waste like that going on (so bear that in mind).

    Another interview and they asked me to prepare (for my 2nd interview) a presentation using power point about a project I had worked on previously – the risks, decisions, etc. I told them that I could only go so far as to not violate any Non Disclosure agreements and they understood. I did a great presentation and, in fact, they said it was probably the best they had seen – I answered all of the questions showing a high level of expertise and knowledge. In the end, after a week, they said they were not going to move ahead with the job and would give no reason – but even then they said that I did very well on the technical interview. I’m still scratching my head on that one.

    One of the ones that I enjoyed the best was from a company that asked me how I would go about designing a system to capture a specific type of vehicle. My response was as follows:
    1) First – I asked them if they had any requirements or limits including but not limited to size/weight/lifting capacity/cost/project length (as in # of months)
    2) Second – they responded that yes, they did have requirements but I would have to ask about specific items I needed to know about, so I asked about each of the individual items above and a few more. At one point they said, Ok, don’t worry about anything else at this point.
    3) I outlined for them a couple of overall architectures that I thought might fit the bill, explained how I would do some industry research to see what is currently available… They stopped me and said, “this has never been done – you’re the first – you need to to this without outside help”.
    4) I then told them that I would have the MEs do some load analysis for the various architectures and I also limited my options to the 3 I liked the best (I had put up about 6 or 7) but that I would keep some documentation on the others in case we started leaning in that direction.
    5) Then I started to get a little bit more detailed on how things would work, what issues I expected to arise and how I would handle them.

    To make a long story short – this was for a SOFTWARE ENGINEERING position – they offered me a job as a Systems Engineer OR a Software Engineer. I told them I wanted to do both and they said they’d see what they could do.

    I accepted and started work – after a few months they ended up renting a new facility about 20 miles farther away from where I lived (I was already near my limit – I had to get on the road at 5 am so it would only take 45 min to get there – much later and it would be 1 hr – 1.5 hrs) and I just wasn’t willing to drive that far/long. We parted on good terms though and I had another job 3 days later.

  16. There is a serious problem with interview procedures.
    I have seen most of the companies repeat a lot of question (with some modifications) .
    This has always forced me to step aside from my work. And prepare stack and queue questions.
    And after a couple of interviews you can easily disguise the interviewer and answer most of the questions from your memory without using your commonsense.

    Time invested in preparing for interviews is just wasted 🙁 . Do they ever give importance to how you put into team efforts? How can you collaborate with your colleagues ? How much clean code you can write ? How good are you in debugging and exploiting your tools and IDE?

    I wished they would have given 2-3 hours and ask candidate to write complete end to end program in the best effective way. rather then asking 100’s of DS and algos questions.

  17. Joseph

    This whole business is ridiculous. First we build our UI in curses, then in Motif, then in Windows, then in C#, then in J#, then in WPF, then inTCL, then in QT. What the hell, this is relentless repetition.

  18. Rinat Galyautdinov

    I think that asking a software developer to write some code within 30-40mins does not make any sense. What can be done within this time? Only some simple and useless functionality, most probably related to array manipulation, etc but is this gonna be a main stream in this job?
    Surely not. The tech interview should include the bunch of the topics which are gonna be required during a real job and if you do want to ask a candidate to write some functionality then let him to do in in his spare time, within several days by implementing some test project of a reasonable size which consumes the technologies you are gonna use in this job

    • The code will likely be relatively short (not necessarily trivial, but certainly short). However, many developers still can’t do that or can’t do it well. It’s a sign of a serious issue. You can learn about someone’s coding skills from that.

      Code doesn’t need to be useful to be a good test of someone’s skills. A good developer should be able to write a function to, say, search for a smaller string within a bigger string. The fact that it’s not useful in the real world (since you’d likely have a library to do this) doesn’t make it a useless test.

      Doing it at home seems like a good option, but the problem is that you don’t know that it’s truly the candidate’s work. Most people probably would get help from their friends.

      It’s also not really fair to give a a several day long assignment. Candidates have other things to do with their time.

      Essentially it comes down to this: test coding in the interview or not at all.

  19. I am a candidate in the arena of ‘phone hiring’ where people call and ask me about my cookie cutter skills related to SAP BW. I mostly get interviewed by Indians who I cannot understand. I get asked the questions that can be found with a little google-juice such as ‘Technical interview questions for SAP BW interview’.

    And that is how the interviews go… out of context questions that have a short answer and a long one, with the short one being inconclusive and demonstrative of absolutely nothing and…. they want the short one so, I memorized all those.

    Why? Because slowly but surely it is dawning on me that the people asking me these questions want only textbook answers. Stupidly on my part, for many interviews, I did not realize they are trying to filter for liars more than they are probing to learn of my wonderful createive and great technical skills.

    I find that most interviewers are not HR people. Thus, it seems like a real dog and pony show where the interviewee needs to get a feel for the audience. Typical scene for me is this: Recruiter calls an I convince him of the truth which is that I am wonderful. Recruiter gives my resume to company. I get a conference call with 2-5 people on the line who introduce themselves as Fre*KNJS and Bill and treyghsgs and Herman, who says he is mostly going to simply listen in. Seldom to I interview with the same set of people the recruiter says I will so my research on linked-in is wasted as are the names on 3×5 cards I have on my keyboard. One is HR, another is mgr, another my supervisor, and a peer thrown in for good measure – almost ALWAYS at least one or two Indians who I cannot decode.

    Then someone asks me to tell them about myself before they tell me what they are looking for. OK, well, telling them I wrote my first computer program for money about oh 5 years before they were born seldom wins any points. Nor does asserting that I have been doing this particular SAP skillset 4 times longer than them so I should ask you questions to see how much YOU know. So, I try to address the Job description and 2nd guess what is most important to them (which they do not have the courtesy to simply state). I have pretty wide and deep experience so, I can drone on. Point of this paragraph for any interviewers reading this: In this scenario, you have refused to be clear what your name is then you ask me to tell you about random experience. My intro is right there as the first paragraph of my resume, so, if you are looking for some specific thing then just say so… I am on the phone with 4 effin people and I am not even sure who is talking. When you talk, repeat your name and title and state the context of your question. Else I answer technically to the HR, HR’ly to the techie, and have no clue with the tweeners how to connect. What am I, a radio show host with 4 call in guests who I never met asking me where was I 4 weeks ago at 7:00PM – and, how did I meet that challenge? Sheesh.

    Here is a ligitimate question framework, imho:
    Hi – this is Gre*KNJS again, the tech lead for the project. I will be needing to get some information out of the system using open hub and hoping you will be able to do that. Can you discuss open hub a little to give me an idea, just a couple minutes and hit the high points convince me you have used it before and understand it?.

    If your are the peer and you want the short answer:
    “Hi, this is areebajashivan, your potential team mate: What is DSO – give to me the answer of textbook learning is ok”.

    Either case above, I can probably satisfy the interrogators, er, interviewers.

    Among the reasons I feel I do not get as many offers as some is that of course one, SAP is being taken over by Indians and they prefer to hire H1B’s more than citizens if possible. Two, I am old and there is this absurd perception that old techies are unmanageable passive-aggressive sickly burned out relics who cannot seem to run with the pack anymore plus the sometimes forget words and occasionally fart. Also because they stayed on developer track instead of ‘blooming’ into managers, they must be losers. Three, I am seldom local. There is truly a lot of local talent and if I was the interviewer I would choose local before bringing in an out of towner.

    Any interviewers out there: Puleese tell me, in this anonymous forum, why old people like me, programming since 1979, with more than 1/2 dozen languages and several iterations of machinery, are forced to disguise our age, our experience and our past? What is the problem with someone who has chosen to be a developer rather than a manager? A resume says ‘great work’, it is accurate. Interview goes well with glowing 1st impression reports back to recruiter then…. all goes dark. No response from recruiter. No response from company. The ‘no feedback’ after a couple weeks thing tells me that there is a litigation issue that they are avoiding. (note that most of the fair hiring practice statements at company web-sites do not mention age as part of the “without regard to’ phrase!)

    25 words or so: Phone interviewers please identify yourself when more than 1 of you on line. State context and purpose of question along with desired answer length.

  20. Marie Murakami

    Whiteboard testing can be rather efficient if done right, but most of the time it isn’t…
    The fault for this lies in the interviewer, it’s not just about giving too much credit for the candidate’s performances on this test, it’s about presenting and conducting the test itself in a wrong manner.

    First, after providing the candidate with the required problem you want to ask him to make a draft (an example, small diagram, or whatever) of the problem. You want to make sure the candidate understands what is asked from him, that there are no ambiguities or false assumptions.

    Second, you start of the conversation, this is crucial because a lot of candidates will freeze due to their nerves so you want to open the communication into a right direction. After the candidate starts tackling the problem it’s very likely he’ll forget about his nervousness.

    Third, ideally the candidate should be the one making the communication flowing, but if he’s not then you should. I’m also pro for giving the candidates both correct and incorrect hints in a form of an opinion question.

    Last (and actually the most common mistake), do not demand any specific programming language even though the position itself requires one. This is not why the whiteboard test is used for, any language including the pseudo code should suffice. If you want to test out the candidate’s knowledge of a specific language then you should do it in some other way. Also testing out the syntax itself is just pointless, what you should observe is how well he preforms in the environment in which he will be expected to work in. But what bugs me the most is that if you need to test out his knowledge of a specific language in a whiteboard phase then you’re doing things wrong… You should have filtered out these candidates at the beginning.