18 ms·

My most enjoyable interview was for an internship in college. I had a take home coding challenge where I had to write some simple code to fetch information from

by Puer 8y ago

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

morcutt 8y ago
This is great. I wish more companies did something like this.
automatoney 8y ago
I would love to be interviewed like this. Even though the candidate does end up spending time doing work outside of work, they'd end up doing that anyway if prepping for an algorithms interview. At least with an assignment you can be finished instead of doing endless leetcode prep. Plus it gives you a chance to practice relevant software engineering skills in a different environment.
- jiveturkey 8y ago
  until you have to endure the fifth rejection and realize you have to multiply this effort for every interviews. Whereas you can prep for an algorithms interview once, and any additional prep is incremental and focused by prior interviews.
sifoobar 8y ago
My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans. I don't do challenges any more, life is too short to waste solving problems that don't exist for someone else without getting paid.
- MarkMc 8y ago
  All the coding challenges I ask of my candidates have been real-world problems I had to solve in the past where I though, "huh, this would probably be a good interview question". I also pay candidates for their time, except for the initial screening test.
- navinsylvester 8y ago
  Second that. I was hired via this model. Have also used this approach to hire and this has paid off more than any other approach. A simple 100 line code can be curated and taught by a friend/relative in a very elaborate way. This approach can negate that issue in someway.
- maccard 8y ago
  > My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans. That excludes anyone with a no moonlighting agreement in their current contract, though.
- matthewmacleod 8y ago
  While I appreciate that it can be a waste of time, the way I tended to look at this was that if the coding test / task was minimal, it was an acceptable trade-off for both company and candidate. Like, that task should take an hour or so. The problem it's trying to solve is just the surprising number of bad candidates that apply. We're talking about people with decent CVs, a bit of work experience at different companies, some open-source work etc., and who had a good chat on the phone – sometimes they just completely mess it up when faced with a task like "combine these JSON files to make output that looks like this sample". Things like code that literally doesn't work, or code that uses totally inappropriate tools. We want to avoid wasting both their time and our time by bringing them onsite for an interview that isn't going to go anywhere. The risk with being "hired to do real, paid work remotely" is that it relies on finding people who are in a position to do that, and this ends up excluding a bunch of good candidates. Not everybody is in an employment situation that will allow them to do external work, and it disincentives people with families or other commitments. The process of applying for a position shouldn't be over-burdening on a candidate. I agree that it's unfair to expect lots of stupid work, multiple-day interview processes and so on. But I don't think it's unreasonable to expect that a candidate who wants to work with a company can afford to spend a few hours in total as part of that process.
11thEarlOfMar 8y ago
This is exactly how we do it at my company. The first interview is mainly for the candidate to get to know the company, products, tech. If we think there is a fit, we send them home with a coding task, choose 1 of 5, not expecting more than 100 lines of code, or more than a couple of hours (though all candidates have submitted more and spent more time). There is no time expectation, but they usually finish in a week or less. They then come back for a code review, walk the team through their code and explain it. This tells us a lot about their ability, but also their communication style and clarity, how they approach problem solving in general and even in which problem they chose. I chose this approach because 'coding under duress' during an interview does not offer a valid sample of what the candidate can do. Taking the time they need and working in a comfortable environment will give a much more realistic result. Coupling the take-home with an in-person code review weeds out those who may just Google up or borrow code from elsewhere.
gabrielhoch 8y ago
This sounds exactly like one of the best interviews I had when I was searching for my first dev job, and I've tried to emulate it whenever I've been involved in hiring new people. A good template is: - Simple yet relevant take home coding test with a relaxed timeframe - Technical portion of the interview where the candidate is asked to add a simple feature to their existing tech test. - This is followed by a more general interview. None of these sections should take more than 1-2 hours.
matthewmacleod 8y ago
That's great to hear – my previous company did something pretty similar to this, except the onsite "technical" portion involved actually pairing with one of the team for an hour to add one of those features, then discussing that process with a second engineer to describe what we'd done together and why. I generally think this works well for a few reasons: 1. The take-home task lets us see if candidates meet a minimum standard of competency and generally follows good practice – do they test the solution, document it, write clear… of course, I think it's important that the size of this task is limited to avoid wasting candidates' time. 2. The on-site interview helps to make sure the candidate is able to discuss the work they're doing, collaborate with other technical staff, and communicate technical ideas well. It feels like the overall goal of an interview process is to ensure that the candidate is at the skill level they have communicated, and that they can work with others.
wccrawford 8y ago
The coding challenge sounds a lot like what my company does (including the time contraints and how long it really takes to code it), but the interview is definitely different. Our coding "challenge" isn't a challenge at all, it's just a test of basic developer competency, including following the spec and making things work. There isn't a lot of room to ask about why things were done a certain way. You've got me thinking that maybe I need something a little more complicated that will give room for those questions.
ldite 8y ago
With this approach you'll miss good senior people; I have dependants and very little free time outside work. Last time I was looking for a job I skipped everyone who wanted me to do prep/homework. If the other interviews hadn't worked out I'd have gone back to them, but I didn't need to.
- g105b 8y ago
  Senior people will be able to do the two hour coding homework in way less than two hours. If someone can't manage this as part of an interview process, it might be a sign of their time management abilities.
  - lifeisstillgood 8y ago
    Senior does not mean you type faster. It means you don't do unnecessary work, you avoid pitfalls and traps you have seen before, you don't over-engineer but you keep it as simple as possible. It also means that you push back against non-constructive requests from business and management and focus your time and effort on what matters. I also avoid anyone who wants me to do a coding exercise for a few hours over the weekend. If you want pay me for that time, and make it not a dig and fill hole exercise - find a OSS project that needs some contributions. Decide that you and your team will do thsoe via your ongoing interview process that hires people before the need arises, so you can all take your time selecting and onboarding people. Value your own time, or no one will
    - PurpleBoxDragon 8y ago
      >you don't over-engineer but you keep it as simple as possible It should also mean you don't under engineer, but that is extremely hard to test for because that involves knowing the business and your customers and having a reasonable estimate of where future needs will be. I'm not sure how you would test for lack of under engineering, especially since any interview task would be a perfect case where you practically can't under engineer since it is guaranteed throw away work. Maybe asking during code review for how you would've done the solution different if you knew that in the next quarter you would likely have to implement either feature A and B or C and D (but you didn't know which yet).

by Puer 8y ago

morcutt 8y ago

This is great. I wish more companies did something like this.

automatoney 8y ago

I would love to be interviewed like this. Even though the candidate does end up spending time doing work outside of work, they'd end up doing that anyway if prepping for an algorithms interview. At least with an assignment you can be finished instead of doing endless leetcode prep. Plus it gives you a chance to practice relevant software engineering skills in a different environment.

jiveturkey 8y ago
until you have to endure the fifth rejection and realize you have to multiply this effort for every interviews. Whereas you can prep for an algorithms interview once, and any additional prep is incremental and focused by prior interviews.

sifoobar 8y ago

My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans. I don't do challenges any more, life is too short to waste solving problems that don't exist for someone else without getting paid.

MarkMc 8y ago
All the coding challenges I ask of my candidates have been real-world problems I had to solve in the past where I though, "huh, this would probably be a good interview question". I also pay candidates for their time, except for the initial screening test.
navinsylvester 8y ago
Second that. I was hired via this model. Have also used this approach to hire and this has paid off more than any other approach. A simple 100 line code can be curated and taught by a friend/relative in a very elaborate way. This approach can negate that issue in someway.
maccard 8y ago
> My best experience so far was being hired to do real, paid work remotely and then invited to discuss the solution and further plans. That excludes anyone with a no moonlighting agreement in their current contract, though.
matthewmacleod 8y ago
While I appreciate that it can be a waste of time, the way I tended to look at this was that if the coding test / task was minimal, it was an acceptable trade-off for both company and candidate. Like, that task should take an hour or so. The problem it's trying to solve is just the surprising number of bad candidates that apply. We're talking about people with decent CVs, a bit of work experience at different companies, some open-source work etc., and who had a good chat on the phone – sometimes they just completely mess it up when faced with a task like "combine these JSON files to make output that looks like this sample". Things like code that literally doesn't work, or code that uses totally inappropriate tools. We want to avoid wasting both their time and our time by bringing them onsite for an interview that isn't going to go anywhere. The risk with being "hired to do real, paid work remotely" is that it relies on finding people who are in a position to do that, and this ends up excluding a bunch of good candidates. Not everybody is in an employment situation that will allow them to do external work, and it disincentives people with families or other commitments. The process of applying for a position shouldn't be over-burdening on a candidate. I agree that it's unfair to expect lots of stupid work, multiple-day interview processes and so on. But I don't think it's unreasonable to expect that a candidate who wants to work with a company can afford to spend a few hours in total as part of that process.

11thEarlOfMar 8y ago

This is exactly how we do it at my company. The first interview is mainly for the candidate to get to know the company, products, tech. If we think there is a fit, we send them home with a coding task, choose 1 of 5, not expecting more than 100 lines of code, or more than a couple of hours (though all candidates have submitted more and spent more time). There is no time expectation, but they usually finish in a week or less. They then come back for a code review, walk the team through their code and explain it. This tells us a lot about their ability, but also their communication style and clarity, how they approach problem solving in general and even in which problem they chose. I chose this approach because 'coding under duress' during an interview does not offer a valid sample of what the candidate can do. Taking the time they need and working in a comfortable environment will give a much more realistic result. Coupling the take-home with an in-person code review weeds out those who may just Google up or borrow code from elsewhere.

gabrielhoch 8y ago

This sounds exactly like one of the best interviews I had when I was searching for my first dev job, and I've tried to emulate it whenever I've been involved in hiring new people. A good template is: - Simple yet relevant take home coding test with a relaxed timeframe - Technical portion of the interview where the candidate is asked to add a simple feature to their existing tech test. - This is followed by a more general interview. None of these sections should take more than 1-2 hours.

matthewmacleod 8y ago

That's great to hear – my previous company did something pretty similar to this, except the onsite "technical" portion involved actually pairing with one of the team for an hour to add one of those features, then discussing that process with a second engineer to describe what we'd done together and why. I generally think this works well for a few reasons: 1. The take-home task lets us see if candidates meet a minimum standard of competency and generally follows good practice – do they test the solution, document it, write clear… of course, I think it's important that the size of this task is limited to avoid wasting candidates' time. 2. The on-site interview helps to make sure the candidate is able to discuss the work they're doing, collaborate with other technical staff, and communicate technical ideas well. It feels like the overall goal of an interview process is to ensure that the candidate is at the skill level they have communicated, and that they can work with others.

wccrawford 8y ago

The coding challenge sounds a lot like what my company does (including the time contraints and how long it really takes to code it), but the interview is definitely different. Our coding "challenge" isn't a challenge at all, it's just a test of basic developer competency, including following the spec and making things work. There isn't a lot of room to ask about why things were done a certain way. You've got me thinking that maybe I need something a little more complicated that will give room for those questions.

ldite 8y ago

With this approach you'll miss good senior people; I have dependants and very little free time outside work. Last time I was looking for a job I skipped everyone who wanted me to do prep/homework. If the other interviews hadn't worked out I'd have gone back to them, but I didn't need to.

g105b 8y ago
Senior people will be able to do the two hour coding homework in way less than two hours. If someone can't manage this as part of an interview process, it might be a sign of their time management abilities.
- lifeisstillgood 8y ago
  Senior does not mean you type faster. It means you don't do unnecessary work, you avoid pitfalls and traps you have seen before, you don't over-engineer but you keep it as simple as possible. It also means that you push back against non-constructive requests from business and management and focus your time and effort on what matters. I also avoid anyone who wants me to do a coding exercise for a few hours over the weekend. If you want pay me for that time, and make it not a dig and fill hole exercise - find a OSS project that needs some contributions. Decide that you and your team will do thsoe via your ongoing interview process that hires people before the need arises, so you can all take your time selecting and onboarding people. Value your own time, or no one will
  - PurpleBoxDragon 8y ago
    >you don't over-engineer but you keep it as simple as possible It should also mean you don't under engineer, but that is extremely hard to test for because that involves knowing the business and your customers and having a reasonable estimate of where future needs will be. I'm not sure how you would test for lack of under engineering, especially since any interview task would be a perfect case where you practically can't under engineer since it is guaranteed throw away work. Maybe asking during code review for how you would've done the solution different if you knew that in the next quarter you would likely have to implement either feature A and B or C and D (but you didn't know which yet).