Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical interview performance is kind of arbitrary

blog.interviewing.io

Post reply on HN
Print view View original

131–140 of 246 posts

Re: Technical interview performance is kind of arbitrary

#131

Post by deangiberson »

bsder wrote: post #124
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.

> 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. Careful. You probably need to define your terms more clearly. A CS student who knows Java (4+ years of experience) is going to turn out very different programs from a 20 year veteran of Erlang who is just learning Java. Even with bad Jav…

"Even with bad Java idioms, the veteran is very likely to be turning out much better code because he is thinking about the underlying architectural issues (failure modes, recovery, concurrency) with far more experience."

Careful with that assumption. While there may be instances where this is true, I've met many veterans that couldn't think outside the small specialty they had become locked into.

Idioms are powerful in that the shape how you think about a solution within a fixed language. They shape your thinking and the shape of your thinking changes what solutions you can conceive of. A veteran that shows interest in a broad range of topics will have more failure experience and will be able to offer better results.

Re: Technical interview performance is kind of arbitrary

#132

Post by FLUX-YOU »

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…

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

It still takes a village to get to this point, which means even in the best case, we're all going to contribute some shitty code to the world because that's just the learning curve.

You can, of course, go a long time without peer review or having ever been shown a better way to do the stuff you just did.

Re: Technical interview performance is kind of arbitrary

#133

Post by agentgt »

I haven't interviewed in some time but one thing I absolutely hate about technical interviews is "white board" coding.

For some reason white boards intimidate me. I have terrible penmanship and complete lack of planning how much space I need for writing things. Then there is the fact the markers seem to have a hi failure rate when ever I use them.

Perhaps I'm the only one that feels that way. I have even begged some interviewers that I would prefer them just watching me use a laptop but the offer is typically refused. Maybe things have changed now?

Re: Technical interview performance is kind of arbitrary

#134

Post by Gratsby »

Technical interviews are silly exercises IMO. You have a multi-month ramp up period and you have all kinds of environment specific things to deal with at just about every employer. Nobody in real life gets asked to program on stage or forced to answer esoteric questions as if your in some sort of math competition.

If you don't have confidence in someone's ability based on their experience and their interview but you did like them, give them a task to accomplish offline. See if their results are anything like your results would be, and bring them in to see how they respond to feedback both negative and positive.

I've seen too many interviews that go along the lines of "How would you rate your Java on a scale of 1-5?" "5" "So how would you fix the problem if your cache hit rate on SomeObscureCommercialProduct went from 94% to 82%?" "Forget that guy. Huge ego. Doesn't know anything."

I did run into one company that had an interesting process for technical validation. They actually hire people for two weeks as contractors and have them work with the team. Then they hold a vote and decide whether to extend an offer.

Re: Technical interview performance is kind of arbitrary

#135

Post by grillvogel »

dms105 wrote: post #120
jchendy wrote: post #70

Earlier quoted context omitted.

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.

if you make one "small mistake" while lawyering an innocent person might get sentenced to death.

why do so many programmers think their job is inherently more special and difficult than everyone else's?

Re: Technical interview performance is kind of arbitrary

#136

Post by splintercell »

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

I have been reading a quora answer about why most of the developers fail FizzBuzz test and the author differentiates between Programming and Engineering and he says that programming is aimed at making the machine work, where as engineering is more about the artistic aspect of building software (which is highly dependent upon experience and tenacity to get the job done). That people wanna hire Engineers, but they test for Programmers.

This got me thinking about a common pattern I have been observing. Most of the algorithms I implement in a real world code are very basic. Most of the work I do, revolves around the fact that my code should be easily understandable to other people (and sophisticated algorithms prevent that), that people should be easily be able to modify it, repurpose it or expand it

In real world, if I ever was asked to implement FizzBuzz, I wouldn't even open my editor until I understood what is it going to be used for, what future features it will have, and what existing code will it work with. Once I understand it all, I might never write the code which most people write (or I myself write) during a fizzbuzz interview.

Maybe it's time to create a Software engineering fizz buzz rather than programming fizzbuzz.

Re: Technical interview performance is kind of arbitrary

#137

Post by darryl42 »

rm_-rf_slash wrote: post #102
superuser2 wrote: post #90

Earlier quoted context omitted.

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.

Most jobs at tech companies will have a clause in your contract about owning everything that you do or think of while employed.

Re: Technical interview performance is kind of arbitrary

#138

Post by mirceal »

3 things I search for:

Fundamentals: CS basics. I don't nitpick on details. It's more around if you've heard about it or not and if you could figure out how and when to use it.

Structure: I want to see a structured approach to problem solving. Doesn't matter if your code is perfect. Doesn't matter the programming language you want to use.

Curiosity: You need to be curios about things. Asking the "why".

Re: Technical interview performance is kind of arbitrary

#139

Post by georgemcbay »

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 don't disagree with the idea that becoming truly skilled in a language is more than a couple of weeks of work even for a great programmer, but more often than not you don't quite need that caliber of work from them right away.

Most job fills aren't going to be putting the new employee in charge of "greenfielding" the architecture of a brand new app, they'll be doing maintenance or build-out of an existing codebase, giving them plenty of time to ramp up on the fine details of a language while still being productive working with the existing code.

Re: Technical interview performance is kind of arbitrary

#140

Post by maxaf »

darryl42 wrote: post #137
rm_-rf_slash wrote: post #102

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.

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.
Post reply on HN