Technical interview performance is kind of arbitrary • Hacker News Board

Re: Technical interview performance is kind of arbitrary

#111

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

illicium wrote: post #104

jkyle wrote: post #91

Earlier quoted context omitted.

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

Yes, and code reviews and other mature practices will get the person over that hump very quickly. Anyone can point you to the 'PEP8' of your language of choice.

Re: Technical interview performance is kind of arbitrary

#112

Post by kelvin0 » Wed, Feb 17, 2016, 9:06 PM UTC

chrisper wrote: post #67

maxaf wrote: post #29

Take home tests FTW. The thinking goes as follows: 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. 2. If the candidate does reasonably well by completing the code test somewhat on time (with a fat margin allowed for them, well, having a life) and within parameters of the task, they're invited…

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

You strike me as the type who would also balk at fizzbuzz and other 'typical' interview questions. What do you propose? Say you have to interview a candidate for your own startup? How would you go about it?

Re: Technical interview performance is kind of arbitrary

#113

Post by sandworm101 » Wed, Feb 17, 2016, 9:06 PM UTC

NDizzle wrote: post #65

jchendy wrote: post #51

Earlier quoted context omitted.

As somebody who's terrible at monologuing, this scares me.

It shouldn't be a monologue - it should be a discussion.

It's only a discussion if the person conducting the interview has some concept of what they ask. I've been to several interviews over the years where the HR person asked questions without any understanding, questions they were obviously handed by bosses. They then hurry to write down your every word of the response, the plan being to google key terms later rather than admit ignorance now.

I had a HR interview team recently ask me about a particular rule governing the admission of evidence in administrative or arbiter proceedings. I started by asking whether they wanted me to explain admission generally or specifically how it differed between the two.... total blank faces. I asked whether I should first explain relevance ... they all nodded.

"Explain it as you would explain it to your students."

"That's at least a three hour lecture."

"Ok, can you do a 10 minute version?"

"Yup."

Re: Technical interview performance is kind of arbitrary

#114

Post by dmansen » Wed, Feb 17, 2016, 9:07 PM UTC

eropple wrote: post #48

maxaf wrote: post #29

Take home tests FTW. The thinking goes as follows: 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. 2. If the candidate does reasonably well by completing the code test somewhat on time (with a fat margin allowed for them, well, having a life) and within parameters of the task, they're invited…

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

Re: Technical interview performance is kind of arbitrary

#115

Post by marknutter » Wed, Feb 17, 2016, 9:08 PM UTC

grillvogel wrote: post #16

technical interviews are a joke. the majority of the time they exist so the interviewer can try to feel smart and subject the interviewee to whatever whimsical problem they found on the internet. how often do you do group coding in a whiteboard in your actual job? at one interview I was criticized for sitting and thinking about a problem for a minute without just blindly jumping into attempting to solve it. also tons…

I once was called into an emergency meeting by the CEO of the company I was working for the time. When I entered the room, all of the top brass were seated around the table, some visibly agitated. The CEO proceeded to hand me a single black whiteboard marker as he stated "the fate of the company depends on you". The problem was outlined by a fellow engineer and it was explained that I had 10 minutes to solve it, or we might risk going out of business.

With that, I took a deep breath and went to work furiously scribbling away on the board while everyone watched with anticipation. As I closed the final bracket, and stepped back to examine my work, audible gasps could be heard from around the room. The grizzled old CTO whom everyone was a little scared of broke the silence at last: "God dammit, Mark!" I caught a few nervous glances from some of the less technical folks. You could hear a pin drop when he continued:

"you just saved the god damn company!"

A slow clap started, and soon everyone joined in with a round of applause and cheering. Over the outburst of joy and adoration the CEO shouted to one of the developers who had gathered outside of the conference room, "get this code into production!" Soon the whiteboard was being whisked away by a group of smiling engineers as they navigated with great purpose through a sea of high fives and back slaps.

And then, with a twinkle in his eye, the CEO shook my hand, and pulled a crisp $100 bill out of his wallet. As he handed it to me, he said "I knew from the moment I heard about your interview that you would be a great asset to this company, Mark. Go home and relax for the rest of the day and take your wife out for dinner tonight. You've earned it."

So you see, being able to solve complicated problems on a whiteboard in a crunch time is a valuable skill.

Re: Technical interview performance is kind of arbitrary

#116

Post by nv-vn » Wed, Feb 17, 2016, 9:09 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.

I think his point is more that someone who's been exposed to a language for years but isn't interested is going to pay off much less in the long run than someone who's using it for the first time but enjoys learning. The reason he mentioned a few weeks of training for the language meant that they would be able to start making changes within a few weeks and be making major contributions by a few months. The fact that their first month or so may be relatively unproductive is less of a concern if they're constantly getting better and better. That said, a few weeks of training plus exposure to a large codebase in a language should be enough for even the short term unless they're trying to learn a whole new paradigm or some huge frameworks/libraries.

Re: Technical interview performance is kind of arbitrary

#117

Post by infinite8s » Wed, Feb 17, 2016, 9:17 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…

> I've met plenty of experienced engineers who still write bad code and design systems poorly. It has no correlation to how much of a tinkerer and curious person they are, in my experience.

Can they really be considered experienced then? Or are they basically just people who are first year engineers repeated for 5, 10, 15, etc years.

Re: Technical interview performance is kind of arbitrary

#118

Post by [deleted] » Wed, Feb 17, 2016, 9:17 PM UTC

[deleted]

Re: Technical interview performance is kind of arbitrary

#119

Post by bsder » Wed, Feb 17, 2016, 9:18 PM UTC

muddyrivers wrote: post #61

jessedhillon wrote: post #25

Earlier quoted context omitted.

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…

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.

I just ask them to bring code, and tell them we're going to talk about it.

It doesn't have to be their own (it normally is though). It doesn't have to be good code (nobody has yet brought bad code, but I wouldn't really care).

I would rather talk to somebody in their own code and language. If they can't explain it to me, then that's a data point, too.

Re: Technical interview performance is kind of arbitrary

#120

Post by dms105 » Wed, Feb 17, 2016, 9:19 PM UTC

jchendy wrote: post #70

dudul wrote: post #41

Earlier quoted context omitted.

More complex than practicing medicine? Or law?

I'm not a doctor, but from the outside, it seems that practicing medicine is mostly about memorizing a whole bunch of things and then doing them correctly over and over again. Law actually seems quite similar to programming. You can think of the jury as your users and facts/precedent/laws as the statements available in your programming language. Then your job is to assemble the statements into a program that compiles…

I like the law/programming analogy, but theres probably more of a margin for error when your job is to convince some people, depending on if you're prosecuting or defending. If you make even a small mistake when programming, it could break your entire program.