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

441–450 of 554 posts

Re: I will not do a tech interview

#441

Post by chaostheory »

zura wrote: post #433
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.

You can figure out by discussing past experience, projects.

This is the easiest for people to fabricate and it makes it harder to discern good people from bad, especially when you can't actually look at the product of that experience.

Re: I will not do a tech interview

#442

Post by lsc »

SomeCallMeTim wrote: post #193
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…

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

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

If you are using the same interview process for technical folks and for sales folks, you are doing it wrong. (I mean, unless your technical folks are also sales folks, in which case, whoo boy. people who are good at both exist? but they are in high demand, and they are rare to begin with, so... good luck with that.)

Re: I will not do a tech interview

#443

Post by psuter »

jff wrote: post #429

Where I work, an interview is a full day thing. I'm pretty happy with how it works: After going through an initial resume screening and phone call, you show up on-site in the morning. You then give a presentation about some recent work you've done. For those fresh out of school, it's generally about their grad work. Then you have a series of 1/2 to 1 hour interviews through the day, mostly with people who were at you…

Where do you work, if you don't mind me asking? This sounds a lot like the interview process for research/academic positions; if you've made it to the interview day, there is really no reason to doubt your technical skills anymore, and the interview becomes more about finding out whether you would find your place and collaborators to work with.

Re: I will not do a tech interview

#444

Post by pjlegato »

nappy-doo wrote: post #421
thestoic wrote: post #374

Earlier quoted context omitted.

Ideally the time you spend writing code is both compensated and under a Work For Hire of the company trying you out. Your current employer owns the IP of whatever you do during work ours and using their equipment not what you do on your own time.

Not at Google.

At least in California, employers are statutorily prohibited from claiming rights to IP that was created on the employee's own time and using the employee's own equipment, and agreements that purport to waive this prohibition are void.

(CA Labor Code 2870-2872; http://www.leginfo.ca.gov/cgi-bin/displaycode?section=lab&gr...)

Re: I will not do a tech interview

#445

Post by jff »

psuter wrote: post #443
jff wrote: post #429

Where I work, an interview is a full day thing. I'm pretty happy with how it works: After going through an initial resume screening and phone call, you show up on-site in the morning. You then give a presentation about some recent work you've done. For those fresh out of school, it's generally about their grad work. Then you have a series of 1/2 to 1 hour interviews through the day, mostly with people who were at you…

Where do you work, if you don't mind me asking? This sounds a lot like the interview process for research/academic positions; if you've made it to the interview day, there is really no reason to doubt your technical skills anymore, and the interview becomes more about finding out whether you would find your place and collaborators to work with.

It's for research, specifically at an FFRDC. I don't believe there's any sort of "establish your technical skills" portion. My hiring process was a bit unique because I had already worked as an intern for 3 years, but as I understand it the usual process is 1) hiring manager finds the best resumes, 2) hiring manager does a phone interview with those people, and 3) hiring manager invites a few of the best prospects out.

The real technical skills part is the presentation. If you can give a good, 40 minute talk about what you've been working on, you've already put yourself in a good place.

Re: I will not do a tech interview

#446

Post by LordHumungous »

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…

It's not just a born talent thing. Practicing interviewing and solving problems on a board in front of someone can do a lot to help you get over that anxiety. Yet most people never bother to practice and then wonder why they are bad at it.

Re: I will not do a tech interview

#447

Post by jff »

sergiotapia wrote: post #430
jff wrote: post #429

Where I work, an interview is a full day thing. I'm pretty happy with how it works: After going through an initial resume screening and phone call, you show up on-site in the morning. You then give a presentation about some recent work you've done. For those fresh out of school, it's generally about their grad work. Then you have a series of 1/2 to 1 hour interviews through the day, mostly with people who were at you…

Sounds like a gigantic waste of time if you're applying somewhere other than Google, Facebook, or any of the "Big Tech Firms".

Well sure, smaller places might not even be able to muster enough people to do that many interviews. It ends up taking about as long as a Google interview, but it's not just debugging assembly on a whiteboard. We tour you around the site, talk about what you'd be able to work on, etc. The interviewers are selected from several different but related groups so you hear about a lot of different work going on.

One of the facts of research life is that you'll spend a good chunk of time talking to people and presenting your work--it's the price you pay for being able to choose what you work on. This interview process seems to help select for people who work well in that environment.

Re: I will not do a tech interview

#448

Post by digitalmaster »

zacinbusiness wrote: post #3

I've always been great at interviews. I'm naturally outgoing, love to talk tech, and really try to show, rather than tell, why I'm a good fit for any particular team or project. That said, I hate traditional interviews. I hate begging for a job, and I hate having to kiss ass to some manager who has no technical competence. I have been fortunate in that I've landed three awesome jobs so far in my life. Two were short-…

Couldnt have said it better myself.

Re: I will not do a tech interview

#449

Post by reeses »

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

What many candidates don't realize is that the hiring manager has probably gone through 1,000 or more resumes from recruiters or retained search agencies, phone screened 20-50, and interviewed 5-10 to fill one position.

"Pay me to contract on probation," sounds as if it's low risk for everyone, but it has stalled the pipeline for new candidates. It's not a reasonable request. If it were, then it would be a "contract-to-hire" position, and advertised as such.

I've walked candidates out because they've refused to whiteboard code. I'm very "hey, let's work out this problem together, and don't worry, I'm not going to compile the whiteboard, ha ha," so most people don't get too stressed out. If they do, that's where I step in and help them along, which is my job once they come on board as well, so they can get a feel for my style. It also helps separate the people with 10+ years of c, java, c#, and syntactically similar languages who can't differentiate between parens and braces, understand pointers, etc. The interview is where you can say,"would you do that differently if..." and see if the person has just had an interview brain fart or if they really don't know what they're talking about.

I've had a few candidates over the past 15 years or so that would just refuse to write any code. Certainly, I made the mistake of asking if they wanted to do some problem solving at the whiteboard, but I was flummoxed when the first guy (back at Amazon when interviewing at Amazon was perceived to be like interviewing at Google today) just said,"No."

And kept insisting. I'm a big believer in not wasting people's time, so I walked him out before he talked to the more senior people on the team, who were all working 24/7 to bring out (I think) auctions at the time. Looking back, it may not have been that big a waste of time. :-)

Post reply on HN