[maxaf]

I hire engineers for a living, and find intellectually dishonest any interview practice I wouldn't enjoy myself. Paper coding, whiteboard coding, brain teasers, and algorithmic beatdowns are out. Representative take-home work samples and conversational problem solving are in.

My candidates are told throughout the process that what we're looking for is a demonstration of how technical collaboration might work if we were employed by the same company. This takes away most of the stress of interviewing, which I know via candidate surveys.

My advice would be to steer clear from employers who use a soulless cookie cutter process that makes people feel like a commodity. This is how you'll also be treated during daily interactions and in conversations about your career development. Don't be under any illusion that you'll be able to find yourself on the right side of such a situation.

[catscratch]

> soulless cookie cutter process that makes people feel like a commodity

I agree most should steer clear from them, but the interview process is often an accurate representation of the level of the team:

* If the interview involves a copied a set of questions off the internet, verbal or written, they don't have the skills on the team to have a dynamic discussion.

* If the interview doesn't have enough standard questions, then they're either inconsistent or might rely heavily on certain people's intuition, the latter which could go either way but the former could mean complete disorganization.

* If they expect you to know the circumference of the Earth (equatorial 24874 mi/40030 km, meridional 24860 mi/40008 km) and capital of Sumer in 2281 (Uruk), then they could be interested in someone that has a scientific mind, great memory, and likes trivia or is very into history.

* If they give you problems to solve, they want to see and hear how you think.

* If they give you homework, they probably just want you to provide solutions in code and figure things out on your own to some extent, and the amount of time they give you to do that is indication of how they estimate tasks.

[hyperliner]

"* If they expect you to know the circumference of the Earth (equatorial 24874 mi/40030 km, meridional 24860 mi/40008 km) and capital of Sumer in 2281 (Uruk), then they could be interested in someone that has a scientific mind, great memory, and likes trivia or is very into history."

===> ... or who has the skill of typing "google.com" on a browser

[samstave]

>"Representative take-home work samples and conversational problem solving are in."

Exactly. How many times have you reached out to your network and said "HEY! I am trying to solve problemX and I am stuck on Y -- anyone done this before?"

You cant expect everyone to know everything - ESPECIALLY in an interview, and even more-so in a panel interview.

Measure their problem solving skills, not their intimate knowledge of tech/lang X....

and then on-top of that, judge their fit for working well in the team!

only ask that when they come back from a takehome issue, that they say exactly how they solved it:

"I had to call my buddy over at BigCorp and say, hey dont tell me the answer - but lead me to where I might figure out how to solve this problem"

OR

"Hey joe, I did this - but i am not sure how efficient it is - did you do something similar?"

Tell them to get a slack channel of their peers to help them succeed.

I am tired of everyone trying to be the hero - all my contacts try to support one-another, the interview process should be no different.

[emilburzo]

> I am tired of everyone trying to be the hero - all my contacts try to support one-another, the interview process should be no different.

Amazing, until you put it into writing I never realized that I do this too.

At least once a day I'll get a random question from my peers in areas where I have more experience than them, which also helped me gain real world work experience years before I even had my first job.

And I do the same when I wander in areas where I haven't had so much experience, discussing approaches and common pitfalls, which makes so much sense.

Yet in interviews it's like you're going to be working alone forever and have to be the best in these exact technologies/languages/stack or you'll never be able to do your job.

I guess this is what you end up with after calling everyone a ninja-rockstar-guru.

[erichurkman]

Having a friendly interview process, to us, is a competitive advantage. As is not requiring multiple onsite interviews, too many phone calls, and even making the onsite interview not take all day (we try to wrap up by 1pm unless a candidate is shadowing an engineer for a day, which we typically do for more senior hires). Having a concise interview process often lets us get offers out the door while candidates are still navigating 'Round 3' and 'Coffee with a lead engineer' and other nonsense with the bigger companies.

[retreatguru]

I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day - mainly solving business problems in elegant ways. I even contacted them and told them so but did not get much response.

I treat interviews more like going out for coffee and often do just that. I like to understand what people are passionate about both in tech and personally.

[initram]

Do you find that you can determine a person's technical skills from such a discussion? I've found that I'm not very good at determining such things from just talking. Often I talk with people who sound like they know what they're doing, only to find out later that they don't.

As for coffee - do you ask your interviewees if they want that? I don't drink coffee and generally hate coffee shops because the only other options are sugar and fat-filled starch bombs like scones and cakes, and other drinks I don't enjoy like tea. I usually eat a decent meal before interviews so I don't end up unable to think due to hunger during the technical part.

That said, I also find puzzles and unrealistic tests to be annoying. One thing I've done for the technical side is to pull questions from codereview.stackexchange.com and ask the candidate to review them. (I generally print it out and ask them to do it on paper in front of me, so they aren't looking at the existing answers.) This gives me a better idea of their technical skills without the "gotcha" feeling of whiteboards. It also normalizes for different background (e.g. I'm used to Xcode, but this interview had me working in Eclipse and I couldn't find anything!).

[retreatguru]

We discover people's technical skills with a take-home question. We took a real business problem that we already solved and get them to solve it. They don't write any code, but just give an explanation as to how they would go about solving it and why. There is a little bit about database normalization in it too. It's incredible how well this simple 'test' works in seeing how people think.

Often the interviews are over Skype, but we keep things pretty causal, and give the interviewee lots of opportunity to ask questions about the company and culture.

Cultural fit is very important to us. We live in Nelson, BC, small town Canada - very far away from Silicon Valley. Our team is very friendly and care for each other. We want to ensure any new hires contribute to that positive vibe.

[erichurkman]

To your latter point, any time we do technical exercises, we _always_ let the interviewee use their own IDE. Nowadays it's easy because most people have laptops, though we do offer to set one up if they do not have a laptop to bring.

Their choice of toolsets and setup can also be a really interesting discussion topic. More than once during an interview, someone has shown me something really cool that I adopted (new key binding, a new tool, a particular way someone had their terminals split-paned, etc).

[huac]

I've done a couple interviews over screenshare, where I setup my own IDE, and liked that more than the typical Google doc or CoderPad

[dmoy]

What if the candidate doesn't have a machine of their own (company owned)?

[erichurkman]

We have a laptop they can use and make the offer that they can use it. It hasn't happened often, but I could easily see it being set up with a few different environments already. (Adding that to my todo list.)

[greenyoda]

"I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day"

But then...

"I like to understand what people are passionate about both in tech and personally."

OK, so what do people's personal passions have to do with what devs do every day? Are you really going to hire someone based on whether they prefer playing music, or bicycling, or spending time with their kids?

Also, since we have a limited amount of time for the interview, I'd much prefer that you didn't waste time asking me personal questions that are irrelevant to the job requirements (or telling me personal things about yourself). I'd rather have time to ask you questions about the job and the company.

[BJanecke]

Hiring someone purely on technical skill is myopic, I'm not going to blabber on about "Cultural Fit" but in small to medium teams hiring someone with vastly opposing viewpoints can be detrimental or it could be greatly beneficial.

How could you expect to measure the social impact of a new member on your team when you look at them as a technical robot and not a human being.

[falcolas]

> I even contacted them and told them so but did not get much response.

Probably because it's much easier to rank a algorithmic solution. The question of "does your code compute the correct answer in the allocated compute time" provides a nice clear answer. Solving business problems in elegant ways, on the other hand, takes a human to judge, and the results are not always clear.

The difference in the difficulty grading the two is exactly why the former is so popular as an interview technique (requires low effort to get a binary answer), and the latter is better at actually judging an applicant (reflects the human behind the test).

[tome]

> I wanted to use and like hackerrank as a hiring tool but found the questions had nothing to do with what devs do every day

Surely you can add your own questions.

[clairity]

i really like your "how well do we collaborate" assessment method and the underlying advice of treating people meaningfully. teamwork is so important to satisfaction, achievement, and even a feeling of responsibility.

that isn't necessarily at odds with assessing technical ability via tests, of course. in a perfect world, we'd be able to tease out both great technical ability and great interpersonal skills. it sounds to me like our original ranter disagreed with the scope and focus of the test--timed cleverness and ingenuity in an esoteric problem space. that kind of ingenuity is often helpful but not often required for many technical jobs.

[oldprogrammer2]

I couldn't agree more, and I've shaped our hiring policy around the same ideas. I try to be very respectful of the time of both the interviewers and the interviewees, while still providing enough data to make a good decision. I'm sad to say that we learned the most from bad hires: people who were terrible communicators, people who became hostile after hired and their work was critiqued, and people who were expert at talking shop but couldn't produce functioning code on their own.

We typically do a short phone interview first to assess if there is enough common ground to work with. We're looking for huge red flags at this point, such as an inability to talk through very fundamental programming concepts, difficult to communicate with, or a generally disagreeable personality.

Next we do a take home project, where we share a functioning, boilerplate web app, and ask the applicant to spend a couple hours addressing some portion of "requested" functionality. The barrier we're looking for here is actually not very high. We want to see that the applicant was able to figure out was going on in an existing code base and that that they were capable of making a new, original addition to it (even if very small).

The next stage of the interview is an in-person interview with 3 or 4 us. We usually start off with a 30 minute paper test, where the applicant can pick 5 out of 10 questions to answer. Pseudocode answers are expected, not syntax perfection. This is really another datapoint where we're trying to make sure the applicant truly is technically competent.

We then sit down and talk for about an hour. We ask questions about their resume, the project, and the paper test. A lot of this is making sure that they can talk about the things they chose to list on their resume. If they indicate expertise in TDD then they can expect questions about frameworks used and software patterns utilized to improve testability. If they indicate expertise in a particular database server, they can expect detailed questions in that area. This is also an opportunity for them to ask us questions about our company, culture, methodologies, etc.

The final part is a collaborative exercise in defining the architecture of a proposed system. I recognize whiteboarding a solution is tough in such a stressful situation as an interview with people you have not yet developed a working relationship. So we try our best to reassure the applicant, and to make it as collaborative as possible. Sometimes we'll debate different options amongst ourselves to see how the applicant participates and which direction they choose.

I usually close with a tour of our dev area, as well as a few areas of the company so they can see if it feels like a place they could call home.

Interviewing is hard on both sides.

[eastindex]

Full stack engineer here. Are you currently hiring ?

[maxaf]

Yes - e-mail address is in my profile. You can also have a look at our careers page. https://canary.is/careers/