This should always freaking be the case. You, the interviewer, are there to decide if you want to work with this person in the future. You're not going to learn that by making an adversary. You're not going to learn that by making it super easy either. If you're worth your salt (as an interviewer, and you should be given that you're now part of the hiring process), you should be able to go through an open ended problem (it's what I do). This open ended problem should have increasingly difficult sub-tasks and of course be related to what you intend the person your interviewing to do. One of my worst experiences interviewing was with a company that clearly didn't give a rats rear end (at one location). Interviewers were constantly late, didn't know what I'd applied for, or even at times my name. Same company, different location...totally different story. Your most valuable resource as a company is your people, treat them as such from start to finish. Needless to say, I chose where I'm at because of the people. I'm glad to see others sharing this attitude as well.
I've been on both sides in worse situations. The resumé is printed out and handed to the interviewers at the last minute or someone is asked to interview a candidate who has showed up and the resumé is handed at that moment. It makes up for a poor experience where the first question is "describe your experience and what you've worked on", most of which is usually present in the detailed (and long) resumé.
I think about hiring a lot and I see a lot of companies doing things that I think are completely opposed to their own goals. Specifically around technical talent where, given the current market, the goal is almost always to out-compete other companies by finding good candidates that others would have turned away because of cargo-cult awful interview processes and standards.
This looks great from what's printed on the page.
The question that jumps out at me from reading the interview prep screenshot is: How often does a candidate fail the "work on your own project" part simply because the people watching them have no interest in the problem space or worse, no idea what's going on? I just don't see how that type of interview could be scored equitably across a range of candidates.
Is that considered a failure on culture grounds? I'm highly suspect of basically all culture related hiring standards.
It's really good to hear that some tech companies are being mature about the process.
I've been in almost all positions of a hiring team: phone screen, white boarding, Q&A, etc.; and in the end I want to hear what this person can bring to the company and see if they're a good fit or vice versa.
I feel like so many places put emphasis on abstract knowledge and technical ability and leave out so many other traits that are good. Also, in Techlandia, I feel there is too much of a male machismo that permeates through and there are many people that treat the interview as a chance to demonstrate ability to the interviewee and/or trick them - to the point of intimidation.
> I feel like so many places put emphasis on abstract knowledge and technical ability and leave out so many other traits that are good.
Take a SWE job for example, what is the most effective, efficient, and fair approach to evaluate a candidate?
Can anyone name an approach that is, in general, better than the main-stream technical interview. Factors to consider:
1. Technical competence
2. Culture fit
3. Interviewer/interviewee/scheduling etc time cost
4. Logistic cost
I kinda like this one. The "what to expect" is really well done.
I also like the do-a-real-thing step. We do something similar at Pivotal. Once you pass the basic tech screen, we invite you to work with us for a day.
We pair program, so this is easy to do: take the candidate, drop them (usually) into a real project with a real engineer working on a real problem. Then they work together on the real problem. That's it.
Assuming nothing goes drastically wrong: One project in the morning, then lunch, then a different project in the afternoon.
If we agree that you know what you're doing and that we want to work with you, you're hired. Every engineer at Pivotal has passed the test of "do you want to work with this person?"
In the quest to work out "can this person do the job?", I personally continue to be amazed at the gymnastics companies will engage in to avoid just ... trying folk on the job.
I hope I was the only person to have had a bad experience with Pivotal ever. Their recruiter straight up lied to me (told me on the phone that they'd schedule a phone screen, went on radio silence, and claimed they had emailed me about moving on). From my personal experience, I don't think Pivotal belongs in a thread discussing great hiring practices.
Hi Jacques! One thing I can't wrap my head around: how do you compare candidates when you have them working on different projects? How do you protect against Candidate A finding themselves pairing on a relatively easier project than Candidate B? How do you deal with pairing on things that are complex and require time to spin up to understand the system architecture, the code base, and the problem at hand? If you only expose smaller problems to candidates, how do you ensure that on any given day there will be an appropriate problem to pair with a candidate? Thanks!
Love the idea of giving the person an idea as to what to expect though this is a pretty general outline; I've gotten the same (although I'll admit far less pretty) when I've interviewed at Amazon, Apple, etc.
The idea of letting someone actually work on a problem is far better than generic algorithm or data structure questions. Two things though...
> As soon as we schedule the interview, applicants receive a link taking them to this welcome page.
Love the page but the content is all static. This should be in an email. If it's in an email, especially in invite form, I have access to the content at all times on my phone and can even accept an invite. Putting it in the browser means I have to find the email and open the browser (alternatively bookmark or keep the site open). But the content is static so it should be in an email.
In my opinion anyway.
> After that is the main part of the technical interview: we ask interviewees to work on their own project, using whatever resources they deem necessary (and yes, that includes Google). We want resourceful developers who can problem solve, not people with an encyclopedic memory. We use this as an opportunity to learn what our candidates are passionate about. This helps us understand whether ReadMe is a place where they can pursue their long-term goals.
Hmm. So many projects I want to work on, especially for an hour or two session, may not necessarily reflect my long term goals but be more oriented towards completing something that either myself or I perceive my interviewers being interested in. Yeah I get the whole "work on what you want" thing but in such a short timeframe to show off what I can do is absolutely not indicative of my long term goals.
On the last bit, perhaps these people are just better developers than me or perhaps it's an artifact of the sort of things they work on vs what I work on but I can't think of a single thing I could complete in a couple of hours which I'd be proud enough of to show as an accomplishment.
I see a lot of these interview discussions talking about having candidates bang out real features in a couple of hours and I just don't understand how that's possible.
Sounds interesting but what if the candidate doesn't have a personal project or one they're willing to show you the code for as they're working on it? Also, seems like you could game this by rehearsing what you'd be developing before the interview (same way you can game questions about binary trees etc).
I think someone having a personal project is a strong indicator that they're passionate about the trade though which is a great thing.
That hasn't been a problem so far. A lot of candidates start new projects, and that's fine too. If you can't think of anything you would want to work on, that's a pretty bad sign for us.
The candidate has to bring their own laptop to work on during the interview, at their place of business?
I know lots of people have a laptop already, but I'm sure I'm not the only person who doesn't (I just can't work on one; I get frustrated). Or is that part of the selection process; they don't want the kind of person who doesn't own a laptop, or doesn't bring it with them to interviews.
Great post and it's awesome to see many companies try to make interview process better but my happiness didn't last long.
They require[1]: 'Your GitHub is full of everything from embarrassing hacks to impressive Open Source contributions'
I understand some reasons behind seeing Github profile of candidate but requiring it is too much.
But this is still better then company i saw the other day which was requiring Github project with X000 stargazers.
The presence of an itinerary for the interviewee should be a requirement. Sadly it's not. I've taken two interviews in the past week where I was in the dark as to what my visit would look like.
That page is dynamic, so everyone sees something different. By the time a candidate gets that page, they've already talked to 1-2 members of the team. Of course there's no "own a laptop" requirement.
They are when you're interviewing for jobs. I don't know about you, but my first impression of a company strongly informs my decision to work there if an offer is extended (because, you know, generally you only around 1 or 2 shots actually interviewing at the company before you are expected to make a decision about taking an offer)
Yes, they absolutely are. The one thing I look for the most in a potential new role is cultural fit; pretty much if I think the team will gel with me. Much of this becomes apparent through the interview process: the type of questions asked, the level of exhaustion shown, and how interested the interviewers seem in their own jobs. These things are as important to me as the type of company and the offer they extend since this is the place where I will spend a great deal of my time and effort. I'd rather not spend a significant part of my day with people that I don't like in a place that I can't stand.
How are different engineering disciplines interviewed? For instance, take a mechanical engineer, are they going to sit down with a stack of tooth picks and be asked to design a bridge with a Pratt truss? Are they asked to show their designs on Github?
I seriously think there's an underlying pissing contest that has permeated the software development culture. If other engineering disciplines can be hired by talking intelligently and answering questions related to their field, why can't software engineers?
> If other engineering disciplines can be hired by talking intelligently and answering questions related to their field, why can't software engineers?
Other engineers have professional registration and thus some form of regulation. In some countries you're not allowed to cal yourself an engineer unless you have some particular qualification and the registration.
It's a self-selecting group, of course... but we're all happy with it! We've also gotten a lot of good feedback from people we've interviewed, since it's not often interviews feel encouraging rather than adversarial.
Lots of people here are describing interviews (from the perspective of the interviewee) as being an adversarial process, where people have bad experiences because the interviewer is more interested in being intimidating or showing up the interviewee, but I wonder how much of that is just the process itself being intimidating.
For me, job interviews were always incredibly nerve wracking. It feels like you're being judged, but of course you are being judged- the whole point of the interview is to judge your suitability for a position. It's also nerve wracking because I was always interviewing for something I wanted really badly, that was a step up from whatever I was doing at the time. So, I was always interviewing from a position of weakness, and it made me feel even more self-conscious.
At this point in my career I've probably been the interviewer >= 20x as often as I've been the interviewee. Some were phone screens, the rest were in person, and about half the time I was one of two interviewers (some companies do one-on-one interviews, some do two-on-one, and supposedly some do many-on-one interviews but I've never experienced that (but it sounds terrible)).
In all of that, I don't think I've ever been malicious or tried to show off or make someone feel bad, and I don't think I've ever witnessed or even heard of a colleague doing it either. Maybe I'm just lucky, and got all my jobs at companies that had a less horrible interview process, but I wonder.
Job interviews at companies I really want to work for have been intimidating because it is intimidating. I wanted to move up in the world, take the next step, and so it always felt like the people interviewing me were implicitly people I wanted to emulate. That's so awkward- it feels like approaching pseudorandom strangers and asking, "I want to be like you, am I cool enough for you to give me a job here so I can be like you?" You're being measured against a yardstick, and it feels like the yardstick is the person interviewing you, because they've already got a job at the company you want to work at.
So I would have to fight against being intimidated by the people who were interviewing me, but what I didn't realize was that although I felt intimidated, they (probably) weren't being intimidating. I was just projecting what I was feeling onto them, they were just being their normal selves and sucking at interviewing because everybody sucks at interviewing.
There's no reason for anyone to be a jerk to an interviewee, the interviewers want to have successful interviews just as much as the candidate. Nobody wants to drive away a potentially good hire just to act superior for a few minutes in front of a job seeker that they will never see again for the rest of their life.
So I would like to think that all of the horror stories about terrible interviewers come from interviewees projecting their (totally natural) stress onto other people, but who knows. People can be irrational jerks too unfortunately. :( I'm also curious if the bad interviewer behavior was exclusively in one-on-one interviews. Those seem more likely to go off the rails, since there's no other interviewer to counteract someone who is an especially bad interviewer to begin with.
> I'm also curious if the bad interviewer behavior was exclusively in one-on-one interviews.
I can hardly speak to this in general, but Google always schedules one of your interviews with two interviewers, one of which is supposed to be training the other to do a good interview.
I felt that those interviews were much nastier than the one-on-ones (2 out of 2 times).
The few Big Name places I've interviewed have always had one The Jerk. This is the stereotypical interviewer who seems determined to put you in your place, is hostile, etc.
I'm convinced that the companies think that this is a good idea, and I'm convinced that this is wrong.
I am quiet impressed that there is even a niche market for people who want to host docs. It really just takes 15 minutes to setup a gulp/grunt script to build and push to cloudfront. After all, we need those scripts for local development anyways.
There's a huge market for good developer experiences :) More and more people are becoming "developers" every day: computer-literate people who want to build something.
It's easy to push something. It's a lot harder to build something good. Our goal is to get away from static docs, and show each developer exactly what they need.
I'm a developer turned founder and I've considered using Readme.io. The ability to defer work in the exchange for time is king for me right now. In my experience, setting up another Google Cloud project (this could be cloudfront, heroku or w/e), selecting a static site generator, finding a theme and the inevitable customization that comes with that is significantly more than 15 minutes. Then of course once it's all done I'll have something that's sub-par from multiple perspectives: SEO, information architecture, no search built in, design doesn't quite match my brand.
In the end the price point put me off enough for me to go in another direction. Yes, it would save time and that time would absolutely be worth $59 or $199 here and now. Maybe even that much every month for three months. At some point though I'm going to run the books and see that I've paid $2k for something I could have built myself in a day. Hopefully when that happens the company is at a point where that is a complete no-brainer "I'm glad I made that call", but there's no guarantee of that. Most companies fail and all that jazz.
We're bootstrapped so the equation may be different if we raised money. I assume that's a significant part of their customer base.
My team uses ReadMe for non-technical documentation. We tried wikis and Google Drive before that and they all felt so... unoptimized. Searching was difficult, organizing was time consuming, and worst of all the documentation kept getting stale.
While ReadMe is built for hosting code/API documentation, we've had no problems using it for just about everything else. And since the UI is great everyone from my operations lead to my executive assistant are able to jump in right away and contribute towards living documentation.
Down the road, I plan to host our first customer support documentation on ReadMe. The both techies and non-techies can contribute towards keeping it up to date and a lot of the features that devs want with API documentation translate naturally to product support docs, such as the QA / Knowledge Base section.
Same thoughts here. Since I need to document my APIs anyway it seems to make the most sense to add comments in code, run a build script and have it pushed up somewhere. Heck you could even check it in if you're so inclined and services like GitHub provide much of the community aspect that I need.
[+] [-] jcbeard|9 years ago|reply
This should always freaking be the case. You, the interviewer, are there to decide if you want to work with this person in the future. You're not going to learn that by making an adversary. You're not going to learn that by making it super easy either. If you're worth your salt (as an interviewer, and you should be given that you're now part of the hiring process), you should be able to go through an open ended problem (it's what I do). This open ended problem should have increasingly difficult sub-tasks and of course be related to what you intend the person your interviewing to do. One of my worst experiences interviewing was with a company that clearly didn't give a rats rear end (at one location). Interviewers were constantly late, didn't know what I'd applied for, or even at times my name. Same company, different location...totally different story. Your most valuable resource as a company is your people, treat them as such from start to finish. Needless to say, I chose where I'm at because of the people. I'm glad to see others sharing this attitude as well.
[+] [-] newscracker|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] wwalser|9 years ago|reply
This looks great from what's printed on the page.
The question that jumps out at me from reading the interview prep screenshot is: How often does a candidate fail the "work on your own project" part simply because the people watching them have no interest in the problem space or worse, no idea what's going on? I just don't see how that type of interview could be scored equitably across a range of candidates.
Is that considered a failure on culture grounds? I'm highly suspect of basically all culture related hiring standards.
[+] [-] caffed|9 years ago|reply
I've been in almost all positions of a hiring team: phone screen, white boarding, Q&A, etc.; and in the end I want to hear what this person can bring to the company and see if they're a good fit or vice versa.
I feel like so many places put emphasis on abstract knowledge and technical ability and leave out so many other traits that are good. Also, in Techlandia, I feel there is too much of a male machismo that permeates through and there are many people that treat the interview as a chance to demonstrate ability to the interviewee and/or trick them - to the point of intimidation.
[+] [-] justicezyx|9 years ago|reply
Take a SWE job for example, what is the most effective, efficient, and fair approach to evaluate a candidate?
Can anyone name an approach that is, in general, better than the main-stream technical interview. Factors to consider: 1. Technical competence 2. Culture fit 3. Interviewer/interviewee/scheduling etc time cost 4. Logistic cost
[+] [-] flukus|9 years ago|reply
I don't disagree, but personally I would rather work with a competent (or brilliant) asshole than an incompetent nice person.
[+] [-] jacques_chester|9 years ago|reply
I also like the do-a-real-thing step. We do something similar at Pivotal. Once you pass the basic tech screen, we invite you to work with us for a day.
We pair program, so this is easy to do: take the candidate, drop them (usually) into a real project with a real engineer working on a real problem. Then they work together on the real problem. That's it.
Assuming nothing goes drastically wrong: One project in the morning, then lunch, then a different project in the afternoon.
If we agree that you know what you're doing and that we want to work with you, you're hired. Every engineer at Pivotal has passed the test of "do you want to work with this person?"
In the quest to work out "can this person do the job?", I personally continue to be amazed at the gymnastics companies will engage in to avoid just ... trying folk on the job.
[+] [-] praneshp|9 years ago|reply
[+] [-] sethammons|9 years ago|reply
[+] [-] BinaryIdiot|9 years ago|reply
The idea of letting someone actually work on a problem is far better than generic algorithm or data structure questions. Two things though...
> As soon as we schedule the interview, applicants receive a link taking them to this welcome page.
Love the page but the content is all static. This should be in an email. If it's in an email, especially in invite form, I have access to the content at all times on my phone and can even accept an invite. Putting it in the browser means I have to find the email and open the browser (alternatively bookmark or keep the site open). But the content is static so it should be in an email.
In my opinion anyway.
> After that is the main part of the technical interview: we ask interviewees to work on their own project, using whatever resources they deem necessary (and yes, that includes Google). We want resourceful developers who can problem solve, not people with an encyclopedic memory. We use this as an opportunity to learn what our candidates are passionate about. This helps us understand whether ReadMe is a place where they can pursue their long-term goals.
Hmm. So many projects I want to work on, especially for an hour or two session, may not necessarily reflect my long term goals but be more oriented towards completing something that either myself or I perceive my interviewers being interested in. Yeah I get the whole "work on what you want" thing but in such a short timeframe to show off what I can do is absolutely not indicative of my long term goals.
[+] [-] jghn|9 years ago|reply
I see a lot of these interview discussions talking about having candidates bang out real features in a couple of hours and I just don't understand how that's possible.
[+] [-] clifanatic|9 years ago|reply
[+] [-] 20yrs_no_equity|9 years ago|reply
[+] [-] pavlov|9 years ago|reply
[+] [-] pmiller2|9 years ago|reply
[+] [-] seanwilson|9 years ago|reply
I think someone having a personal project is a strong indicator that they're passionate about the trade though which is a great thing.
[+] [-] gkoberger|9 years ago|reply
[+] [-] EliRivers|9 years ago|reply
I know lots of people have a laptop already, but I'm sure I'm not the only person who doesn't (I just can't work on one; I get frustrated). Or is that part of the selection process; they don't want the kind of person who doesn't own a laptop, or doesn't bring it with them to interviews.
[+] [-] ddorian43|9 years ago|reply
[+] [-] alphabravodelta|9 years ago|reply
They require[1]: 'Your GitHub is full of everything from embarrassing hacks to impressive Open Source contributions'
I understand some reasons behind seeing Github profile of candidate but requiring it is too much. But this is still better then company i saw the other day which was requiring Github project with X000 stargazers.
I think we have to choose between bad and worse.
[1] https://readme.io/careers/#job-full-stack-nodejs-developer
[+] [-] mintplant|9 years ago|reply
[+] [-] pzaich|9 years ago|reply
[+] [-] Ntrails|9 years ago|reply
[+] [-] gkoberger|9 years ago|reply
[+] [-] codecamper|9 years ago|reply
[+] [-] rer|9 years ago|reply
They're not.
[+] [-] magic_beans|9 years ago|reply
[+] [-] netule|9 years ago|reply
[+] [-] jomamaxx|9 years ago|reply
They definitely are - it's part of human psychology, and it happens to those of us even aware of the fact.
We start making judgements quickly. It's the way we work.
It takes a lot of self-awareness, and usually methodology to overcome it.
[+] [-] justinlardinois|9 years ago|reply
[+] [-] JustSomeNobody|9 years ago|reply
I seriously think there's an underlying pissing contest that has permeated the software development culture. If other engineering disciplines can be hired by talking intelligently and answering questions related to their field, why can't software engineers?
[+] [-] DanBC|9 years ago|reply
Other engineers have professional registration and thus some form of regulation. In some countries you're not allowed to cal yourself an engineer unless you have some particular qualification and the registration.
[+] [-] runcougar|9 years ago|reply
[+] [-] gkoberger|9 years ago|reply
[+] [-] mwfunk|9 years ago|reply
For me, job interviews were always incredibly nerve wracking. It feels like you're being judged, but of course you are being judged- the whole point of the interview is to judge your suitability for a position. It's also nerve wracking because I was always interviewing for something I wanted really badly, that was a step up from whatever I was doing at the time. So, I was always interviewing from a position of weakness, and it made me feel even more self-conscious.
At this point in my career I've probably been the interviewer >= 20x as often as I've been the interviewee. Some were phone screens, the rest were in person, and about half the time I was one of two interviewers (some companies do one-on-one interviews, some do two-on-one, and supposedly some do many-on-one interviews but I've never experienced that (but it sounds terrible)).
In all of that, I don't think I've ever been malicious or tried to show off or make someone feel bad, and I don't think I've ever witnessed or even heard of a colleague doing it either. Maybe I'm just lucky, and got all my jobs at companies that had a less horrible interview process, but I wonder.
Job interviews at companies I really want to work for have been intimidating because it is intimidating. I wanted to move up in the world, take the next step, and so it always felt like the people interviewing me were implicitly people I wanted to emulate. That's so awkward- it feels like approaching pseudorandom strangers and asking, "I want to be like you, am I cool enough for you to give me a job here so I can be like you?" You're being measured against a yardstick, and it feels like the yardstick is the person interviewing you, because they've already got a job at the company you want to work at.
So I would have to fight against being intimidated by the people who were interviewing me, but what I didn't realize was that although I felt intimidated, they (probably) weren't being intimidating. I was just projecting what I was feeling onto them, they were just being their normal selves and sucking at interviewing because everybody sucks at interviewing.
There's no reason for anyone to be a jerk to an interviewee, the interviewers want to have successful interviews just as much as the candidate. Nobody wants to drive away a potentially good hire just to act superior for a few minutes in front of a job seeker that they will never see again for the rest of their life.
So I would like to think that all of the horror stories about terrible interviewers come from interviewees projecting their (totally natural) stress onto other people, but who knows. People can be irrational jerks too unfortunately. :( I'm also curious if the bad interviewer behavior was exclusively in one-on-one interviews. Those seem more likely to go off the rails, since there's no other interviewer to counteract someone who is an especially bad interviewer to begin with.
[+] [-] thaumasiotes|9 years ago|reply
I can hardly speak to this in general, but Google always schedules one of your interviews with two interviewers, one of which is supposed to be training the other to do a good interview.
I felt that those interviews were much nastier than the one-on-ones (2 out of 2 times).
[+] [-] jghn|9 years ago|reply
I'm convinced that the companies think that this is a good idea, and I'm convinced that this is wrong.
[+] [-] suyash|9 years ago|reply
[+] [-] scandox|9 years ago|reply
[+] [-] simplehuman|9 years ago|reply
[+] [-] gkoberger|9 years ago|reply
It's easy to push something. It's a lot harder to build something good. Our goal is to get away from static docs, and show each developer exactly what they need.
[+] [-] wwalser|9 years ago|reply
In the end the price point put me off enough for me to go in another direction. Yes, it would save time and that time would absolutely be worth $59 or $199 here and now. Maybe even that much every month for three months. At some point though I'm going to run the books and see that I've paid $2k for something I could have built myself in a day. Hopefully when that happens the company is at a point where that is a complete no-brainer "I'm glad I made that call", but there's no guarantee of that. Most companies fail and all that jazz.
We're bootstrapped so the equation may be different if we raised money. I assume that's a significant part of their customer base.
[+] [-] jtfairbank|9 years ago|reply
While ReadMe is built for hosting code/API documentation, we've had no problems using it for just about everything else. And since the UI is great everyone from my operations lead to my executive assistant are able to jump in right away and contribute towards living documentation.
Down the road, I plan to host our first customer support documentation on ReadMe. The both techies and non-techies can contribute towards keeping it up to date and a lot of the features that devs want with API documentation translate naturally to product support docs, such as the QA / Knowledge Base section.
[+] [-] BinaryIdiot|9 years ago|reply
Their stuff does look pretty though.