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

I will not do a tech interview

medium.com

Post reply on HN
Print view View original

331–340 of 554 posts

Re: I will not do a tech interview

#331

Post by bmj »

Bartweiss wrote: post #312
bmj wrote: post #110

Earlier quoted context omitted.

Doing contract work via take home seems like a nice balance here as even people with kids have 2-3 hours free after kids go to bed. Done over a few nights in a week makes much more sense. Initially, I was going to react negatively to this (as a father of two kids under the age of 11), but the more I think I about it, the more I like it. I assume that if I was scheduled for a technical interview, I'd likely spend at l…

For me this part about preparation is the hidden value of this approach. For most interviewees the interview isn't a 2 hour process, it's far more time spent in potentially-irrelevant preparation. It seems like companies might as well turn that time into a more direct skills evaluation.

And, if I'm reading you correctly, it may end up being a benefit to the interviewee, too. At the end of the process, whether I got the job or not, I have additional "implemented X in Y" experience.

Re: I will not do a tech interview

#332

Post by toomuchtodo »

bqe wrote: post #130
toomuchtodo wrote: post #19

Earlier quoted context omitted.

I hire people based on their ability to learn, not what they know. If you're asking interview questions that can be googled in 20-30 seconds, you're wasting your time and theirs.

Basic computer science knowledge (and yes, B-Trees qualifies) cannot be learned in 20 seconds. Most of this knowledge is actually a prerequisite to being able to search Google properly.

Fair point. I was unfamiliar with B-Trees because most of my time is spent as DevOps/Networking/Sysadmin. It took me 15 minutes to learn and understand what they are and how they work.

http://slady.net/java/bt/view.php?w=800&h=600 http://en.wikipedia.org/wiki/B-tree http://en.wikipedia.org/wiki/B%2B_tree http://guide.couchdb.org/draft/btree.html

Now if you make understanding B-trees a prerequisite for the job, I can at least learn it ahead of time for the position.

Re: I will not do a tech interview

#333

Post by tonyarkles »

jimmaswell wrote: post #322
bigtunacan wrote: post #236

Earlier quoted context omitted.

You have to look at the candidate's overall performance in the interview; not the answer to a single question. Describing a closure is actually a great example of something many great software developers WON'T know based upon their prior domain experience. A strong Java or old school C/C++ programmer (yes I know C++11 has closures) may actually be an excellent candidate, but have no idea what a closure is. I would ex…

I can get anything I need to done in JS and I have no idea what a closure is. I've even written an emulator in it. Took me a little while reading to figure out what it is. Apparently it's just using vatiables in a lambda that are from a scope higher than it. I do that all the time, I just didn't know it had a special name. To be fair, I didn't know JS could do lambdas. I've only used them in C# and possibly Python. W…

You've never passed a callback to a JS function?

Re: I will not do a tech interview

#335

Post by chaostheory »

acuozzo wrote: post #118
chaostheory wrote: post #50

Earlier quoted context omitted.

Well then how am I going to figure out whether or not you can code? The only thing I can think of is an expensive two week trial period which doesn't make sense since I feel that most programmers will either submit work or submit to a pop quiz.

> Well then how am I going to figure out whether or not you can code? Provide the candidate with a PC representative of what you'd give to him/her during the course of his/her's employment and assign an ~one-hour-long programming assignment to complete while you sit nearby. If the candidate needs a particular program (e.g., "I don't like Vim. I prefer to write my code in VILE!"), then give it to 'em.

This is still another variant of the pop quiz... but a better one.

Re: I will not do a tech interview

#336

Post by RyanZAG »

dragonwriter wrote: post #251
RyanZAG wrote: post #242

Earlier quoted context omitted.

Ah okay, good, that's a more reasonable discussion then. So you're basically saying that a meeting could fail to create value because an employee made mistakes in the meeting as he could not handle the stress. The correct way to solve this for everyone involved is to reduce the amount of stress everyone is under in a meeting and to create an environment conducive to problem solving. This isn't really that hard, a wel…

> The correct way to solve this for everyone involved is to reduce the amount of stress everyone is under in a meeting and to create an environment conducive to problem solving. Sure, you can mitigate this to some extent, but you can't reliably avoid having high-stakes situations which you need a meetings which are inevitably going to be high-stakes to address, or that senior developers won't be to a certain degree o…

"you can't reliably avoid having high-stakes situations which you need a meetings which are inevitably going to be high-stakes to address, or that senior developers won't be to a certain degree on the spot in those meetings."

Sure you can. You can send out the problem before the meeting so the developer can think through the issue and make notes before he is put on the spot. You can also help the developer during the meeting by simply making the meeting positive instead of negative.

"You don't always have the luxury of making decisions in the way you'd prefer without paying a cost."

Snap decisions are often bad decisions. If you need to make a very important decision in a hurry it means someone already made a mistake in not considering this issue earlier. That happens, but you need to realize that the resulting decision is highly unlikely to be a good decision, let alone optimal. A mark of a good team is being able to avoid these kind of situations through research and planning.

Again, I'll go back to the same point: if you have created an atmosphere in a meeting that is causing people to freeze up due to high stress, you need to fix your meetings. There is something very wrong.

Re: I will not do a tech interview

#337

Post by chaostheory »

toomuchtodo wrote: post #77
chaostheory wrote: post #50

Earlier quoted context omitted.

Well then how am I going to figure out whether or not you can code? The only thing I can think of is an expensive two week trial period which doesn't make sense since I feel that most programmers will either submit work or submit to a pop quiz.

Good developers cost, what, $120K-150K/year? If a two week trial period is "expensive" to you, you don't have the budget for someone in that pay range.

Time is an expensive resource for even teams in large corporations. Most often you'll be spending a week or two going over the context and rationale of existing stuff. This gets worse the larger and older the company.

Re: I will not do a tech interview

#338

Post by tiglionabbit »

tmoertel wrote: post #240
untog wrote: post #72

Earlier quoted context omitted.

Maybe somebody can explain this better to me -- but if you freeze up in interviews, are you also going to freeze up in developer meetings? During code reviews? When you're in the room with clients? Of course not. Interview situations are very, very different than the others. Meetings and code reviews are with co-workers, whom you know and trust. Meetings with clients could be nerve-wracking for other reasons, but the…

Can I offer you some advice? An interview is a negotiation. The rules aren't fixed. If you're asked to do something that won't give a reliable measurement of your ability, say so and offer the interviewer a better option. You'll probably get what you want. In the scenario you described, I might try something like this: "I think I see what you're trying to measure by asking that question, but it assumes a working styl…

I've tried that. The response is always, "This is how we do our interviews. If we changed it for you, it would be hard to compare you to our other applicants".

Re: I will not do a tech interview

#339

Post by ansible »

jnbiche wrote: post #48
TeeWEE wrote: post #4

Well, I need to interview candidates because I need to know if they are up for the job when systems breaks. If a table query fails because it needs a btree index due to range searches, I want the candidate to know how a btree index works and why it fixes the issue. Also If somebody cant tell me the difference between http udp and tcp, its a no hire for me. So for me, I really want to interview somebody before he can…

Can you not understand that there might be people who can complete your task easily, yet who have extreme anxiety about interviews? I actually understand this issue -- I've been trying to switch careers into programming for the past year. I've know several languages well (Python, JavaScript, some C), can use git, and have a few decently impressive projects on my Github profile. I also contribute to a pretty well-know…

Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you.

I'm sure there is a lot of that out there, but that is definitely not my reason for asking hard questions.

We will always be interviewing at least a few people to fill a position, I think that's natural. Suppose I ask you and the other candidates questions... and you all get them all right. Well, that's fabulous, but now I have no way to distinguish which of you actually knows more about a particular subject.

And I think it would be stupid for me to ask the interviewees to answer questions to which I don't know the answers.

So we're always going to be in a situation where I'm asking you at least some questions that you don't have the answers for. I need to test your limits, and see how firm a grasp you have on various subjects.

Re: I will not do a tech interview

#340

Post by alpha001 »

geebee wrote: post #150

One good thing about reading/browsing HN is that you can get an impression of the ideas that are starting to emerge. One thing that seems to be emerging now is that people are rethinking the grueling technical interview process. There was a huge emphasis on avoiding false positives in the interview process - largely because a single bad hire can do great damage to a software development team. But people seem to be le…

For which kind of position one gets asked markov chains, primal-dual and alike math things in the programming interview?
Post reply on HN