34 ms·

How to Interview Engineers

• ammon 9y ago
  An interesting point my co-worker made is that, almost by definition, if an interviewee does not know how to answer a question, they don't know why that question is important or where that type of problem is applied. So from the point of view of an interviewee who's can't do well on all the questions (that's most of us in most interviews) some of the question will always seem like minutiae / lacking application. (Of course, there's also plenty of just bad interview questions)
  • sidlls 9y ago
    It's entirely possible to not be able to answer a question because the question is objectively not meaningful, and therefore the candidate has correctly never considered it important enough to learn about.
    • ammon 9y ago
      Totally. Both things happen.
      • filipecalasans 9y ago
        Sometimes questions are useful only if you are in the context of the specified problem. I mean, if you are not struggling or have never struggled in the problem, you will probably not know the specificities of it. This is specially true for unexperienced engineers or those who are working on a different field
  • kafkaesq 9y ago
    (Of course, there's also plenty of just bad interview questions) Well yeah, there's that unfortunate fact. The problem is, a lot of interviewers can't tell the good from the bad -- and it can only take one bad question to effectively sink the interview.
    • logfromblammo 9y ago
      Where do you see yourself in 5 years? Every time I hear that question, I die a little inside. I'm not sure it's possible to answer it honestly without taking yourself out of contention.
      • scottLobster 9y ago
        I suppose it depends on your 5-year goals and the position, but as an entry-level developer my first thought would be: "Well as I'm interviewing here I would obviously see taking this position as a step foreword for all the reasons we've discussed. Naturally I don't see this position as the job I'll work until I retire, and obviously I'll be looking for at least some mild expansion of responsibilities in the future. Whether that happens here or somewhere else in 5 years remains to be seen, but staying here is certainly an option depending on how things are going after 2-3 years. On that note, exactly how are company name's technical and managerial tracks structured..." In that paragraph I've been honest, I've let them know that I don't intend to do menial labor forever and have aspirations, the minimum amount of time-loyalty they can expect from me, an assurance that I won't job-hop, and I've shown further interest in their company as well as the initiative to ask questions of my own if I haven't done so earlier. Edit: Reading it here may sound like I want to be a manager in 3 years (which is crazy for a junior dev), but that's where manner and vocal tone come in.
        • fwefwwfe 9y ago
          Ok, now do it for someone with 5 and 10 years of experience.
          • watwut 9y ago
            That question is easier with experience, because you know more about how positions look like in practice and what you disliked in the past.
            • logfromblammo 9y ago
  • sbov 9y ago
    Almost by definition, if you think being able to answer a question is important, and you only hire people who know how to answer that question, you will always think it's important.
  • vaishaksuresh 9y ago
    >if an interviewee does not know how to answer a question, they don't know why that question is important or where that type of problem is applied I would argue that not knowing answer and not knowing question are two different things. I may not know answer to a questions, but know that the question exists. I personally am comfortable not remembering things that I can easily look up.
    • collyw 9y ago
      I don't know the answer but I know how to get it.
  • base698 9y ago
    I've thought of interviewing as finding the intersection of something to have a discussion about. Tech is so broad and deep it's possible that two people will have minimal overlap. It's nice to find some common ground you can discuss in depth. If both the interviewer and interviewee have overlap they can discuss then the interview is most productive.
• jobu 9y ago
  "15% dislike academic CS (and think that talking about CS is a sign that a candidate will not be productive)" That seems really weird. Academic CS isn't really necessary for most programming jobs, but I can't see how it would ever be a detriment.
  • rsyring 9y ago
    I had a guy work for me that was very academic minded regarding programming. He had a hard time letting go of the "pure" way of doing things and taking a good/practical approach to just getting stuff done. It can definitely be, but won't always be, a detriment in my experience.
    • pmiller2 9y ago
      That's a mindset flaw, not one that can be attributed to having CS knowledge, or enjoying talking about academic CS.
      • pm90 9y ago
        This is exactly true. There are certain things about which you absolutely need to be anal about being pure, such as scientific experiments and theoretical deductions/proofs. And there are others where you need to be more practical. This one person seems to have been applying the same mentality to both, which is a personal flaw, not solely a result of having more academic credentials/experience.
    • fwefwwfe 9y ago
      I like how you discriminate against CS knowledge in general because a single person couldn't get stuff done.
    • dvnguyen 9y ago
      What you've described is someone who follow some practices religiously. I don't see any correlation between people like that and ones with academic background.
• padobson 9y ago
  Spending a week working beside an engineer (or seeing how they complete a substantial project) almost certainly provides a better measure of their abilities than watching them solve interview problems for 1 hour Trial employment is expensive for the company. [...] Trial employment (and large take-home projects) are expensive for the candidate. I can't help but think there's way to mitigate that expense among several (dozen) companies. Triplebyte is already interviewing for other companies, why not set a low bar and hire everyone who passes it for a week? Charge your clients accordingly. If you have 25 clients hiring for overlapping skills, have them all pay to hire a person for a week. 40 hours of of labor / 25 clients = 1.6 hrs of labor per client, or about what it costs to do a single technical interview. Meanwhile, the interviewee gets to do a single, focused project for a week, but effectively interviews with 25 companies! I can get on Dice right now and find over 100 openings for python/java/golang/javascript/c++ engineers, certainly all of those companies would benefit from something like this. More power to Triplebyte if they can figure out how to take those projects and turn it into a client deliverable on top of defraying interview costs.
  • Kpourdeilami 9y ago
    IMO, trial employment works because interviewer gets to spend a week with the candidate personally to get a feeling of how they approach and solve problems. Having Triplebyte do that without the interviewer being there to work with the interviewee on something, then it wouldn't be any different from an hour long interview
  • ammon 9y ago
    That's an interesting idea! The hard part would be convincing companies to trust an external trial week fully (part of what's great about a trial week is the chance to actually see how an engineer will interact with your team / your problems). But I like the idea!
    • padobson 9y ago
      It's true that a company would not be able to gain a "feel" for working with a candidate, but those feelings probably help contribute to noise as much allowing interviewers to ask their pet questions. Surely a company could objectively learn a great deal about a candidate by looking at a week's worth of git commits and evaluating the final product for correctness/maintainability/optimization. But still, taking TOO much of the humanity out of hiring ignores the fact that ultimately, a person has to work with other people, so you're right that it's not perfect.
• jdp23 9y ago
  Looking at Triplebyte's "about us" page, it appears that their engineering team is 100% male. This should be a big red flag for any company trying to get diverse engineering team - why work with a company that doesn't hire women engineers?
  • wootness 9y ago
    What a simple comment. You have no idea why that is the case - stop presuming.
  • Kpourdeilami 9y ago
    Small startups often don't have access to a diverse talent pool to hire from since it is hard to convince anyone other than people you already to join the company. I don't think they deliberately refuse to hire women engineers judging by the diversity page[0] on their website 0: https://triplebyte.com/diversity https://triplebyte.com/diversity
    • daveguy 9y ago
      And they have several female employees with CS and engineering backgrounds: https://triplebyte.com/about https://triplebyte.com/about
    • ubernostrum 9y ago
      Until one person left recently (nothing acrimonious), the engineering team I'm on was 9 men, 8 women. At a startup. The "pipeline problem" doesn't exist. The "we're too small to do that" problem doesn't exist. You know what does help? Recruiting at places other than the Stanford CS job fair. Partnering with mentorship organizations. Sponsoring or hosting events that show off your company to people who aren't Stanford CS students. I could go on and on.
  • deleted 9y ago
    [deleted]
  • fwefwwfe 9y ago
    Clearly they must be racist, too.
• altharaz 9y ago
  At my company our engineers defined the following process. First, we defined the skills we're looking for i.e. Programming / SysAdmin / Cybersecurity. Our process goes as follows: 1. We ask candidates to answer a quizz by phone, with questions in the 3 chosen fields. Duration = 1h. 2. We ask candidates to solve remotely with Google Docs 5 real-world problems asking for skills in Algorithmics, Data Modeling, Object-Oriented Programming, Software Design, and Parsing. We also add a bonus question like "how many people can get into a train". Duration = 1h. 3. We have a HR meeting at our office with a non-technical member of the team. Duration = 1h. The quizz helps us to remove of our list the candidates that do not have the technical culture we're looking for, and to see what they already have worked on. The 5 problems helps us to see how the candidates can code, the bonus question helps us to see how they approach new issues and manage their stress. The final HR meeting is very typical: we try to see if we would be happy to take a 6 hours long flight with the candidate. Most candidates do not go through first step, and roughly half on them do not go through second step. This simple process definitely helped us to reduce the time spent on hiring and to make the really good candidates shine.
  • Dzugaru 9y ago
    > how many people can get into a train Can't speak for everyone, but I'd turn away and walked out the instant I hear this or similar BS (which is totally unrelated to "approaching new problems" or "stress management" in programming at least)
    • deleted 9y ago
      [deleted]
    • supran 9y ago
      You're too forgiving. I turn down interviews when they list "linked lists, hashing, breadth/depth first search" on their study guide. I've never had to write a linked list EVER in my career, don't fucking bother me with that shit. Also, if the position is in a language where linked lists would be stupid (i.e. python), then I definitely reject that company. I can explain what everyone of them is, and why you'd want to use them. But I've never written any one of them and I'm not going to spend the time to memorize something I can look up in my CLR book or stackoverflow. It's embarrassing that tech interviewing is still stuck in a 1990s mindset.
• timebomb 9y ago
  Where I work, we'd be totally happy to ask interviewees how to reverse a binary search tree. As soon as an actual developer creates a pull request that does as such. Which hasn't happened yet. So we don't ask about things like that. And everyone seems happier.
  • jkaptur 9y ago
    I don't get it. Programmers are surrounded by trees. The filesystem, your code's AST, dependency trees, the HTML DOM, any JSON ... why do people consider it so unreasonable to ask a question about simple manipulation of a well-understood tree data structure?
    • bookmarkacc 9y ago
      It would be reasonable to ask tree related questions. If the questions falls within a normal use case. Traversing a filesystem is something you should be familiar with. Reversing a binary tree. No
    • walrus1066 9y ago
      Unless you're writing a database or browser engine, you will never have to implement a binary tree. So it is effectively trivia knowledge. It's like asking how the x86 CPU architecture works, because it's the platform on which most code runs.
    • ubernostrum 9y ago
      Because it implicitly selects for inexperienced/mediocre candidates over experienced ones. Even among people who did a degree that involved implementing these algorithms, 99% or more will never do it again once they set foot off their campus, because they'll just use a library that already has it implemented. Then they'll free up room in their brain's working set for the stuff they actually do have to implement. And the longer they go like that, the longer it'll take and the more difficult it'll be to find where all those tree algorithms got paged out to in their brain, and the worse they'll look on an interview which consists solely of asking for that stuff. Meanwhile, the inexperienced and likely unqualified (given what people claim about the average CS graduate) person who just walked out of their college graduation still has it fresh and ready to regurgitate onto your whiteboard, and passes with flying colors: great technical skills, great "fundamentals", A+++++ hire ASAP! The solution to this is to stop using proxies for the thing you want to know, and start actually testing for the thing you want to know.
• LordHumungous 9y ago
  >I'm arguing for asking easy questions, but then judging fairly harshly. I agree with this. Better yet ask a multi-part question that has an easy first part and a harder follow on.
• pklausler 9y ago
  The sad reality of programming interviews is that it's absolutely necessary to ask several near-trivial questions in order to flush out the candidates with awesome resumes and impressive degrees who simply have no idea how to analyze a simple problem and solve it using a computer. Lately, I've been asking "given the starting and ending times of two calendar appointments, determine whether or not they conflict." No loops, no fancy algorithms, no tricks... and asking it has not been a waste of time. I get people writing doubly-nested loops over all of the seconds in the two intervals, comparing for equality; I get multi-line predicates full of redundancy that still yield false positives and negatives; it's depressing as hell.
  • ionwake 9y ago
    The funny part is I reckon you would struggle to answer the question yourself when put on the spot, if you had no prior experience of it. Just my opinion of course and I am speculating.
    • kornish 9y ago
      What's your basis for that speculation? The solution is a simple predicate. Assuming both events are internally consistent (i.e. end time after beginning time) they won't overlap so long as the beginning of the first comes after the end of the second OR the beginning of the second comes after the end of the first. Seems like a good weed-out problem. Disclaimer: no prior experience with the problem.
  • ben_jones 9y ago
    I think many companies hire with the number one goal of reducing false positives. By definition this approach is going to unfairly reject a number of candidates. I would argue that it also dehumanizes a number of candidates, forcing them in aggregate to play a numbers game until they are in the top 20%-40% of the pool (if they ever get there) where companies then begin vying for them. It is as you put: depressing as hell. And this is among white collared, educated, demographics. Imagine how it must feel to be an uneducated demographic in most other parts of the world...
• danthemanvsqz 9y ago
  Interesting read from the POV of the staffing agency and hiring company. But why should I jump through those hoops when I don't even know if I'm interested in the job? I really think the hiring companies need to sell me on them before they ask me to spend an hour of my time.
  • Jemaclus 9y ago
    I agree. I had an interview yesterday where they passed, and the reasoning was "You didn't seem interested in the job." And I sort of think that's hilarious, because nobody tried to sell me on the job. Nobody told me exactly what the job would entail. I never met the hiring manager, even though I was on-site for 5 hours. And clearly they weren't interested in me... It just seems weird that I have to be jizzing my pants to work for them, but they don't even have to try to sell me on the role. And this goes doubly true for any company that reaches out to me first. Like, if I apply to your company, then yeah, you have an expectation of me being interested in the company. But if you reach out to me, then maybe you're the one who needs to sell yourself to me. I don't really get that attitude by employers. Whenever I'm interviewing candidates, I really try to sell them on the role. I try to tell them what's awesome about it, why they should want to work here over literally anywhere else in the world, and why you WANT to sit next to us for the next six months and work with me and my team on projects. Part of my job as an interviewer is to not only gauge your ability and interest, but to convince you that we're the best place for you to be. Or... do interviewers really think I selected their company is the only company I even considered talking to? We're engineers. We have options. You (the company) have to meet me at least halfway. Incidentally, I've often wanted to ask my interviewers to solve a tech challenge. I don't want to join a company where the team is incompetent and I'm constantly cleaning up after them. Oddly, that's never a consideration that companies allow candidates... ;)
• gaylemcd 9y ago
  I agree with much of this. Some additional comments: > Ask questions as close as possible to real work: This is achieved by making interview question as similar as possible to the job you want the candidate to do (or to the skill you're trying to measure). This "or" thing in parentheses is really important. Interviews should not be "as similar as possible to the job." They should be all about the skill you want to measure. And there's quite a difference between these. People can be trained, assuming you have time and resources. The point of standard algorithm interviews is to measure a particular skill: intelligence. The belief behind this is smart people will tend to solve problems well in the real world. It's okay if they don't know all the skills they need; they can learn them. (And if there's a particularly challenging skill, then maybe you need to add that into the process.) > Avoid hard questions: If a candidate solves a really hard question well, that tells you a lot about their skill. However, because the question is hard, most candidates will fail to solve it well. The expected amount of information gained from a question, then, is heavily impacted by the difficulty of the question. We find that the optimal difficulty level is significantly easier than most interviewers guess. This effect is amplified by the fact that there are two sources of signal when interviewing a candidate: whether they give the “correct” answer to a question, and their process / how easily they arrive at that answer. You don't give examples of what qualifies as hard vs. easy, so it's a little difficult to judge this. But generally, I'd advocate for people asking harder questions. When a question is easy, a little thing -- small point of confusion, etc -- can make a big difference in whether the candidate seems to have gotten to that answer well or not. When a question is hard, this is when you can actually see a great differential between great vs. good vs. okay. You can offer help and see how effectively they pick up on that advice. If your interviewers are just throwing out a question and then sitting back and seeing what happens, then yeah, candidates won't be able to tackle a hard question. But that's not what they should be doing. To be clear here: hard does not mean "ask about some obscure data structure [skip lists, etc]." It means a challenging question involving common knowledge (hash tables, strings, arrays, maybe binary search trees). > 5. Ask every candidate the same questions: [...] there is no justification for asking different questions to different candidates. If you evaluate different candidates for the same job in different ways, you are introducing noise. I think this is overplayed a little. If you're doing algorithm-style interviews, any question should be basically evaluating the same skill (problem solving skills). If I ask my favorite question and you ask your favorite question, but they're evaluating the same skill, then it doesn't really matter. There's nothing to make one question better than another. Why not let each interviewer ask the question that they like? Now, if every interviewer asks a different question, you won't be able to give a well-defined metric on what good performance looks like for that problem. But that's okay. You can't really do that anyway. When companies give well-defined metrics, they get too rigid. The candidate takes slightly longer to complete the code because the candidate thought things through more thoroughly, and now they're pushed into a lower performing bucket. And that's wrong. These standardized metrics sound good in theory, but they don't work well in reality (for algorithm interviews, anyway).
• rezashirazian 9y ago
  I wouldn't use TripleByte to hire or get hired, but that was a well written article.
• bogomipz 9y ago
  >"After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe)." Can anyone from any of these companies confirm this? This strikes me as really odd. So only one employee from FB, Apple, Dropbox, and Stripe needs to interview a candidate that Tripplebyte say is a "Go"? I'm having a hard time believing that.
  • zippergz 9y ago
    I don't think "the final interview" means a single person. I took it to mean the onsite round, with however many people that entails, skipping the recruiter screen, phone screen, etc.
    • Zephyr314 9y ago
      This interpretation is correct; they skip to onsite, but get a full onsite. (Source: we interview triplebyte candidates regularly)
      • theflork 9y ago
        how is the quality of the candidates coming thru the triplebyte pipeline compared to recruiters, or direct site applications? I'm considering using triplebyte, but also want to control where my applications are sent to.
        • Zephyr314 9y ago
          They are of similar quality to candidates that get through our normal screening process (direct applications). It is best to be very specific about what types of candidates you are looking for so they can match as well as possible. We're happy with them in general.
    • bogomipz 9y ago
      So why does it matter whether the first round of interviews is done by this company or the actual company doing the hiring? I would argue that as a candidate I would rather interview with as many of my potential coworkers as possible. Interviewing is a two way street. The more exposure to the actual people I would be working with allows me to make a better-informed decision. How is reducing my exposure better for me the candidate? It seems its really better for Tripplebyte though and maybe the company looking to hire if they are short-staffed but not the candidate.
• 0xffff2 9y ago
  As someone with an actual accredited engineering degree, I find it bizarre that Silicon Valley has decided that the term "engineer" doesn't even need to be qualified anymore. Even without getting into the flame war over whether "software engineers" are real engineers or not, there's a very large pool of engineers to which this post doesn't apply at all. I can't be the only one in the latter pool that reads HN, can I?
  • null0pointer 9y ago
    I used to be reluctant to call myself an engineer. I don't actually get to do too much engineering in my work. But I've seen too many less qualified people calling themselves engineers so I might as well... Besides, my degree is from the Engineering faculty at my university rather than Science where the CS/SE degrees are. At least that's how I justify it to myself.
  • skyshaker124 9y ago
    You're not the only one. I have a Master's and it was hard. I went for my engineering degrees after more than a decade as a technician and programmer in telecom. It's a world of difference. A cert from Microsoft or Cisco or whomever doesn't compare. We earn the title, they enjoy it.
• mpetrovich 9y ago
  We've had success with take-home coding challenges. After 1-2 technical phone screens, we send applicants a coding challenge for which they have 48 hours to complete. The coding challenge is representative of some of the work we do (e.g. Given our API, create a D3 visualization of X) and should take applicants several hours to complete. In submissions we look at everything from overall program structure and approach to applicants' attention to detail and usage of good industry practices. This coding challenge quickly weeds out applicants that interview well but code poorly and is an efficient way for us to see the quality of work we can expect from them (and conversely, the type of work they can expect to do with us). After a successful challenge, we bring applicants in to meet the team. At this point, it's largely just about culture fit.
  • aldarn 9y ago
    Do you specifically hire D3 developers? This sounds like a pretty difficult "coding challenge" for a non-D3 guy, let alone someone who may not even primarily use javascript. Having used D3 sparingly before i've found it something that requires a fair amount of upfront domain knowledge to get much done beyond something extremely simple (unless of course you copy an existing example, which is what I always did). This seems unreasonably difficult for someone with no prior knowledge to accomplish in a 48 hour window whilst working etc -- you may find you are inadvertently optimizing your interview process for the unemployed with this kind of time limit / coding investment.
    • mpetrovich 9y ago
      No, we're not specifically looking for experienced D3 devs. That particular challenge can be completed with the simplest D3 viz if desired (of which there are hundreds of examples online) and doesn't even require prior D3 experience (I didn't have any when I applied). We do look for a solid working knowledge of JS, however, and an ability to learn new tools quickly. The 48 hour time limit is a relatively arbitrary timebox and isn't a hard limit; we value quality over speed.
• DenisM 9y ago
  Sometimes I ask candidates to come up with a question for the interview, something that would allow them to put their best foot forward. Any thoughts on that?
  • DoofusOfDeath 9y ago
    I've never seen it done, but it sounds like there's potential. How has it played out when you've done that?
    • DenisM 9y ago
      Not well. Candidates get disoriented and can't come up with anything relevant. It's a very small dataset though.
  • tcarn 9y ago
    Never heard of it but what a great idea!
  • roguecoder 9y ago
    The question is really under-constrained and it's not clear what you are trying to figure out. I ask things like, "what's the most interesting bug you've encountered?" or "what have you been excited about learning recently?" to try to find a topic we can have a conversation about in a domain they are familiar with and interested in.
    • DenisM 9y ago
      Oh, I forgot to add - I actually ask for a coding task they think will put them in the best light. Like, "hey, I can balance a binary tree, let me show you". In my mind if someone learned something like this very well they show their learning potential, and complexity of the task will tell me their self-assessed level of development.
• partycoder 9y ago
  You can ask someone to solve a rubik cube in under a minute. Or you can ask someone to beat a Go bot that is ranked over 5 kyu. Or you can ask someone to find adjacent zeroes in a matrix of numbers in under 15 minutes. All those exercises, however tricky, do not correlate much with how smart you are or what your programming abilities are.
• notadoc 9y ago
  My own 2 cents for interviewing, for engineers and most other vaguely technical positions but perhaps broadly applicable: - Don't ask them to whiteboard, especially don't ask them to whiteboard some absurdity - Don't put a panel of 5-10 people against a single candidate, but if you must absolutely (why?) do not do it on the first interview - Don't ask time-wasting stupid questions about manhole covers, boiling bagels on mars, overlapping clock hands, or how many eggs fit into a phone booth - Don't put someone into a socially awkward situation - If you ask a knowledge question and the response is something like "I don't know, but I would google it" that should be acceptable if they are demonstrably capable of using what they find - Do ask them to walk through their own projects, their code, their past work/contributions, etc - Do try to effectively convey the corporate culture so the candidate can know if they are a good fit or not ahead of time - Do try to accurately convey what their actual job duties and day-to-day work will be
  • cyrux004 9y ago
    Can you expand on the boiling bagels on mars question ? Havent heard of that before
    • deleted 9y ago
      [deleted]
    • taneq 9y ago
      In context it sounds like a flippant reference to the 'creative thinking' type questions that were all the rage a few years ago. Ask someone an oddball question with the aim of having them talk through their process of solving a question they've never heard before because you just made it up. As long as you make it clear that the actual number they come up with is irrelevant and you just want to see how they think (and you're also open to pragmatic answers like "why the hell would I be trying to calculate the weight of an Airbus A380 when I could just look it up on wikipedia?") I don't see why it's that bad a question.
    • notadoc 9y ago
      It's just a variation on the typical logic/creative thinking questions that a lot of people and companies obsess over. "Well they're a great candidate otherwise but they totally failed the boiling water on alternate planet question, so let's keep searching" - believe it or not, that's a real mentality out there. I don't get it and never have.
• known 9y ago
  quiz != interview
• Jemaclus 9y ago
  IMO, hiring is like a funnel. At the top of the funnel is the entire universe of people. At the bottom of the funnel is your hire. The goal is to filter out as many people as possible as quickly as possible. One key point is whether or not they can write code. Keep in mind writing code is the BARE MINIMUM required for a job. If they can't do that, they shouldn't be on-site in the first place. If you have your candidate taking a day off work and taking a day worth of engineering talent off engineering-related tasks, and you're spending that time asking them to write code, you've failed to apply the filter higher up in the funnel. Ideally, you verify their coding ability BEFORE you bring them into the office, whether via a tech phone call, live-coding session, or take-home assignment. Before the haters start saying "but they can fake it!", hold your horses. Once you've established that the candidate can code, when you bring them on-site, you quickly VERIFY your previous conclusions. You quickly VERIFY that the coding assignment you gave them was completed by them. This should take no more than 15-20 minutes. Maybe you just have them walk through a chunk of code. Maybe you ask them to recreate their answer. Something. Anything. But if you send in three different engineers, and they all spend the entire hour asking the candidate to solve programming tasks, you're literally evaluating the BARE MINIMUM of the hiring requirements. And there's so, so, so much more to being a good engineer than writing code. Outside of a QUICK verification, your on-site questions, imo, should NOT be writing code (or even pseudo-code). They should be about previous projects, architecture, personality, professionalism, punctuality, communication, teamwork, autonomy, and collaboration skills -- all the non-tangibles that answer the basic question of "Do I want to sit next to this person for the next 6-12 months?" If your idea of a good interview is to ask someone to generate a calendar between two dates or sort a list or find the minimum integer in a list, you're completely, totally missing the point. You're evaluating the bare minimum to get them in the door -- and if you're doing that in-person, you're wasting your time. You should have filtered that out before they walked in the door. Remember, these candidates are often lying to their bosses and calling in sick or using up valuable PTO to take an entire day off work to come sit in your office. Don't waste their time with redundant tests and things that you could have figured out before they walked in the door. (And dear god, some of the questions in these comments are... awful... at evaluating anything except, I dunno, getting the right answer. Yikes.)
• paulie_a 9y ago
  Honestly drop the question/answer aspect for technical checkouts. Offer a problem then work with them to solve it. The most important aspects are two fold, What questions do they ask, and now that you are being cooperative and a team mate, how do they interact with you. EDIT: But during the entire process keep in mind they are hopefully interviewing your company. Far too many companies forget this aspect and the entire process has become lopsided in favor of companies making candidates jump through hoops.
• Steeeve 9y ago
  I find it odd that so many comments here highlight the fact that people are giving interview questions that have little to nothing to do with day-to-day employment tasks. It seems to me like an enormous amount of time wasted for both interviewers and interviewees. When considering someone for a development/engineering role there are a few basic questions to figure out: 1. Does this person have competence within our technology stack? 2. Can this person communicate clearly? 3. Is this person productive/can this person be productive in our environment? 4. Does this person have characteristics that will allow them to succeed in our environment? Making people jump through hoops like some sort of dancing monkey while they are on a job hunt is needlessly cruel and is a waste of everybody's time. If you regularly see people who can't succeed with what you consider basic engineering questions, you either have a recruiting problem or you yourself have a communication problem. If you expect an interview candidate to expend 8 hours or more working on interview tasks, you should be presenting a unique enough opportunity to justify it. If you expect an interview candidate to whiteboard a solution to a coding problem that they received in the room, that should be part of your everyday work experience and you should go through the process yourself in front of them so that they have an understanding of what your expectations are. If you want to review their code and talk with them about it to determine competency, provide an example of your own code and a set of questions and answers that would be successful. Don't put engineers through a gauntlet of challenges that you would have trouble successfully navigating under the pressure of feeding your own family. They have more than one company they are interviewing with and each company has their own focus. Put them in a position to succeed and give them the chance to do so. That's what you want out of your own people - the ability to succeed given a reasonable amount of guidance and clear parameters for success. If you can't provide the guidance or the parameters for success for an interview, how can anyone expect to succeed in your actual working environment?
  • danielbarla 9y ago
    The question of relevance reminds me of an anecdote. (Before that though; I tend to agree with your points.) A distant acquaintance interviewed for a secretary position. It didn't go well, because she was asked a general knowledge question (something along the lines of: "name some of the planets in the solar system"). She was furious with how irrelevant and unfair this was. It makes me wonder though, would I have hired her? I probably wouldn't have asked that question, but still. When someone is missing some really basic knowledge - even if it's irrelevant - it's not a good sign, per se.
• expertentipp 9y ago
  Looking for a job has become a full time job. In depth technical discussions about the technicalities, then about technical quirks, onsite visits and time spend on researching what on earth the company is doing and what their project is about, then the curse of the industry - take home assignments. Once I signed my last employment contract I said to myself "I'm exhausted, there is no way I'll move a finger during the first months of employment in this company". Also I learned to be more picky. "Want to see my code and apps? Show me your code, show me how you work!" Eclipse required? Bad workflows with weird limitations? "This is how we do it here, it works for us" attitude? High discipline environment with daily standups? Cheapskate workplace/outsourcing center? Sorry, I'm passing.
• pavlakoos 9y ago
  Some engineers I interviewed got "offended" by ElonMusk-like questions and refused to answer :)
  • jk563 9y ago
    What type of questions do you mean?
    • pavlakoos 9y ago
      Imagine a cottage with all 4 walls facing south. And there is a bear visiting it. What is the color of bear's fur?
      • csmattryder 9y ago
        The second you uttered that, I'd thank you for your time and walk out. What on earth does that have to do with building (actually, in most cases, maintaining) a CRUD web app? What does that have to do with n-tier web application architecture?
      • coldcode 9y ago
        Is that a real question? I too would refuse that in a programmer interview, unless it was joke. Of course the answer is white - polar bear and you are at the north pole. Even as a puzzle question it's pretty lame. Still puzzling over the boiling bagels on Mars one...
  • andrewstuart 9y ago
    If you really ask questions like that then you shouldn't be allowed to be involved in recruiting.
    • pavlakoos 9y ago
      Why?
• mychael 9y ago
  > background-blind interviews, looking at coding skills, not credentials or resumes. Subtext: "Did you create a famous open source tool, write a book, have patents in your name or architect some amazing system at a big company? Doesn't matter! Our hiring process prefers code monkeys who can solve our puzzles instead of system thinkers." > An interview can result in a bad engineer being hired and later fired (a false positive). Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out."
  • yosefk 9y ago
    It's hard to know if a patent holder or system architect actually did the work or just took credit for it. It's easy to check if someone can print out a binary tree. Certainly a "system thinker" who can't write the simplest code and assumes it's for "monkeys" to do it is worthless both as a programmer and in any higher-level capacity, whereas someone who can program might be able to do meaningful higher-level work.
  • fnord123 9y ago
    >Subtext: "A hire can either be good or bad. It's never management's fault if it doesn't work out." I agree that the article gets this wrong. It reminds me of Diego Forlan's time at Manchester United. Diego Forlan is/was an Uruguayan striker at Independiente (Arg) where he scored 36 goals in 77 games (a very good rate). He then moved to Manchester United (Eng) in January of 2002 and was anticipated to take off. He made 18 appearances in the 2001-2002 season but failed to score. It took him until October to net his first Premier League goal. He was loved by the fans as he has/had a great attitude and had some delightful near misses. He also famously scored twice against Liverpool[1]. But he continued to struggle at United, scoring only 17 goals in 63 appearances until he was sold to Villareal (Esp) in August of 2004. In his first season at Villareal he won the Pichichi Trophy (golden boot for La Liga) and the European Golden Boot. What a turnaround! Forlan went on to have a terrific career and is considered one of the best Uruguayans to play modern football (soccer). His time at United was certainly a misstep but it wasn't because he was bad. And it wasn't because United were bad. It just didn't work. Sometimes it just doesn't work. [1] https://www.youtube.com/watch?v=49Zym0gaZqA https://www.youtube.com/watch?v=49Zym0gaZqA
• rf15 9y ago
  > 9. Make decisions based on max skill, not average or min skill This is a strict specialist search - here, too you should make a decision depending on your requirements and future outlook: Do you need a generalist that can branch out and specialise, or strictly a specialist that only does the thing you need right now? (Also let's not argue which is better, specialist or generalist - deep down, each of us already knows and made the choice ;) )
• andrewstuart 9y ago
  One thing I find interesting is the absolute conviction that every interviewer has that they got it right when the reject a candidate. No "reject" decision can ever be reconsidered or questioned by anyone, ever.
  • roguecoder 9y ago
    If I were in charge of a giant company I'd hire every 50,000th applicant or whatever, just so we had a control to see if our interview process was worth the time.
• bambax 9y ago
  An alternative to an "interview" would be something more like an exam: have candidates try to solve a (relatively simple) problem in limited time, with or without external resources. Candidates would be watched, would know they're being watched, but would not see themselves being watched, which would probably take a lot of stress out. You could even test many candidates at the same time this way. And you could setup a system where each candidate could ask questions if needed, without being heard by other candidates (like in language learning classrooms). This must have been tried? but I wonder why it's not even discussed in the post, as an alternative?
  • overlordalex 9y ago
    There are a couple of web services that offer this - a quick google search around should return some company names, such as www.interviewzen.com Personally, I feel just as much stress knowing that the interviewer can review all my typos and mistakes in minute detail, leaving me to write code in my local editor and simply copy-paste working sections into the provided editor. Amazon made use of a service similar to what you've described at one point, however they required access to your machine to verify you weren't "cheating" in the interview. You can read one of the (many) threads here: https://news.ycombinator.com/item?id=13076073 https://news.ycombinator.com/item?id=13076073
  • cr0sh 9y ago
    My current employer does this. You're sat in the conference room, given a machine that has a screen monitor program running, and a set of tasks to perform on the code. You are told where to find the code in the introduction on the sheet of instructions. You are allowed to use any resource via the computer (so nothing you've brought in like a phone or laptop is allowed; basically, all work has to be "shown"). Then...go. Outside the room, the dev team watches the process. We want to see how you go about each problem, what resources you use, etc. It's always surprising the number of people who go for an hour or more and do nothing. Just sit there (or seemingly sit there - there's no keyboard or mouse activity). When I interviewed, they actually gave me an online test; the job was supposed to be for javascript, but the online was in PHP (which my prior position used, and I had been using for years). Passed that, and came in for the on-site part. I thought it was odd that they first tested me for PHP. Did a bit of face-to-face interview, then they wanted me to do the watched javascript portion (single page app). I first sat and read the problems, formulated some possibilities in my head, then jumped in. 30 minutes later I was done, and popped open a new file to write something to that effect (figuring if they were watching, they'd come back in). I sat for several more minutes, then they came back. "How's it going?" "Alright...umm, hey, I'm done." "No way! Are you serious? Are you sure?" Odd... "Yes." Apparently they had never had anyone finish the test that quickly, and get it completely right - especially someone who also had PHP skills, and had already demo'd them in the first test, which was also done correctly. I found this rather odd, as neither test was that particularly difficult. Apparently, though, it's not uncommon in our industry. I'm not sure what to make of that...
• FilterSweep 9y ago
  Here's a concept I had a question about that I don't think gets discussed that often... If a company were to offer a base salary at a mere third of the Google base salary for the same job, why should an applicant have to copy Google's depth of computer science abstraction in the coding interview? Is the onus on the developer for even entertaining such a demanding question at a low pay, or does the current economy favor employers in such a way that developers have no other choice? Or rather, is the knowledge of available jobs asymmetric enough to where employers can pay pennies, piss, and peanuts for A-level employees?
  • JoeAltmaier 9y ago
    I don't see a connection between pay and the interview process. Should the company also make their chairs one-third the height? Have one third the whiteboard marker colors? Feed you one-third of a lunch?
    • vorpalhex 9y ago
      My willingness to jump through hoops is proportionate to how much I want to work with you. If you pay me well and treat me well, I want to work with you. If you're trying to hire me for 50% of market, my tolerance is much lower.
      • JoeAltmaier 9y ago
        Then the filter would be "The skills of a Google Engineer, but can't get in there so might work here". All others need not apply?
    • kodr 9y ago
      well, if you interview for a nurse position, you shouldn't have to pass the doctor interview.
      • JoeAltmaier 9y ago
        Oh. I thought the statement was "for the same job".
• cl0wnshoes 9y ago
  I've performed interviews and phone screens for years and out of all the techniques I've tried all of them typically end up with me thinking I'm doing it wrong. Basic domain questions, problem solving, white boarding, white boarding along side the person helping them out, coding in an IDE, take home projects. As of today, in Kansas City, I'm looking at around 4% pass rate, and close to 90% utter face palming failures. I check my ego at the door, I try to make the person as comfortable as possible, small talk, help them out as much as I can, provide them with answers or explanations when they get something wrong. I've never asked an algorithm or data structure question, I've rarely asked a patterns question. Most people can't answer basic every day questions. Overtime my goal in interviews turned into making sure the interviewee left with more domain knowledge than when they came in hoping it will help them do better somewhere else. Ended up creating a pre-screening service that asks the same basic questions and in the end provides the user with a study guide based on how they answered. Currently piloting with two local recruiting companies and I'm finding the same similar statistics of failure/success. Maybe that makes me the issue :)
  • austincheney 9y ago
    My numbers were about the same when I was interviewing for JavaScript developers years ago at Travelocity. The only 1 skill I absolutely could not bend on was the ability to walk the DOM. Only 4 out of the 22 people I interviewed could do this and only two of them could do it well. Strangely enough I warned candidates days before the interview of what I was looking for and still almost nobody bothered to brush up on the couple of basic methods needed to do this 1 task.
  • ubernostrum 9y ago
    You know the quote: if you encounter an asshole first thing in the morning, you encountered an asshole. If you encounter assholes constantly all day long, it's probable you're the one who's the asshole. If you have a 90% rate of "utter face palming failures", the problem isn't with the people you're interviewing, it's with the interviewer and/or the interviewing process.
    • cl0wnshoes 9y ago
• pards 9y ago
  "There is not a single set of skills that define a good programer. ... No engineer can be strong in all off these areas." The ability to spell is one of them.