I will not do a tech interview • Hacker News Board

Re: I will not do a tech interview

#191

Post by nollidge » Wed, Aug 21, 2013, 6:06 PM UTC

blah32497 wrote: post #164

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…

I guess it depends on the industry/clientèle, but meetings are fundamentally very similar. You are worried about what "they" will ask and if you will be able to answer the questions. With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles. In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have…

I guess it depends what you want to test. I've not once done the task untog described, but if you sat me in front of an Internet-connected PC with an editor and browser, I'm pretty sure I could do it in ~30 minutes or so. I sure as hell could not do it on a whiteboard.

So. What kind of skills are you looking for? Someone who's memorized a limited set of knowledge and can slap it on a whiteboard on demand, or someone who can get shit done? Not that they're mutually exclusive or even uncorrelated, but why test for a poor proxy of what you want instead of exactly what you want?

Re: I will not do a tech interview

#192

Post by ronaldx » Wed, Aug 21, 2013, 6:08 PM UTC

crazygringo wrote: post #62

Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…

Would you be kind enough to explain further why knowledge of closures is a priority...?

Re: I will not do a tech interview

#193

Post by SomeCallMeTim » Wed, Aug 21, 2013, 6:09 PM UTC

untog wrote: post #72

crazygringo wrote: post #62

Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…

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…

>Of course not. Interview situations are very, very different than the others.

Really? I disagree. There even exist situations (in the case of some positions) where you will be talking to a client of the company you're working for, effectively interviewing with the client, representing the company. And interviewing is a subset of "sales", which is important for working on many teams -- including selling management on changes that would improve the user experience, for example.

>Meetings and code reviews are with co-workers, whom you know and trust.

Actually, when you first start out, you don't know them much more than you did when they were interviewing you. And honestly, I haven't always learned to trust my coworkers; or rather, some I've learned to not trust.

Regardless, this sounds like a psychological limitation on the side of the interviewee. Which is something you can work to improve.

Disclaimer: I've always been good at interviews. At least good enough that I have a more than 50% job offer rate for interviews I've gone to.

>For my own personal example, I once interviewed at a place where the interviewer wrote up some HTML on a whiteboard, and then asked me to write out the CSS next to it that would turn it into a horizontal drop down menu.

Not my domain, but yes, that sounds like a "parrot from memory something that you could copy-and-paste or build up trivially with a real coding environment," which I agree is not a great question, nor is it a good way to interview.

>I opted out of returning for the second round of interviews.

I think this is where you failed, though. If they asked you back, then even though you didn't feel good about the interview process, you must have passed. Their process is broken, so probably NO ONE was able to do everything perfectly.

>The next place I interviewed I sat down, in front of a computer, with the interviewer, and we talked through code as I wrote it. I took the job.

That's certainly a better interview process. But you do realize that you filtered out a company for having a less-than-optimal interview process? Seems like a poor choice of filter, in both directions.

Re: I will not do a tech interview

#194

Post by lfuller » Wed, Aug 21, 2013, 6:10 PM UTC

VladRussian2 wrote: post #173

lfuller wrote: post #119

Earlier quoted context omitted.

I realize that it can be hard to understand without having experienced interview anxiety yourself, but it is an entirely different environment. I suffer from interview anxiety to the same extent as the author of this blog post. Though I am a very skilled developer, I completely freeze in these situations (I even failed a fizz buzz test once). This doesn't translate to difficulty with on-the-job stressful situations h…

>I realize that it can be hard to understand without having experienced interview anxiety yourself, but it is an entirely different environment. my point isn't about denying interview anxiety existence (i suffer from it myself), and it has solid science foundation - speed of dopamine removal once your system is flushed with it. Some people have it faster, some slower. The former ones are great performers in acute sho…

I understand where you're coming from, but I disagree that this is a matter of individuals' responses to stress in general. I know that in my case there is nothing else I have ever experienced that can trigger a stress response equivalent or even similar to what I experience during an interview. It is irrational, but it is entirely separate to anything I could experience through professional work. It is not the questions being asked during the interview that cause anxiety, it is the interview itself. I actually find that I work quite well under high-stress and high-stakes work environments.

Re: I will not do a tech interview

#195

Post by ronaldx » Wed, Aug 21, 2013, 6:11 PM UTC

dragonwriter wrote: post #171

MartinCron wrote: post #107

Earlier quoted context omitted.

if you freeze up in interviews, are you also going to freeze up in developer meetings? Are you really saying that your developer meetings are as high-stakes as job interviews?

> Are you really saying that your developer meetings are as high-stakes as job interviews? Most certainly aren't, but some are potentially higher stakes ( especially with smaller companies), since you and coworkers losing jobs you have -- which can be the price of getting things wrong -- is a bigger stake than you not getting a job that you currently don't have.

Possibly, a senior front-end developer shouldn't be exclusively responsible for those higher stakes meetings?

Re: I will not do a tech interview

#196

Post by _delirium » Wed, Aug 21, 2013, 6:12 PM UTC

crazygringo wrote: post #62

Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…

If you're looking for something very specific and the hiring is such that there's no time for a hire to get up to speed, vetting candidates to make sure they already have exactly the knowledge you need makes sense. But a lot of technical interviews are not really doing that. Google does not care about the specific knowledge they ask you about at interviews for the most part; they have so many Google-specific internal systems and processes you couldn't possibly have any experience with, that there is going to be some getting up to speed anyway. Instead, they're using the interview gauntlet as a proxy for something they're actually interested in, something vaguely like "technical skill".

Re: I will not do a tech interview

#197

Post by RougeFemme » Wed, Aug 21, 2013, 6:12 PM UTC

blah32497 wrote: post #164

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…

I guess it depends on the industry/clientèle, but meetings are fundamentally very similar. You are worried about what "they" will ask and if you will be able to answer the questions. With a client, it's about the software you're developing, with a interviewer, it's about software architecture or coding principles. In your example about HTML -> CSS I think you missed the point. It wasn't so much to check that you have…

My experience has been that with a client, the universe of potential questions is much smaller than the universe of potential questions in an interview. An interviewer can go almost anywhere. . .that's not usually the case with the client. As you said, the client is asking about the software you are developing, not - typically - details about how you would handle their business need in a different language or on a different platform. Or about textbook information you may have covered in a class a few years back and haven't used once since.

Re: I will not do a tech interview

#198

Post by geebee » Wed, Aug 21, 2013, 6:12 PM UTC

hvs wrote: post #7

tocomment wrote: post #6

Earlier quoted context omitted.

If only there were some way an employee could learn about btree's after taking a job...

I don't want my employees to have to learn everything just-in-time. By that logic, the people you hire wouldn't need to know anything. In addition, they don't know what they don't know, so they may not even know that they need a btree index.

What if they could explain what a b-tree is, and why they are useful, but that they'd have trouble implementing one on the spot. If they told you the name of a good book they know that has an explanation of b-trees. That they read the chapter a while ago, which is why they can generally explain what a b-tree is, and that that's where they'd go if b-trees came up and they needed to write/implement one?

I don't mean to imply that this wouldn't be acceptable to you. I do "know" that I've been screened out after giving an answer like this (to the extent that I can really know the reason, legally they aren't allowed to say).

Re: I will not do a tech interview

#199

Post by gregors » Wed, Aug 21, 2013, 6:13 PM UTC

btilly wrote: post #85

crazygringo wrote: post #62

Granted, there are a lot of bad tech interviews out there (asking about algorithms that nobody ever uses) ... but I do not understand this. Imagine someone's being hired for a front-end position, and we don't have months to get them up to speed. I'm going to ask them to explain how a closure works. How they deal with AJAX. What they think about "!important". Things to be careful about with floats. How CSS precedence/…

The problem is that interviews are high stress affairs. Stress produces adrenaline. One of adrenaline's known effects is to prepare us for "fight or flight", meaning that higher order logic is shut off, digestion is shut off, our senses sharpen, reactions improve. This is great when you've got to climb a tree to get away from a tiger. This is horrible if you are trying to demonstrate your ability to function mentally…

I've been meaning to read this http://www.amazon.com/Choke-Secrets-Brain-Reveal-Getting/dp/... hopefully got get some insight into my own "freezing up"

Re: I will not do a tech interview

#200

Post by tmoertel » Wed, Aug 21, 2013, 6:14 PM UTC

baddox wrote: post #167

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…

> Interview situations are very, very different than the others. How exactly? Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job. Sure, you'll get comfortable with your coworkers, and they'll get more forgiving of temporarily lapses, but I think most interviewers (for non-terrible jobs especially) purposefully give some extra leeway to interviewees, si…

The primary way in which interviews are different from after-the-hire social interactions is that interviews are high-stakes events, and the candidates know it. For some people, that knowledge is enough to put them into a self-reinforcing mental death spiral. Their fight-or-flight response takes over and they literally stop thinking as their bodies switch into survival mode.

That's why, when you're interviewing candidates, your first job is to get them to relax. Start out with small talk and softball questions until you sense them unwind. Then move slowly into the real questions.

When you get to the coding problems, again, start with dead-simple questions so that the candidates have the time to gain some confidence before the harder problems arrive.

The first programming problem I give – and this is after some small talk – is usually something like, "Print the odd integers between 1 and 100, in increasing order." This problem is so simple that it doesn't tell me anything about the candidate's ability, but that's okay. It helps to calm the candidates so that when I get to the problems I care about, I'll get better measurements.

That's the goal: To measure how the candidates actually perform, not to see whether they'll choke under interview stress.