Live data from Hacker News

Interviewing in Silicon Valley

symbo1ics.com

81–90 of 117 posts

Re: Interviewing in Silicon Valley

#81
Let me posit a couple things to my fellow interviewing engineers here:

1) I like to ask questions during interviews. I hate the whole "I'm a brilliant guy charade." I'm not. You're not. Einstein was. Deal with it.

2) And I especially don't have a care for rote memorization bullshit for things I can look up in less time than it would take me to remember. I'm a thinker, not a fucking textbook.

So, if you said to me "do whatever using x algorithm", and I said to you, "I don't know x algorithm by heart; could you tell me what it is, and I'll implement it in one of the languages I'm proficient in?" would that just completely turn you off to me as a candidate?

Re: Interviewing in Silicon Valley

#82
From reading the post, my takeaway is a guy who's probably going to struggle for awhile to find a position. When an engineer says that they only care about the technology and not the product, that would set off my red flags immediately. Frankly, in 99% of the cases, it's the product that pays the bills including the salaries of the team. If I had interviewed him, I probably would have suggested he look for a position in a R&D group in a large company with the funds to do that sort of software engineering.

I find many of the interview puzzles that people have posted on the Web that they've encountered at the Big Name companies as often a bit silly. Having said that, asking software developers to implement a solution to a common programming problem - "navigating a tree using recursion", etc. is perfectly reasonable. I've found more than a few software devs who have great looking resumes but who have no idea what recursion is, what a tree is used for as a data structure, etc. And I consider this the basic, easy, 1st year undergrad type stuff.

If there's an undercurrent to all of the comments here, it's that we still don't really have a good way to sift through the good from the really-not-so-good developers quickly. The programming tests and puzzles are a proxy for this and they only work so far - some people like to think through issues more before coding, or tend to freeze under this on-the-spot pressure. Doesn't mean that they aren't a good, competent developer you'd want on your team; my experience is that the guys who blurt out very quick answers can sometimes write the worst code.

Re: Interviewing in Silicon Valley

#83

I've been interviewing a lot of candidates over the last couple of months and I also despise trivia question interviews. The approach I've been taking is using a FizzBuzz type of question, but a bit more complex. I couldn't believe the number of candidates that have trouble with things like manipulating two arrays, which I feel is a basic level of expectation for a programmer. If I spend all hour on this relatively s…

I code all day. I don't have a whiteboard, I don't use a whiteboard. I can expect whiteboard-questions but that doesn't help anything. Am I supposed to practice them? Why can't you be happy just giving me a laptop, or a pad and paper, or something I'm used to?

Re: Interviewing in Silicon Valley

#84
post #65

Earlier quoted context omitted.

If they request I spell out the naive solution, I certainly oblige. But if it's clear to both the interviewer and me that they are looking for that particular solution, then I won't spend time writing it out. So far, this approach of assuming they want the best solution—while acknowledging the simple solution exists along with a brief sketch of it—seems to be agreeable.

Your posts leads us to believe that this is in fact, not agreeable.

Why's that? I've used that technique in places from which I've received offers (from small non-profits to large multi-billion corps). I think it's a realistic thing to do. If they want me to code the naive way, they can just say so. If they want a better solution, and I sketch out verbally the naive solution and they're happy, why magnify into it?

The non-agreeable part is the difficulty with finding a better solution, and spending inordinate amounts of time searching for one.

Re: Interviewing in Silicon Valley

#85
post #83

I've been interviewing a lot of candidates over the last couple of months and I also despise trivia question interviews. The approach I've been taking is using a FizzBuzz type of question, but a bit more complex. I couldn't believe the number of candidates that have trouble with things like manipulating two arrays, which I feel is a basic level of expectation for a programmer. If I spend all hour on this relatively s…

I code all day. I don't have a whiteboard, I don't use a whiteboard. I can expect whiteboard-questions but that doesn't help anything. Am I supposed to practice them? Why can't you be happy just giving me a laptop, or a pad and paper, or something I'm used to?

All of the above is fine with me. It doesn't have to be a whiteboard, it's just the term that I use to coding on the spot, which admittedly probably isn't accurate. When I interviewed at my current company, I did everything on a pad of paper.

Re: Interviewing in Silicon Valley

#86
"Don’t sell me your product, sell me your challenges"

I actually care about the product equally if not more than the engineering challenges. I write code to build products and businesses, not for the sake of engineering. I'm a bit different though :)

Re: Interviewing in Silicon Valley

#87
post #83

I've been interviewing a lot of candidates over the last couple of months and I also despise trivia question interviews. The approach I've been taking is using a FizzBuzz type of question, but a bit more complex. I couldn't believe the number of candidates that have trouble with things like manipulating two arrays, which I feel is a basic level of expectation for a programmer. If I spend all hour on this relatively s…

I code all day. I don't have a whiteboard, I don't use a whiteboard. I can expect whiteboard-questions but that doesn't help anything. Am I supposed to practice them? Why can't you be happy just giving me a laptop, or a pad and paper, or something I'm used to?

I can code on a whiteboard, but it's certainly not something I enjoy. So when interviewing, I often ask for pen and paper. Just like a whiteboard, I have to write code without a computer and IDE, but unlike a whiteboard, I don't have to stand and write code in a position I'm not used to, with a tool I'm not used to (and let's be honest, whiteboard markers are kind of a pain to write with).

If I'm going to be disqualified based on my choice of writing medium, well, I probably wouldn't be that keen on working there anyway.

Re: Interviewing in Silicon Valley

#89
post #51

I agree with this article that communication with companies is getting absurdly poor. With all these communications channels available, why is it so hard to send a quick email? Don't have time because of too many candidates? Maybe you shouldn't have more candidates than you have time to handle. I've reached a point in my career where I'm not interested in engineering positions anymore (a great motivator has been to a…

I like to partition companies with products that gain traction into two groups. In the first group are technically mediodcre founders who cobbled together a product that's almost unmaintainable. The second group consists of relatively experienced founders who cobbled together a product that's maintainable. The two groups use distinct interview styles. Since the group with nearly unmaintainable code has many more memb…

> The quality to seek in employees is perseverance and obedience. And this familiar interview style tests for just that.

I know some actual interviewers who ask these types of CS heavy, puzzle based, brainteaser type of questions. They say that their rationale for asking questions like this is to gauge the candidate's attitude and to see how they behaviorally respond when presented with this kind of problems. In many ways, they are testing for submission in candidates. Basically, if you up and leave when asked how many manhole covers there are in New York, their system worked perfectly: they weeded out a candidate who they think would be an entitled prima donna. Corporate environments often require foot soldiers who will do the job without complaining, hence the testing for absolute obedience.

I disagree with this tactic but unfortunately it is quite widely employed during the selection process.

Re: Interviewing in Silicon Valley

#90
post #18

I despise interviewing for software positions. Engineers love to treat interviews like some kind of hazing. They're gonna make you quiver and sweat and if you can still solve their stupid brainteaser maybe they'll give you the honor of working with them. Problem being, this has basically nothing to do with how good you'll be at the job. I spend 0% of a normal day with someone I don't know staring me down and judging…

I'm a software developer. By far the best interview I've had in the past few years was with a very small startup in NYC with some cool tech. We had a fairly extensive and relatively detailed tech interview over the phone that included mostly general questions like explaining how DNS lookups work. They then gave me a fun, throw-away programming project to do offline in a day or so that utilized their preferred stack, and they PAID ME with for it with a $150 Amazon gift card. I can't tell you how many bonus points they earned with me, both for the enjoyable, puzzle-free interview and for signalling that they understood that my time had value. I was ultimately told that they had "changed direction" and weren't going to hire at all, and I have no reason not to believe them. I don't feel like my investment in time with them was wasted or that I was insulted/abused in any way, quite the opposite and that was refreshing.
Post reply on HN