I am super bad at interviewing — I just want to see how well the candidate can code :-(
Then read some (maybe this, I didn't look at it in detail, but at first glance looks reasonable) and practice.
> I just want to see how well the candidate can code :-(
All this tells you is if the candidate can code. If you want that, give them a test, look at their Github history (if they have it). Ask for code samples from any project they can share that they're proud of.
I personally find it much more valuable when interviewing someone to talk about what they've done. How they've solved problems. What their interests are both in and outside software.
Setting up a non-stressful experience and using behavioral interview type of questions and form is my personal favorite. Something I think is really important, that many people forget, is that the interviewee is also interviewing you. If you come across disorganized, unprepared (didn't even read their resume), etc., then you may fail the interview and even if you want to hire them, they'll say no.
I try to get all information I can about the candidate, including reading through their Github or Linkedin profile, or looking them up on StackOverflow or on social media just to get a deeper understanding of what kind of person (and coder) they are. But I was consistently surprised by how difficult it may be to find relevant information about a candidate before an interview. Many do not include links to their code (Github, Gitlab, Bitbucket, whatever, just show me how you think) in their resumes (admittedly, we did not have it as a hard requirement, but one would assume that a programmer would include them). Resumes often contain spelling or grammar mistakes that bias me against the applicants (and I need to tell myself that these mistakes don't necessarily matter).
Our process is a screening interview over Skype with a simple coding challenge. Followed by an hour-long in-person interview, also coding-heavy, but relevant to the work that the candidate will be doing (no brain teasers, no CS algorithms). I feel that at least this gives me some objective datapoints to assess and rank the candidates. Asking about previous work or interests in and out of software feels too subjective to be useful for subsequent comparison, and is prone to false-positives (we once talked to a candidate with an interesting background and all the right buzzwords in their social network who did not even pass the screening challenge). Although we certainly do ask.
Yes, this is a problem in subjectivity, but I don’t think there’s any better way to judge a cadidate than their past experience. Experience is an important factor in determining leveling, etc.
> we once talked to a candidate with an interesting background and all the right buzzwords in their social network who did not even pass the screening challenge
Yes, and I did recommend giving a programming test. It sounds like your process worked if you were able to disqualify them early.
Behavioral interviews, when done properly, are not something they can easily BS through. In fact, I find I get far more details about how they work through this process than white boarding sessions.
Programming is not the only aspect of a job, understanding how they resolve conflict, disagreements about API design, how to design higher order interfaces, who they talk to and how they determine what to include in designs, how they deliver software into production, what they consider MVP; these are all things that can be discovered through behavioral interviews, and many people don’t represent these well on resumes.
If you job is really coding most of the time and challenging/interesting enough on itself, you have less reason to do projects on the side (and it might not be effective use of time). Same for those working in competitive positions where either maximum time or output is expected.
I've been given tests galore though. Last week I was given one and told while I was halfway through it that somebody had accepted an outstanding offer.
Hiring is so broken.
They absolutely matter! Spelling, grammar, and usage mistakes on a resume can be a red flag that the candidate is sloppy or careless. They didn’t even make the small effort to have a native English speaker proofread. Will they have a similar cavalier attitude about code reviews or compiler warnings?
When I’m looking for programmers, I’m often looking for craftsmen (or women): people who “use good wood in the back of the cabinet” [1]. If you’re misaligning the margins on your resume or if you incorrectly use “your” instead of “you’re,” it says something about the level of polish you find acceptable.
1: https://thenextweb.com/apple/2011/10/24/steve-jobs-obsession...
I wonder if there have been any studies done into this or whether it's just a popular mantra repeated in many resume guidelines. I lean towards your side, but a much more experienced colleague of mine is adamant that you cannot tell a good developer from a bad one by how clean or sloppy their resume is. And that the list of companies they worked at and their years of experience are a much better predictor of success.
I think this is a bad idea. If you discover through this stalking that they are on the opposite side of some issue to you, will you be able to overcome any innate bias? Like it’s utterly irrelevant to anyone’s professionalism if in their private life they happen to be e.g. pro or anti abortion and if they never bring it up at work. And you also don’t know the context that lead them there. When I interview a candidate I deliberately know nothing apart from what’s written on the CV, I don’t even talk to my colleagues about them.
Absolutely, there is this risk. On the other hand, how do you know they would never bring up this opposite side of the issue at work, or that you would not inadvertently offend them by something you say? Also, I've heard culture fit mentioned a lot, and if you are looking for someone for your team and they turn out to be on the opposite side of some issue to you, is it possible they wouldn't fit your culture?
Although I completely understand what you are saying and it's a really good point.
Oh you absolutely can, if you look at group memberships, volunteering experience or whatever. Sexual orientation too sometimes. Even if they don’t make a big deal of it or get into arguments or even explicitly mention it at all.
Basically you are better off not even looking.
Then I was the lead at a small startup where I was the only technical interviewer, led to a nightmare situation. The person could talk the talk but had dismal output in practice and was super defensive when things were on the line. Took a lot of work to convince others in the org he had to go as he was charismatic with excuses, personal issues, etc.
Never again. Now I grill people and only consider offers where I was sufficiently grilled, in real time, to ensure I'm around people who can do the job.
I haven't been burned by this process once. I have gotten to the end of an interview and decided a candidate was not being forth coming on details, and turned them down, but I've never ended up with someone getting through where it was a complete disaster. That's not to say that there haven't been people that weren't perfect and ended up letting go, or they decided to leave themselves.
Behavioral interviews when done properly get very detailed. I often am able to discover exactly how much of the HTTP stack someone has worked on, for example, down to choices on parameters at the TCP layer, or asyncio libraries.
Unless your part in the interview process is explicitely to only look at the coding skills, in which case that's perfectly OK I suppose!