4 ms·

>Google's interview best practices strictly focused on algorithms and data structure questions won't help you in your interview process. They mostly don't help

>Google's interview best practices strictly focused on algorithms and data structure questions won't help you in your interview process. They mostly don't help because they bear no resemblance to what 99% of developers actually do, even at Google. Realism in dev job interviews is criminally underrated.

maybeiambatman 8y ago
Internships are probably the best job interviews.
- chooseaname 8y ago
  Yeah, but that only[0] works for entry level developers. [0] I'm sure there are exceptions.
  - maxxxxx 8y ago
    True. Contracting is sometimes also a way to find good people.
- crdoconnor 8y ago
  I think hour long interviews can also be fine provided an emphasis is put on squeezing realistic tasks in to the time provided.
madeuptempacct 8y ago
At a startup, we interviewed purely for being able to d x task in Angular, Entity Framework, MongoDB, C#, and other components of our tech stack. It worked out well for us - we just needed a website built. The company I work for now interviews only on the fundamentals and problem solving in language of choice - I am starting to come around and see the benefit of this, but it seems it only makes sense with senior candidates who context-switch a lot and need to intrinsically understand GraphQL the moment they hear about it because they know it's a graph.
cmollis 8y ago
completely agree. It's been done to me (at Google), and I'm guilty of this myself. I tend to ask a bunch of obscure questions about topics that ultimately have nothing to do with the daily job. I gloss over the banality of what they'll actually do (push data in and out of databases.. ), in favor of javascript scope, map/reduce esoterica, C pointer arithmetic, blah blah.. shit that I know. It's kinda stupid.
sparrish 8y ago
Agreed. We gave up on technical interviews and now offer a paid project. Something in the 5-15 hour range that provides an opportunity for the candidate to show their skill in the areas that we'll actually have them working - usually something from the 'features' list. We pay a reasonable hourly rate for the work because they're worth it. And if we decide their pull request is good enough to merge, we'll send them a job offer.
- crdoconnor 8y ago
  It's good that you're willing to pay I don't think 5+ hours is necessary. It's perfectly possible to squeeze a realistic set of tasks in to one hour I think (it just takes a bit of work).

maybeiambatman 8y ago

Internships are probably the best job interviews.

chooseaname 8y ago
Yeah, but that only[0] works for entry level developers. [0] I'm sure there are exceptions.
- maxxxxx 8y ago
  True. Contracting is sometimes also a way to find good people.
crdoconnor 8y ago
I think hour long interviews can also be fine provided an emphasis is put on squeezing realistic tasks in to the time provided.

madeuptempacct 8y ago

At a startup, we interviewed purely for being able to d x task in Angular, Entity Framework, MongoDB, C#, and other components of our tech stack. It worked out well for us - we just needed a website built. The company I work for now interviews only on the fundamentals and problem solving in language of choice - I am starting to come around and see the benefit of this, but it seems it only makes sense with senior candidates who context-switch a lot and need to intrinsically understand GraphQL the moment they hear about it because they know it's a graph.

cmollis 8y ago

completely agree. It's been done to me (at Google), and I'm guilty of this myself. I tend to ask a bunch of obscure questions about topics that ultimately have nothing to do with the daily job. I gloss over the banality of what they'll actually do (push data in and out of databases.. ), in favor of javascript scope, map/reduce esoterica, C pointer arithmetic, blah blah.. shit that I know. It's kinda stupid.

sparrish 8y ago

Agreed. We gave up on technical interviews and now offer a paid project. Something in the 5-15 hour range that provides an opportunity for the candidate to show their skill in the areas that we'll actually have them working - usually something from the 'features' list. We pay a reasonable hourly rate for the work because they're worth it. And if we decide their pull request is good enough to merge, we'll send them a job offer.

crdoconnor 8y ago
It's good that you're willing to pay I don't think 5+ hours is necessary. It's perfectly possible to squeeze a realistic set of tasks in to one hour I think (it just takes a bit of work).