231–240 of 471 posts
To a large degree, these look like no-name companies who probably have to resort to this kind of thing to make up for worse pay and benefits as compared to FAANG.
We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…
I guess the tasks are something like "take this scaffolding and implement thing x". What would you think if the candidate responded saying the scaffolding does not allow to implement X properly without sacrificing things y and z, and instead of turning in code for review would show up for a discussion about the compromises and deficiencies in the scaffolding?
Earlier quoted context omitted.
How do you avoid awarding candidates who violate your request of no more than two hours and spend considerable time coming up with something amazing? They may still produce 100 lines of code — but those 100 lines may end up being unusually elegant, beautiful code that stumps 40 year veterans. How do you avoid punishing someone who took your requested time constraint seriously (or otherwise didn’t have enough free tim…
I reject entire the premise of this question. Anyone spending huge amounts of time is either going to produce way too much or they just took too long. There is nothing magical about programming where taking 8 hours to solve a 2 hour problem is going to stump 40 year veterans or be unusually beautiful. That's just unrealistic.
If I want this job, I would spend this extra time to submit this better solution because obviously that will improve my chances of getting the job. But that means that these take home assignments might not be such a good indicator of efficient proficiency. You might be overvaluing people spending more time on these tasks and undervaluing people spending the allotted time on these tasks. For example, a better developer who did write a solid solution in under 2 hours might get passed over because her solution seems not as good as mine where I did spend another hour to rewrite my initial messy solution.
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 was to choose and implement and couple enhancements to a toy app. In the subsequent conversations, we discussed how I approached the problem, details of my design, technical tradeoffs, etc -- all the sorts of things you would expect a professional sw engineer t…
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?
It was good because:
1. There was no faffing about to set up the environment 2. There was some small, easy wins at the beginning which got me engaged and thinking about the task. 3. It was fixed time - I had to specify when I would start and then the test was emailed to me 15 minutes before that time. I then had 4 hours to return it via email.
This solved most of the problems I've seen with take-home tests - namely that they take far too long and ask the candidate to do all sorts of pointless admin tasks before they can start coding. Unless the candidate happens to be super familiar the exact environment of the test (including setting up a new project - how often do most people start new projects?), you're either making them waste hours of time before they can start, or disregarding good candidates.
Ultimately you want to find candidates who can solve problems and understand software architecture. Unless you're interviewing for a devops position, making them spend hours setting up a build environment seems like testing for the wrong thing.
We use a 3 step process, sans whiteboard: 1. First interview, the candidate interviews us. What market we serve, what our development processes are, what our technology stack is. If they express interest by being prepared and asking good questions, we send them home with 2. a programming task. Choose 1 of 5 tasks. The tasks are not abstract problems or puzzles, but come out of the designs we've implemented. We ask fo…
I was asked to bring in my laptop with some of my own code - I had a side project at the time, so no problem. We talked about the code, decisions I had made. I was asked to implement a simple feature. I did.
No time consuming take home exercise. No whiteboard riddles. No need to have a github full of work (lets face it most peoples work is in house and not easy to show off). Code I was familiar with, so less stress. The only downside would be not having code available, but then it will be the equivalent effort of a take home exercise to produce something.
Here is how to do a tech interview that (I think) will work for everyone. I am sharing in the hope that this will become the standard, it was certainly the most pleasant technical interview that i have had, and somewhere where our industry is badly broken. I was asked to bring in my laptop with some of my own code - I had a side project at the time, so no problem. We talked about the code, decisions I had made. I was…
Seems like a good solution if the candidate has a side project. However, many candidates might have their majority of the "good" code they've written owned by their previous company.
> I am sharing in the hope that this will become the standard
Hopefully it can become a standard option. There's probably never going to be a standard technique which fits for all candidates (or employers).
Earlier quoted context omitted.
I once applied at a company that started with a programming test before any human communication. I think I did a pretty good job on the test. After that I was rejected when I assume they saw my resume. They gave me $50 store credit on their website (custom sticker printing). I assume it cost them a lot less than $50 but it was still pretty cool.
This past week one of the companies on "who's hiring" sent me three challenges that "would only take 2 hours" before I ever got to talk to a human being or even got a human being responding with an email. This was a fully automated system apparently. "Take this programming test, we'll let you know if you're good enough to talk with a human." Whilst the challenges were not particularly complex, you also had to ensure…
I did one recently after the initial HR person chat. I spent a morning on it as they suggested 2 or 3 hours. But then I was rejected for the most pedantic reasons (2 white space PEP violations), not setting up mocks for testing (that would have doubled the scope of the project). Providing an HTML response rather than JSON when the spec asked for a "page, don't bother about styling". And various other trivialities.
I tried passing on my complaints, but the HR girls didn't like that. Pretty disrespectful after giving up a morning of my free time.
Sennder is the company, as I feel that we should be naming and shaming.
No one enjoys whiteboard interviews but it's not clear that these companies have better alternatives. Many of them do take home projects which are time consuming. I'd prefer the employer look at my GitHub profile as there's plenty of code there already. Furthermore, I'm not a fan of "interviews" in general, I find that more information is transmitted by eating lunch with the team and talking like normal people.
Our interview process is far more advanced. We place the candidate in a room with a large whiteboard for 15 minutes alone with the lights off. I then walk in with a 6 piece dresser [1] from IKEA (obviously keeping the lights out). I explain to the prospect that this particular dresser is missing one piece - BUT we need the dresser assembled then disassembled and placed back into the box [without anyone seeing]. More…