Earlier quoted context omitted.
It's expensive in other ways though. A programmers who is currently employed but thinking about moving on probably won't agree to a two-week trial period because of the substantial risk that they get rejected afterwards and end up unemployed. That makes the trial period expensive to him . In turn, it makes it expensive to the employer as well, because you'll filter out good people.
Can they not do this two-week project after hours? Must it be in your office, on your schedule? Where you code, the hours you code, these do not matter. The code is what matters.
I will not do a tech interview
301–310 of 554 posts
Re: I will not do a tech interview
#302Earlier 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.
Re: I will not do a tech interview
#303Granted, 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 primary filter for me these days is the pair programming interview. Can they make something? Do they think clearly about what they're making? Do they ask good questions? Can they explain why they did something, and what other options are?
Re: I will not do a tech interview
#304Earlier quoted context omitted.
> I don't want my employees to have to learn everything just-in-time What about just some things . And in most cases, it's not learning for the first time but brushing up on the topic. To expect people to have encyclopedic knowledge of every edge-case problem your company deals with on a day-to-day basis is ridiculous.
As OP said, you would not be able to google the specific B-Tree question because if you don't know about B-Trees you wouldn't know that you need to google it. There's a difference between things you know you don't know (and therefore can google), and things you don't know you don't know (and therefore will not google).
Re: I will not do a tech interview
#305Earlier 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.
A client meeting, code review, or dispute with a manager can be stressful, but you can answer from a position of strength. You know your code, have reasons for your decisions, and have met some standard to get the job. Interviews may be less demanding, but for some people it's a huge problem that there's no solid place to stand.
Re: I will not do a tech interview
#306this is a very good idea. i've had multiple interviews where i did well on the phone and the tech-out, only to receive a "take home exercise".. with guidelines such as "it will be graded by style and architecture in addition to correctness of function". This would mean half of my saturday in a coffee shop coding an elaborate solution using latest technology and good patterns.. with some resentment because i just wast…
Same thing. I got an open ended problem that would take a measure of forever to solve: Specifically to write a program (in your favorite language!) that would do natural language processing and discern emotions and feelings about subjects from text. We were supposed to include our own lexical parser. The author's strategy scales poorly with complex and interlocking problems. Where it is more important to show potenti…
I know of a YC alumni company that asks for a weekend project on roughly that level and when rejected candidates ask if they can upload their work to Github, the company declines because they'd "like to keep an even playing field for future candidates."
Then you're left with choosing between having an awesome project you can't show off and being an inconsiderate jerk who uploaded code despite being asked not to.
Doesn't really make one enthusiastic for the next time you're asked to do an "exercise" or a "project."
Re: I will not do a tech interview
#307Granted, 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…
I didn't prepare for this, but it allowed me to convey my engineering thought process and brag a little :) I really enjoyed it.
Re: I will not do a tech interview
#308Earlier 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 job interviews really that high-stakes? There are always more jobs for skilled tech people.
Re: I will not do a tech interview
#309Earlier quoted context omitted.
I'm curious, is this a money issue, i.e., you refuse because it feels like working for free? Or is it just a principal thing? I doesn't seem unreasonable to me to ask even a senior developer to do a small coding assignment as part of the interview process unless they can show a good, relevant coding sample. If we're going to agree that whiteboard coding isn't a great way to evaluate someone, and we can't ask you to d…
I'm curious, is this a money issue, i.e., you refuse because it feels like working for free? Not OP, but it doesn't "feel" like working for free. It is working for free. Having someone perform work for you without paying them is illegal in the United States (see minimum wage laws). There's a simple solution; pay them $x per hour to do your 3 hours of work. Even if you pay them $100 per hour that's a cheap way of filt…
Re: I will not do a tech interview
#310On-site interviews are a necessary for the most part, but phone screens have always been the bane of my existence. About 50% of the time I can barely understand what the other person is saying, mostly because the person conducting the interviewer is not a native English speaker. I almost never have an issue in person with non-native English speakers because you're able to pick up so much more context from subtle phys…