Earlier quoted context omitted.
> 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. The approach you describe strikes me as shortsighted as well as to no small degree selfish. I don't do take-home tests, as a rule, for one overriding reason: my time is too valuable, and I have so much less of it to expend in discretionary fas…
At my company, we use take-home problems to answer: "is this person worth interviewing?" Can you take a simple problem and code us an equally simple solution? It's basically FizzBuzz. I rarely have people balk at doing this, but when they do, I'm happy to look at other code samples. I just need to know if they can write code.
Technical interview performance is kind of arbitrary
141–150 of 246 posts
Re: Technical interview performance is kind of arbitrary
#142Earlier quoted context omitted.
Most jobs at tech companies will have a clause in your contract about owning everything that you do or think of while employed.
This is true of work you do on company equipment during work hours. If things were as you describe, no one would ever be able to do open source, let alone sign standard FOSS CLAs or the like.
Re: Technical interview performance is kind of arbitrary
#143Earlier quoted context omitted.
I apply almost the same approach as OP. You can get a relatively good picture at a candidate's engineering skills and thinking ability via "go[ing] deep into the details", compared to asking algorithm questions. I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is c…
> I also ask candidates to code on a realistic problem. It doesn't involve any "fancy" algorithms or "tricks". What I want to see are the coding style, attention to details, and of course, if the candidate is comfortable at coding. Do you do that on the spot or is it a "take home" assignment? I've known many solid programmers (myself included) that could code anything you want, but if you put them in a room, sit ther…
Re: Technical interview performance is kind of arbitrary
#144Earlier quoted context omitted.
Startup A asked me to do a take-home programming challenge to prove my skills, as well as a general algorithm test to give them ideas how to run their core architecture. This took hours, I felt I was being asked to do their job for free (on the second test), and the results were pathetic. Startup B gave me an assignment to add a feature to their API and have my work merged with their active code base. I was compensat…
Option B is explicitly prohibited in your employment agreement for most salary workers. I would never consider working for a company that required me to violate a contract just for a chance to work there.
Re: Technical interview performance is kind of arbitrary
#145Earlier quoted context omitted.
>1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. A good reason not to work at your company. Why would I want to invest 4(!) unpaid hours into something where I am not even considered seriously yet? I recently had a coding challenge, which was not only vague, but also took up two hours of my t…
Would you have preferred to spend a whole day on an inconclusive onsite interview? Or perhaps a phone screen during which you're asked to implement a hashtable for the umpteenth time? As I said in another comment somewhere in this thread, one day people will learn to do this right. Hopefully this will happen before programmers as a profession have decided to never take code tests again.
Re: Technical interview performance is kind of arbitrary
#146Earlier quoted context omitted.
Wow, all I can say is that sucks to be you. I work in higher ed now, and I can do whatever I want outside of normal hours, as long as it doesn't interfere with the work I was hired to do. One benefit of having firmly rejected Silicon Valley is that I'm no longer at the whim of jealous employers who know I could find another job across the bay at any time and keep my home and social circles.
Most jobs at tech companies will have a clause in your contract about owning everything that you do or think of while employed.
Well, sane in this thing, at least.
Re: Technical interview performance is kind of arbitrary
#147Earlier quoted context omitted.
> 1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. The approach you describe strikes me as shortsighted as well as to no small degree selfish. I don't do take-home tests, as a rule, for one overriding reason: my time is too valuable, and I have so much less of it to expend in discretionary fas…
I have one major disagreement with you: > I have a Github profile with more than enough stuff on it Based on my experience only, you're in the minority here. Most candidates I've interviewed have barely anything on GitHub. Some UI/UX-ish people will have a portfolio, which involves a lot of "view source" and isn't too rewarding. Lots of perfectly good working programmers have no active open source participation, not…
Re: Technical interview performance is kind of arbitrary
#148Earlier quoted context omitted.
>1. If the candidate can't be bothered to complete a 2-4 hour (depending on claimed seniority) code test in the language of their choice, we can't be bothered to talk to them. A good reason not to work at your company. Why would I want to invest 4(!) unpaid hours into something where I am not even considered seriously yet? I recently had a coding challenge, which was not only vague, but also took up two hours of my t…
Would you have preferred to spend a whole day on an inconclusive onsite interview? Or perhaps a phone screen during which you're asked to implement a hashtable for the umpteenth time? As I said in another comment somewhere in this thread, one day people will learn to do this right. Hopefully this will happen before programmers as a profession have decided to never take code tests again.
Re: Technical interview performance is kind of arbitrary
#149Earlier quoted context omitted.
That's why you get them to talk you through their process during the face-to-face interview. It'll be immediately apparent if they didn't do the work themselves.
One of the best interviews I've had as a candidate (didn't get that job - it's the one that got away) involved me explaining design choices I made while implementing my solution to the take-home test. That was a great discussion, and didn't feel like the traditional interview-style questioning.
We bring them onsite and review the code and have them walk through what's going on. If they just blatantly copied stuff or handed in someone else's code they won't be able to stand up to scrutiny. And if they really do know it inside and out they probably could have written it anyways. We've had a small number of candidates who tried to pull a fast one but very very few
Re: Technical interview performance is kind of arbitrary
#150Earlier quoted context omitted.
I was bummed out recently when I did a take home test for a local start-up, which asked me to build a full web app. I spent 4-6 hours on it making sure it was perfect - just to turn it and and get told I did a great job but they decided they didn't really want to hire any non-senior engineers and where just testing the waters. This is happening a lot in Seattle recently - the job market is here is terrible for anyone…
Poor execution doesn't invalidate the idea. Happened to me too, although on a smaller scale. 4-6 hours is a bit much for a take-home evaluation project. If it can't be reasonably done by a distracted person in 4 hours, it's too hard/too long for a take-home test. Hopefully people will learn to do this right over time. Or, someone might solidify a common platform for doing this, a-la HackerRank or any of the other sim…
4-6 hours probably results in the candidate filling in a lot of basic details to get something to actually work that will tell the interviewer little more than the 1-2 hours spent implementing the core parts of the task.