7 ms·

This is a great list. Thanks for sharing it. I actually had the pleasure of interviewing at one of these companies before. They had a take-home project, which

• sangli 6y ago
  I would rather spend 3-4 hours working on a take home test rather than writing on whiteboard. Last year, I did take home test for 5 different companies and all 5 of them invited me to the next round. I yet to have a successful whiteboarding interview.
  • _qulr 6y ago
    But did you get any of those jobs? I wouldn't call being invited to the next round successful if you don't get the job. In fact it's a loss, more lost time for the candidate.
    • bananaface 6y ago
      Yeah seriously - "rounds" don't mean anything unless they publish numbers, and even then it's sketchy. You need to be able to verify that they're actually there to shrink the pool, not just provide the impression of it. Take-homes are free for the company to issue.
  • jnwatson 6y ago
    So you're saying you spent 15-20 hours just in order to get interviews. Many, many folks would not have the time for that.
• dudul 6y ago
  > A major issue is that they require candidates to have free time outside of work to complete them. Just like onsite interviews. Any interview process will require candidates to spend time outside of work. The only way to fix that would be a true, universally recognized certification/diploma that would prove that you can write software, but I don't see that happening any time soon.
  • dagw 6y ago
    Just like onsite interviews And unlike an onsite interview, I don't have to take time off during working hours to do them. My mental model is that I'm willing to spend N hours in total for the job application process. I'm happy to spend some of those hours working on a take home problem as long as that is instead of and not in addition to spending those hours doing multiple rounds of interviews.
• leonidasv 6y ago
  I hate take-home projects more than I hate whiteboard interviews. I think the best approach would be giving the candidate a broken app and have they debug it live or in a take-home debug-and-fix or debug-and-improve exercise. Could also have some refactor assignment. Has any company tried something like this before?
  • Ozzie_osman 6y ago
    Yes. I worked at Quora and we had a "practical interview" that was exactly this (it wasn't take-home though). https://www.quora.com/What-is-it-like-having-a-practical-interview-at-Quora?ch=10&share=25fcacf6&srid=OYIQ https://www.quora.com/What-is-it-like-having-a-practical-int...
  • sethhochberg 6y ago
    We do this at String and Key (and I adopted the process from my prior teams at Digitally Imported. I've posted jobs from both here on HN in the past). Its a one-hour hands-on programing lab via screenshare - a pretty straightforward task of consuming some data from an API, processing it a little, and displaying it. We use Ruby for our work, and ask the same of our candidates in the lab. No handwritten syntax, exotic/tricky algorithms, or gotchas. Just a task to see how a candidate approaches a problem, deals with requirements, and implements them in our language of choice. Happy to go into more detail if anyone is trying to implement something similar in their own hiring processes.
    • leonidasv 6y ago
      I'm interested in hearing more. I'm currently in the process of improving my interview approaches — currently a live coding session with a real-world problem involving an internal dataset.
      • sethhochberg 6y ago
        It sounds like you're on the right track. I think the important parts are: 1) It should be a live exercise (at least mostly live). I'm less interested in the end result than how someone got there, and most people chose to narrate their thought process as they work through the exercise. 2) The candidate should be able to work in their own environment. Online assessment tools can be different enough to introduce friction in a timed interview scenario. I'm interested in seeing how fluid a candidate is with the tools they'll use every day. 3) It should have the same expectations as your day-to-day work. Did the editor have a linter configured, and did they use it? Were tests written for the parts of the lab that introduced nontrivial logic? Is there a README? Is it all one git commit, or did they habitually make commits as they worked? 4) The design of the lab should have a decision point - I'm currently using a lab which could be implemented successfully with either a relational database or some kind of cache store. The strongest candidates recognize there are multiple paths and can justify why they chose the one they did. This works best for reasonably experienced devs who can actually be expected to create something from scratch from a set of requirements on a short time frame. For more junior people, I'd typically give a version of this lab that I completed myself and introduced a couple of bugs into. The task is to fix the bugs.
• joncalhoun 6y ago
  Was this a timed take home project or something with a flexible timeline? That is, was it "You have to respond within 3 hours of receiving this email with your solution" or something more flexible? I mostly understand why some companies do the x hours routine, and when I've done interviews this way I've historically performed well, but it just felt like it added unnecessary stress. For instance, anyone on the job doesn't have to worry about issues like, "What if I couldn't get the app up and running because I had the wrong version of X installed?" longer than maybe their first day on the job. And if you plan on hiring an engineer for a few years, one day is irrelevant. At best this felt like it favored contractors who were more experienced at jumping into new projects frequently.
  • mbil 6y ago
    In this case it was a flexible timeline. It took a few hours to properly complete, and I was given a number of days to return it.
• nickwalton00 6y ago
  I've had companies straight up pay me for doing a take home project as part of an interview. I think that's the ideal way as it gets rid of the potential for exploitation/excessive burden that can come from take home projects.
  • autarch 6y ago
    This can add a lot of overhead, and some candidates may have jobs that forbid them from accepting outside work. A good middle ground would be to have the company make a donation to the candidate's choice of nonprofit.
    • unishark 6y ago
      Or just offer both options. I certainly wouldn't eliminate the opportunity for unemployed people to get a little cash, just because of contract issues that gainfully employed people might have.
      • bbarnett 6y ago
        Yes, but... Now one worries, is this itself a test? Are they judging my desire to donate.
        • SuoDuanDao 6y ago
          Well, honestly - if I wanted to donate, I could do so myself after they pay me. Then I'd be worried... are they watching to see whether I engage in hollow virtue-signalling?
          • bbarnett 6y ago
            No, they're watching to see if you're worried about whether they're watching to see if you're engaged in hollow virtue-signalling. :P
        • unishark 6y ago
• muratk 6y ago
  > choose and implement and couple enhancements to a toy app I think this is a key piece why this kind of project is useful, because that's exactly what they'd do when they start in their coding role: jump into an unfamiliar code base and fix a bug, implement something tiny, make things better along the way. When hiring for a React role, I went to find an open-source React app and simply asked the candidate to mod it a bit. We then discussed the why and how, but also how they liked the app and why. We only gave this task to the final candidates, and the ones that had React experience were done in very little time, because typing wasn't the issue here, but reading unfamiliar code and understanding the mechanics of the app. Writing a hello world app from scratch or coding fizz buzz doesn't tell me enough.
• danjac 6y ago
  Take-home tests are fine in isolation, but if every company does that you'd pretty much be spending all your time doing take-home projects and nothing else. Also many companies will insist on a take home project in addition to everything else, including a whiteboard interview. So you can pour time and effort into this project only to be eliminated further down the line (or just ghosted). It's like they assume applicants are applying to one job at a time and have no other work or life commitments. I dunno, it feels like the tech industry has forgotten how to interview candidates, as in "just chat with someone like a normal human being to see if they are a good fit for what you need", and like many other aspects of the profession have fallen for dumb processes, fads, cargo-culting, outsourcing to third parties, and dubious technical solutions in lieu of experience and social interaction. I learned this early in my career, and found I can pretty much size up someone's technical chops - assuming they're in my wheelhouse - and get a good idea of their professionalism - with a short, half hour phone/Zoom interview. Yes, I can see how this might lend itself to bias and prejudice, but it seems the solution there is to train interviewers to overcome biases and have more diversity (in all senses of the word) in your interviewing team.
  • bananaface 6y ago
    Just look at their GitHub and if it looks good, dive in at the interview to make sure they actually wrote the code. Isolated take-home tests seem ridiculous to me if the candidate has public code available. You're filtering out anyone who likes to avoid duplicated effort.
    • rocqua 6y ago
      Requiring github as a CV is worse from the POV of not forcing people to spend a lot of time outside work programming. Not everyone has the inclination or time to code outside of work. Many of these people are still very competent developers.
      • danjac 6y ago
        If a person has some interesting Github activity (that they can back up) I would certainly discuss it with them. If I'm hiring for a Django developer and the candidate has contributed to the Django core or a related library, that would be a strong signal - but it should not be a requirement. A strong candidate is typically a mixture of good work history, side projects, hobbies and interests, personality and other things that indicate they would be a good fit for your team. How much and in what way depends on the job and the person. Maybe the startup company needs a person who does lots of side projects, builds stuff on their own etc because you need self-starters that don't require lots of hand holding and are ready to take the initiative to learn. On the other hand your 1000-strong engineering subdivision at big corp needs more heads-down 9-5ers who just produce reliable output. Maybe the things you ask a junior dev out of college are different to what you would ask a mid-career developer. There's no one size fits all approach that people seem to be looking for.
• 908B64B197 6y ago
  I'll play devil's advocate and defend whiteboard interviews as compared to take home or online assessments. Take homes are not very respectful of the candidate's time and, especially if they are not time bound, often leads to a candidate wasting a significant amount of time on these assignments. Plus, there's always the possibility that desperate candidates would cheat and have the assignment done by someone else. I would only use take homes and HackerRank style quiz for applicants that are from institutions I don't fully trust with quality or applications that are very spammy in nature, i.e from a college/bootcamp that has an abysmal application-to-hire ratio [0]. For candidates from serious institutions I favor a two-step approach: a screening interview with a light coding question and a full whiteboard interview. The screening's purpose is really only to answer questions about the hiring process and check that the candidate can write very simple code by himself when given a trivial problem [1]. Now, a lot of folks do whiteboard interviews wrong. They often expect to get the exact implementation of an algorithm they found in a textbook and for code on the board to compile. This isn't the point of whiteboarding. Doing this only promotes rote memorization. A good whiteboard interview should be a toy problem that can be solved in several different ways by using different strategies or data-structures. The idea is to see how the candidate will break down the problem. Is the candidate able to formulate test cases, write a simple implementation, verify his code and correct the implementation should it fail a test? On the more meta side of things is the candidate able to take feedback and explain why a certain strategy was chosen? Of course it's not representative of real world engineering but it's a good way to peek at someone's ability to debug and reason about programs; these abilities translate well into debugging and design. Especially at the college level, I really can’t make any assumptions on what the candidates know. I’m not judging their knowledge of the standard library of X programming language or the framework-du-jour but their ability to learn it fast. [0] https://economictimes.indiatimes.com/tech/ites/95-engineers-in-india-unfit-for-software-development-jobs-report/articleshow/58278004.cms https://economictimes.indiatimes.com/tech/ites/95-engineers-... [1] https://blog.codinghorror.com/why-cant-programmers-program/ https://blog.codinghorror.com/why-cant-programmers-program/