Technical interview performance is kind of arbitrary • Hacker News Board

Re: Technical interview performance is kind of arbitrary

#101

Post by toby » Wed, Feb 17, 2016, 8:59 PM UTC

maxaf wrote: post #71

chrisper wrote: post #67

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.

So if they do well in the take-home test, you give them an offer? Or do they still have to do the all-day on-site after that?

Re: Technical interview performance is kind of arbitrary

#102

Post by rm_-rf_slash » Wed, Feb 17, 2016, 9:00 PM UTC

superuser2 wrote: post #90

rm_-rf_slash wrote: post #73

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.

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.

Re: Technical interview performance is kind of arbitrary

#103

Post by lamontcg » Wed, Feb 17, 2016, 9:00 PM UTC

jessedhillon wrote: post #25

brightball wrote: post #22

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

Interest is not enough, unfortunately. There are plenty of engineers who are attracted to the challenge and excitement of building new things, but have no appreciation for The Right Way to build things. Great engineers think beyond "how" and ask the "should" questions as well. Mediocre engineers glue things together in a haphazard way with little thought about what's the best way to write things. Caring about maintai…

At the same time you can overdesign something based on how it 'should' be engineered to the point where you haven't shipped anything and your company is bankrupt. You need someone that can pick a decent enough pattern which can get the job done in the time allotted.

I would not hire someone that has a list of a hundred 'shoulds' which need to be met for any project to be shipped. That's a recipe for never shipping.

Re: Technical interview performance is kind of arbitrary

#104

Post by illicium » Wed, Feb 17, 2016, 9:01 PM UTC

jkyle wrote: post #91

brightball wrote: post #22

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

> I expect a programmer to be able to pick up a new language or database within a couple of weeks (tops) in most cases. They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.

There's more to being a productive programmer than knowing the semantics of a language.

Someone who has been programming for a while but is learning a new language will have a ramp-up period when their code is ugly or unidiomatic, and they will take longer to write it, but it will capture the correct algorithms and abstractions. Compare that to someone who is inexperienced and writes a pile of exponential-time spaghetti that is slow and unmaintainable in any language.

Re: Technical interview performance is kind of arbitrary

#105

Post by maxaf » Wed, Feb 17, 2016, 9:02 PM UTC

toby wrote: post #101

maxaf wrote: post #71

Earlier quoted context omitted.

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.

So if they do well in the take-home test, you give them an offer? Or do they still have to do the all-day on-site after that?

Do well in the take-home test? Come in, meet the team, do the culture-fit thing. Then you get an offer. And this doesn't need to be an all-day thing. Who wants to keep selling the company to a candidate all day long? :)

Re: Technical interview performance is kind of arbitrary

#106

Post by bitbuilder » Wed, Feb 17, 2016, 9:02 PM UTC

dudul wrote: post #41

dms105 wrote: post #36

Earlier quoted context omitted.

You could argue that building software has a higher potential for complexity than work in any of those fields. So how do you measure someones ability to be good at that within a reasonable time frame using limited resources (interviewer time)? You're always going to have a "broken" process with those limitations, because you can't test for every possible scenario they may encounter. This leads to a small subset of qu…

More complex than practicing medicine? Or law?

There are two things that guarantee at least a nominal level of competency in those fields:

1) For junior positions, both have professional accreditation, with standardized testing that ensures a basic level of competency. Not to mention the mandatory schooling (in most cases).

2) If you screw up as a doctor or lawyer, you can end up with official sanctions on the public record. If you screw up too bad, you lose your ability to continue to do your job.

I've worked with plenty of dead weight developers who wouldn't pass even these nominal competency tests.

Further, it just seems to me it's easier to benchmark your successes as a doctor or lawyer. At least in a way that has meaning to your potential employer.

I think part of that has to do with the fact we pretty much all work on teams. The actual projects themselves might be somewhat verifiable, but figuring out that developer's actual contribution is a pure crapshoot.

I list of successes for a doctor or lawyer are going to be both more individual, and also verifiable (i.e., less likely to be bullshit).

Re: Technical interview performance is kind of arbitrary

#107

Post by seanwilson » Wed, Feb 17, 2016, 9:02 PM UTC

jkyle wrote: post #91

brightball wrote: post #22

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

> I expect a programmer to be able to pick up a new language or database within a couple of weeks (tops) in most cases. They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.

> They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.

From the opposite side of things, someone who's only been using the same tools for 5 years is probably going to struggle picking up new tools. For the projects I work on, it's rare to use the same languages and tools for every project. I'd rather have someone that understands how to write good code in general and knows multiple programming paradigms instead of someone claiming to be a guru in a single language.

If someone knows Java and JavaScript well for example, is it really going to take them more than a few weeks to be productive in Python (especially if you have someone on the team helping with picking the appropriate libraries to use)?

Re: Technical interview performance is kind of arbitrary

#108

Post by dudul » Wed, Feb 17, 2016, 9:03 PM UTC

jhspaybar wrote: post #60

dudul wrote: post #26

Earlier quoted context omitted.

What do they involve? How do you interview a sales guy? what do you ask him? How do you interview a product marketer?

I was a sales guy, I typically showed up with 6 months of pay stubs, dressed nicely, and had a job within hours.

That's interesting. So would you say that this process was broken? Was it good? I'm genuinely trying to understand how other fields handle recruitment to compare it with the "broken" IT equivalent.

Re: Technical interview performance is kind of arbitrary

#109

Post by RogerL » Wed, Feb 17, 2016, 9:03 PM UTC

jkyle wrote: post #91

brightball wrote: post #22

With programmers, the single easiest way to identify good candidates (in my experience) is sheer interest in what they do / desire to learn. This is a learn everyday field and if you're interested in what you're doing, you're going to do a lot better at it. It's hard to apply yourself mentally to something that you don't have a good level of interest in. Given that it's a learn everyday field, people with that level…

> I expect a programmer to be able to pick up a new language or database within a couple of weeks (tops) in most cases. They may be able to hack around, write a for loop, track down a bug....but you're not going to get the same caliber of work from someone who first saw python two weeks ago compared to someone whose been using the language for 5 years on real projects.

So how exactly is anyone supposed to gain new experience?

I don't mean to be combative, but so many job recs and interviews expect X years of Y. How do you get that time it? You learn it, right? I didn't used to know Python, but it was obviously useful for my job. So, I installed it and learned it. I was producing useful results for my company very rapidly. Sure, a few years later my skills are more well rounded and 'pythonic', but really, so what? This is how every. single. one. of. us. learns.

My job is only interesting to the extent I am learning new things. You are only going to hire drudges if you require the applicant already know everything needed for the job. How boring. Obviously I'm not arguing for hiring a janitor to rewrite Google's deep learning from scratch; some ability is required. But picking up basic skills in a new language? Easy peasy. Nothing to it. That's our job.

Re: Technical interview performance is kind of arbitrary

#110

Post by eropple » Wed, Feb 17, 2016, 9:04 PM UTC

darryl42 wrote: post #53

eropple wrote: 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…

How do you feel about the all day interview process some large companies are currently using? Keep in mind you probably had 1-3 phone + computer interviews before the in person interview. A take home test seems like a less time intensive process as you at least don't need to take time off from your normal job to do it.

> How do you feel about the all day interview process some large companies are currently using?

I don't go for the all-day ones (I just decline; after my last Google interview I'm done putting myself through the wringer for a whateverjob), but I really do enjoy in-person interviews. Like, last time I was looking for a FT gig I did at least a phone interview at 35 places and an in-person at 20. I enjoy interacting with people. I get a great lay of the land of what the market looks like, what's not just "cutting edge" but what is, in practice, the leading edge of what people are actually trying to use in anger. This is, in addition to just learning about a given company, why I view in-person interviews as a two-way street. After my last FT company shuttered, I moved into consulting largely because I have a better view of the world than most people working for individual companies. I've learned, from talking to a ton of people, many things that might even seem like offhand facts from idle conversation that have helped me. Like, I happened to remember that D3 instances exist in AWS from a chat with somebody on one of those interviews and in the process I saved a client $20K/month in EBS costs.

Maybe it's a Shockingly Minority Viewpoint, but I think that, in a healthy business relationship (and it's important to realize that employer/employee is a business relationship), both sides get something, even if it's the short relationship of an interview.