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

171–180 of 554 posts

Re: I will not do a tech interview

#171

Post by dragonwriter »

MartinCron wrote: post #107
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 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.

Re: I will not do a tech interview

#172

Post by com2kid »

joyeuse6701 wrote: post #10
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…

I suppose if you're a network engineer http/udp/tcp is necessary to know maybe off hand but not really, http isn't even in the same network layer so I'd find it strange to even ask about the 'difference'. UDP and TCP differences are more or less a well known question but even then I've had some ask the question expecting the most basic of differences and others with the minutiae. btree index is also something that ca…

Actually UDP and TCP are the prototypical examples of a reliable versus an unreliable protocol.

Being familiar with protocol design is important no matter what type of programming one is doing, the ideas of ACKs, NACKs, and flow control pop up all over the place!

Re: I will not do a tech interview

#173

Post by VladRussian2 »

lfuller wrote: post #119
VladRussian2 wrote: post #63

Earlier quoted context omitted.

>Programming interviews seem incredibly confrontational compared to my current profession. Interviewers seem to be out to trick you at something, or else to prove how much smarter they are than you. well, welcome to software engineering. The interviews are for the reason, they let you peek into your future job. If you can't manage that environment for 4 hours of the interviews, how you're expecting to manage it for m…

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 short-term stress, while the latter ones are better at long/deep concentration on a task.

My point is about interview situation being preview to a lot [not all, yet a lot and many of them will be key ones] of future situations.

Re: I will not do a tech interview

#174

Post by dirk94018 »

Those European university tests copied by Google, then copied by SV startups, mostly deliver two things, making the interviewer feel superior and filtering for submissive coders.

All managers dream of robots that can read minds and work for titles but lazy managers prefer to hire those who do what they are told, even if its pointless, even when done poorly or without imagination.

A good manager is worth his weight in gold. "I will not do your tech interview" while offering a short contract is an excellent way to screen out the lazy managers.

Re: I will not do a tech interview

#175

Post by untog »

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…

The thing is, if you've done this HTML -> CSS conversion a hundred times before, you wouldn't need to look it up. They're trying to gauge your experience level

That really doesn't make sense, though. They were gauging my experience level by forcing me into a development process I have never used before?

I don't think the best way to test if a person can do X is to take them far, far out of the environment in which they've always done X, and would be doing X if hired by you.

Re: I will not do a tech interview

#176

Post by Fishkins »

imsofuture wrote: post #149
btilly wrote: post #85

Earlier quoted context omitted.

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…

Sorry, but a negative reinforcement cycle of tensing up in a medium stress situation is exactly the kind of characteristic that I'm trying to screen out in an interview. Stressful situations happen a lot more than never in the real world (and sometimes they even involve talking to people, like customers) -- I don't want to have coworkers who can't handle that.

For me, the interview has always been way more stressful than anything I've had to do on the job. I think lots of people feel the same way (partially based on what I've seen performing interviews myself).

Re: I will not do a tech interview

#177

Post by untog »

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…

Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job.

Not really. A job interview is your one single chance to make a good enough impression to get the job. You could freeze up in a meeting and it would be fine, if the rest of your performance is on par.

One meeting in a job is a very tiny part of your overall employment. An interview is the one and only impression you get to make.

(For further reading, please consult the lyrics to Eminem's "Lose Yourself". Mom's spaghetti.)

Re: I will not do a tech interview

#178

Post by bobbbinsIII »

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.

how often does a normal software developer find himself in a situation where he has to know about B-Trees in depth?

Re: I will not do a tech interview

#179

Post by Cakez0r »

potatolicious wrote: post #121
maxk42 wrote: post #100

Earlier quoted context omitted.

Just replying to state my shock at how many people are defending poor interview performance. If you freeze up during interviews because it's "high stress" then maybe you need to practice going on more interviews until it doesn't bug you any more. When you're a developer -- especially at a senior level -- you need to be able to work well under stress. Hell -- you need to be able to do that for nearly any job in the wo…

This seems false to me. Interview stress isn't deadline stress isn't code review stress. This is like saying "all drivers need to be able to drive well under stress, so let's test them while blaring a foghorn in their ear". Context is important. I don't want to hire someone who is good at interviewing, I want to hire someone who is good at what I need them to do. While it may behoove the individual to train themselve…

all drivers need to be able to drive well under stress

But wouldn't you say a driving test is to driving as a technical interview is to a development role?

Re: I will not do a tech interview

#180

Post by brianmcconnell »

I've never liked the tech interview format. Throughout my career I've run four different companies, all small, all resource constrained, so I never had the luxury of competing for the A+ talent.

I ask people for a list of projects that they designed and coded (live projects, so I can see how they function), to get a sense for how good they are overall, then will look at the underlying code. I value readability and documentation over fancy tricks meant to show off the author's MENSA status.

When it comes to the interview, that's all about assessing their personality, work habits, and broader interests. Friendly personality, good work ethic and broader interests = someone who is flexible, which is vital in a small company where everyone has to do a bit of everything.

Post reply on HN