Live data from Hacker News

Technical interview performance is kind of arbitrary

blog.interviewing.io

141–150 of 246 posts

Re: Technical interview performance is kind of arbitrary

#141
post #48

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.

Totally. And I mean, I don't think I'm unreasonable. If it's the kind of thing I can reel off the top of my head or open `pry` and bang out in a couple minutes, I'll usually indulge. It's the multi-hour odysseys that are a big nope.

Re: Technical interview performance is kind of arbitrary

#142
post #140

Earlier 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.

Don't over-generalize, both of the big tech companies I've worked at in the last 10 years have this clause and require _explicit_ specific approval for any outside work, open source or not. Otherwise, yes, according to the contract it is their property. The enforceability of this debatable, but it is most definitely something that happens.

Re: Technical interview performance is kind of arbitrary

#143

Earlier 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…

Yeah I do wonder what you are getting out of not doing this. If they were to somehow cheat (get someone else to do it) this would be picked up very quickly on the job and waste everyone's time including their own.

Re: Technical interview performance is kind of arbitrary

#144

Earlier 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.

I believe those clauses are completely unethical in the first place, so I wouldn't have a problem.

Re: Technical interview performance is kind of arbitrary

#145
post #71

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. 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.

People usually have a coffee date first, before doing dinner. Here, you're doing dinner first, and then lunch. The first pass should be minimal in commitment, and give both sides a chance to get to know each other. They pass fizzbuzz or something doable in 15-30 minutes, you have a short convo about the company, and then you move on to the second pass.

Re: Technical interview performance is kind of arbitrary

#146

Earlier 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.

Not in sane states (read: California).

Well, sane in this thing, at least.

Re: Technical interview performance is kind of arbitrary

#147
post #62
post #48

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…

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…

Nearly all of the work I do for my employer is on public github. I always wonder though because if you just went to my personal github page it's not necessarily obvious that my Day Job is just a click or two away as these are contributions to another public repo, not one of my own. My own personal repo collection has close to nothing related to any job I'd ever want.

Re: Technical interview performance is kind of arbitrary

#148
post #71

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. 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.

Those other things being unpalatable doesn't change code tests being unpalatable.

Re: Technical interview performance is kind of arbitrary

#149
post #46
post #40

Earlier 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 ask candidates to submit code samples of their own choosing, or if they have nothing that they can supply for whatever reason we give them a short challenge which is only used for generating code to review.

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

#150
post #69

Earlier 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…

I would be surprised if a well constructed 2 hour test wasn't able to give you enough information on their structure and approach.

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.

Post reply on HN