The urgency to interview, followed by the abrupt halt in communication isn't something that is unique to Silicon Valley or engineering positions. I had it a lot in London a couple of months ago for mostly product jobs. It's incredibly unprofessional / downright rude - especially when so much pressure is put on to get you through the interview process quickly. It also means that I now have a negative opinion of a numb…
Interviewing in Silicon Valley
41–50 of 117 posts
Re: Interviewing in Silicon Valley
#42Earlier quoted context omitted.
> Well, that's one problem right there. [...] Of course it depends. Getting the ball rolling is probably not best done by giving an NP-complete problem (subset sum) as a first exercise. When presented with an interview question, I usually say "well, it can be solved by doing $NAIVE_SOLUTION, just to get that out there, and I know you're looking for a better one." By doing this, I've established that there is a naive…
> "well, it can be solved by doing $NAIVE_SOLUTION, just to get that out there, and I know you're looking for a better one." I'm at the very beginning of my career, having just accepted a new grad position, but I thought I'd offer my opinion on this: just implement the naive solution. If you're really unsure, ask them if they're OK with you doing that. In my very first interview I took the approach you just described…
Honestly, when I interview and ask a question like this, it's a leading question. I want the simple solution as a FizzBuzz style test of your abilities, then I'm going to ask "and what problems can you see with this solution?" and we'll go from there.
Re: Interviewing in Silicon Valley
#43Earlier quoted context omitted.
> Well, that's one problem right there. [...] Of course it depends. Getting the ball rolling is probably not best done by giving an NP-complete problem (subset sum) as a first exercise. When presented with an interview question, I usually say "well, it can be solved by doing $NAIVE_SOLUTION, just to get that out there, and I know you're looking for a better one." By doing this, I've established that there is a naive…
> "well, it can be solved by doing $NAIVE_SOLUTION, just to get that out there, and I know you're looking for a better one." I'm at the very beginning of my career, having just accepted a new grad position, but I thought I'd offer my opinion on this: just implement the naive solution. If you're really unsure, ask them if they're OK with you doing that. In my very first interview I took the approach you just described…
Re: Interviewing in Silicon Valley
#44I have little interest in working for a company where I'm going to struggle to do the job. I'm not going to apply for a job where I'd be out of my depth for any more than a month or so, because that sort of "if I don't get better at this soon I'm going to be fired" sort of stress is horrible. I want to find a job where I can succeed right off the bat, learn new things and get better over time, and where I can see myself staying for several years at least. No one wants to be a job hopper; it's a symptom of poor interviewing on the interviewee's part.
From my point of view then, I know before I even get to the interview that I'm perfectly well suited for the company and can do the job - if I wasn't, I wouldn't have applied. So I approach interviews in reverse: I'm going to grill you, your team, the baristas in the nearest coffee shop, and anyone I can find on LinkedIn who's recently left. If you ask me stupid puzzle questions that have little to do with what I've come to understand the job entails, I'm going to take that as a sign that your company is less than functional in the interviewing arena, and I know from experience that that extends to the actual engineering too.
Interviewers seem to treat these types of questions as shit filters. I do exactly the same. If you ask them, that's a smell.
Re: Interviewing in Silicon Valley
#45It's far more illuminating, and a far better reflection of their worth as a candidate, than their ability to go off into a room somewhere and work through a problem alone. I'm much more interested in someone who thinks well than who codes well (since the latter can easily be trained).
Re: Interviewing in Silicon Valley
#46I 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…
Re: Interviewing in Silicon Valley
#47Well written piece that shows what to me is the SV recruiting paradox: there is a massive demand for programmers, yet companies make it really, really hard to get a job. It's easier to start your own company without the interview hassle and condescending attitude of some HR managers. I might be out on a limb here, but it seems it's almost easier to raise money for your startup than to get a job. Of course it gets a l…
>> yet companies make it really, really hard to get a job. It is much better to filter out some perfectly good candidates than accidentally hire the wrong candidate. The wrong hire can be very disruptive, and in some cases fatal for a company. Firing the wrong hire is very, very hard. >> but it seems it's almost easier to raise money for your startup than to get a job Raising money is like interviewing for three jobs…
The USA is at will and in the UK the first two years are effectively at will.
Re: Interviewing in Silicon Valley
#48Re: Interviewing in Silicon Valley
#49I 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…
First off it's a sign of commitment from the candidate : as small as the project can be, it will require on his/her part to invest more hours than the one/two of a live technical interview.
Second, it's much closer to what your real job will entail : being given a task, committing to deliver on a definite deadline, and doing it using whatever tools and sources of information you are more comfortable with.
A live interview should still be the final step, but in this case the candidate should defend and discuss how the project was realized, possible improvements and problems : this way the company should be able to confirm that the project was actually done by the person being interviewed as well as judging his ability to explain, communicate and work with other people.
Re: Interviewing in Silicon Valley
#50Earlier quoted context omitted.
Interesting point of view, which I don't share by the way. I think the right person for the job is not per definition the smartest or the best at solving equations during an interview. Finding the right person for the job is more about getting a good fit with the rest of the team. Being the smartest guy/girl on earth doesn't help you when you have a shitty personality or can't work together with the rest of the team.…
Well it's hard to quantify the relative importance of personality and cultural fit vs intelligence and programming ability. You can turn what you said around, and say that you can be the nicest, coolest person in the world, but if you are a fucking moron who can't code, you won't be very useful. But the big tech companies seem to have settled on the current process, and are therefore probably fairly happy with the pe…