As both an interviewer and interviewee at Weebly, I'm pretty confident in saying I prefer our approach of the trial week. It really gives a great opportunity for the candidate to show off their skills without the on-the-spot pressure of a coding interview. A great side-effect is the candidate gets to determine if they like the team, and vice versa. I honestly wouldn't work somewhere else where I couldn't come in for…
Destroy all hiring processes
71–80 of 104 posts
Re: Destroy all hiring processes
#72It's funny, I've tried tons of different approaches to solving this problem and the only thing I now do is spend about 30 minutes with someone then decide to hire or not (usually I'm able to express this on the spot to whomever I'm interviewing). For better or worse, my instincts about who is smart, honest and kind seem at least as good (and often better) than any other approach we've tried.
Also reminds me of a comment by Robert Townsend. Which is a warning about following the practices of the biggest most illustrious firms. In his day that was General Motors etc. Today it's Apply and Google. I think those guys can spend a buttload of time and money looking for the perfect fit out of the line out the door of candidates because, it matters. Bad/Good hire could cost or make the company millions of dollars. It's also hard fire when your company is large.
Your dinky company? A misperfect fit is going to cost you thousands to tens of dollars.
Re: Destroy all hiring processes
#73Earlier quoted context omitted.
It's more that there's a lot of cargo-culting and "Google did this, so it must be good" flying around, and a lot of really bad CS programs which revolve more around the Feynman-rant memorize-and-regurgitate style than actually understanding performance characteristics. Which in turn produces interview processes that really are of the See-'n-Say variety. Though to be honest, for a lot of what I do my working set in me…
Fair enough, but then you should explain that what you're against is mindless regurgitation, not good CS education (which again, has algorithms at its core, but goes far beyond that).
A big part of the problem is over-generalization. Here's a reddit comment I posted in a similar discussion not too long ago, touching on that:
https://www.reddit.com/r/Python/comments/3nfbkr/patreon_is_a...
The person I was replying to there had made the mistake of assuming that because in these fields of programming, knowledge of data structures, algorithms and big-O characteristics is one of the most important things for performance, that must be true of all fields. When, in fact, it's not true of all fields, and I provided an example of one where it isn't true and where quizzing someone on their big-O cheat sheet wouldn't actually reveal whether the candidate has the most relevant knowledge for what's going on.
Re: Destroy all hiring processes
#74Re: Destroy all hiring processes
#75Earlier quoted context omitted.
Brilliantly put. When I'm giving interviews I really like it when a candidate posed with a fairly complicated problem or design question pauses and actually thinks, then says something like "..well, I don't really know, I'd probably want to think about it more, but here's an idea" before putting forward their likely non-optimal but totally plausible and on-the-right-track design or solution that they thought of on th…
I recently interviewed at Facebook and they seem to want the shoot from the hip type person who is extremely confident (borderline arrogant) about their answers. Theh drill and drill amd expect rapid fire responses.
Re: Destroy all hiring processes
#76A couple of years back, I was hiring some vendor developers for my team, and since I had some flexibility in the interviews that wouldn't be allowed for full-time employees, I tried an experiment: For one of the vendor candidates, I told him a day ahead of time that I'd be asking him to implement System.Collections.Hashtable in C#, with behavior equivalent to the one in .Net. The day of the interview came, and he whi…
I recently interviewed with a company that had advertised (in my paraphrase) "we've noticed that a lot of perfectly good developers do poorly in interviews for reasons that appear to be unrelated to job performance. So you can now interview with us by completing a project on your own time, and during the interview we'll talk about that". My project was a regex matcher. I ended up getting the following feedback: > We…
Re: Destroy all hiring processes
#77I'm working on open source stuff for two years now. Everything I do is public for everyone to see. Including my responses to bug reports and design documents. Yet I get the same algo/ds puzzle questions that you should've solved before in order to solve it in an interview setup. Google reached to me and said based on my profile I can skip the phone interview but I'm so afraid of the interview that I postponed it mult…
* Google asks questions like pots of gold[1] where it's really impossible to solve it on a whiteboard if it's your first time seeing the problem. * Ok, so here is an anecdotal sample. I have not seen this problem before. After reading the problem description I tried one round of the game on the paper (actually in the text editor) to get the feeling of the game play and then it took me about few minutes to come up wit…
Re: Destroy all hiring processes
#78Earlier quoted context omitted.
I recently interviewed at Facebook and they seem to want the shoot from the hip type person who is extremely confident (borderline arrogant) about their answers. Theh drill and drill amd expect rapid fire responses.
That may be true for the person who interviewed you, but that isn't any sort of official standard
Re: Destroy all hiring processes
#79this article is awful. it cites a single bad coding interview as a problem with all coding interviews. as someone who gives tons of code interviews, they are absolutely invaluable, and are a strong indicator in weeding out people who can't write code. you can't blame bad interviewers for the entire process not working.
Slippery slope fallacy...You are incredibly oversimplifying what he is saying. Sure, he is generalizing but he isn't citing a single coding interview to judge the entire process . Having said that, I actually agree with him because I've learned that it's not always simple as who can't write code . I would much rather assess a candidates' ability to learn (sharpness) than the current skill-set.
Re: Destroy all hiring processes
#80Earlier quoted context omitted.
* Google asks questions like pots of gold[1] where it's really impossible to solve it on a whiteboard if it's your first time seeing the problem. * Ok, so here is an anecdotal sample. I have not seen this problem before. After reading the problem description I tried one round of the game on the paper (actually in the text editor) to get the feeling of the game play and then it took me about few minutes to come up wit…
Do you allow linear space?