I am considered a great hirer, and it is because of this "one weird trick."

The most useful "question" is any generic task.

It can be as simple as

-- please put this spreadsheet in alphabetical order

-- I have misplaced your resume, could you send me another copy?

-- That sounds like an interesting article, would you send me a copy later on

Even the most trivial task will really illuminate the difference between candidates. Compared to a task, merely talking is entirely useless. Some very polished candidates will simply ignore the request and do nothing. Some will do one of two or three. Some very quiet candidates who are not "impressive" will do all the requests, thoroughly and with obvious care.

How can someone handle the request to forward an article with care? You have to see it to understand. They may remind you of the context, say a word about the article, and add another one for more context for example.

In interviews I like to try and get a reaction, and the best way to do that is to sit down with a coffee or two (or three) and just chat about their experience over the last few years, in a judgement-free zone - dev to dev.

In terms of an actual question, the only useful ones are ones that come from this chat, because it's where we have a back-and-forth conversation about tech decisions, what issues they had, what they had to overcome, and what decisions that particular dev made. My goal is to get a reaction, negative or positive, and dig into why that situation happened, what they did to overcome it, and what they'd do with hindsight.

Not only does it make an interview more interesting for all involved, it tells you more about the candidate than a quiz would. You learn what they do under pressure, what pisses them off, and what experience they have for the kind of work you do, because you've been using your experience against theirs in conversation. Sometimes, to make it fair, I tell them (without dropping client names) issues I've had recently, and I see if any of the solutions were raised by the team, or are ultimately the solution we went for.

I've had enough success with this approach that (when I did interviews) this was my approach:

1. A really basic take home test, probably in a language they don't use, just to see if they can write any code. Literally something that takes an hour to do. A favourite of mine was to get them to write an application in a given language to hit an endpoint, with a given code and their email address. When done correctly, an email is sent to our HR team, who then set up an interview. Based on our logs, you'd be surprised at how many candidates couldn't do this - by which I mean had clearly worked on the test, submitted something, and had failed to send a PUT request with the correct data.

2. A relaxed interview, like above, in neutral ground like a coffee shop. I use the walk from office to coffee shop to handle company questios, and the standard interview stuff,

"Tell me about one or two projects you've done in the past that stand out for some reason. Maybe you learned a new technology over the course of it, got to interact with cool people, got shipped off to a different country, had weird clients, got a killer contact. Maybe the project was a total disaster. Doesn't matter what happened or how long ago, just something you found memorable."

Get them talking about what things they get emotionally invested in. You learn a lot about someone this way.

The trick to good interviewing is putting the candidate at ease. When someone's future is on the line, they behave very differently, and preform worse than they would in a regular work environment.

Asking questions like "what have you done well" and "what mistakes have you made" will favor narcissists, because they will embellish, whereas those more on the neurotic side will take more blame, and dislike taking credit.

So put them at ease. You'll get far more real answers that way.

I find this one short and useful: "so you know language X and Y, can you compare some features between them that you like and dislike?". If they get into deep comparisons about the tradeoffs between type safety, state, maintainability, multithreading, undefined behaviour, functional vs OO, libraries etc. that's a good indicator to me.

Hiring side.

"Tell me more about what you did." Can be asked off almost any line of conversation. I'm seeking two outcomes:

1. Candidate's ability to quickly articulate a complex process, organization, problem, etc. to someone who has absolutely no understanding of it (i.e., me).

2. An understanding of their specific role and impact, as well as how the team worked together. You often have to coach people through the latter, as many candidates will default to the royal-we.

The other one I'm playing with is, "Let's say you start working here, but six months later, you leave for another opportunity. Why would you leave?"

I'm still figuring out the delivery on that one, but you get an interesting insight into what matters to the candidate.

Ironically, when interviewers talk about how they interview, they pretty much all seem to believe they are very good in evaluating candidates. But when candidates talk about job interviews, they all seem to agree interviews are done badly.

A rule I have is that everyone is good in something and bad in something else. So, if by the end of the interview I haven't found a topic where the candidate excels and a topic where sucks, the interview hasn't been effective.

From the hiring side:

"Tell me about a result or achievement you're very proud of. How did it come to be a goal for you, and what did you do to accomplish it?"

(Crucial followup after they answer) "Now tell me about a mistake you made along the way and how you overcame it."

Talking about real work provides insight into motivations and enthusiasms, and gives you permission to dive into details as they talk. It also helps show whether they have a healthy attitude about mistakes. This question can also provide some insight into team dynamics since very few big things are accomplished solo these days.

From the applicant side:

"Let's say I get hired and I do an amazing job. You're going to write my 6-month or annual review--what would you write?"

Like Amazon's trick of writing the press release first, this helps hiring managers get specific about their expectations for the hire. It's amazing how often companies hire folks with only a vague sense of what success should look like.

Applicant side: "What's the biggest struggle that you're currently working through?" coupled with "Tell me a bit about how you're working through that struggle."

I find this tells me a lot about the person who's interviewing me and the current climate they're operating in. Asking follow-up questions helps a lot here too. It's a good way to find out if the interviewer (frequently the hiring manager) is struggling with an unmotivated team, overly-onerous bureaucracy, lack of funding, staff turnover, outdated software, etc.

I have a generic question which I ask in all interviews, whether hiring for a dev, manager, project leader. It works wonders for me.

For each position in the candidate's resume (or the last 3 if the resume is too long) I ask "what did you like about the job? what did you dislike? What made you happy to go to work and what made you drag your feet? It can be anything: boss, coworkers, how work was organized, office politics or lack thereof, visibility/interest of the job, commute time, offices... There are no wrong answers". Then I let them talk.

When it's done right, I find this is a great way to understand what motivates them and to make sure their intrinsic motivation is aligned with the position they're applying for and the company context. For instance, for a developer I'll be interested in someone who likes fixing problems; for a project manager, being result-oriented is usually a good thing. Someone who likes having a clear set of steps to follow is probably not a good match for my management style. Another thing that I can check is how they coped with a situation they disliked. Did they try to address it, work around it, or did they give up/avoid it?

I was first exposed to this approach as a candidate. I remember spending 90 minutes talking about all my previous positions, reflecting about what I'd liked and disliked for each of them, and coming out of there knowing more about myself than I did going in.

Having them do a code review (about 10-15 minutes), i.e. have a short (about 50-80 lines) piece of real code, that I have prepared with plenty of problem, messes, non-idiomatic code, or little ugly things.

NOT a test as in "find the 10 hidden mistakes", but an invitation to talk about ways to improve the code. I make it clear to the candidate that it's not about the syntax, or any algorithm, but about quality.

It's really good to see what kinds of things they care about (e.g. do they look into low-level performance, or more into things like variable naming and method length), how deep their knowledge of the language is (e.g. do they recognize non-idiomatic code, and suggest more modern approaches), if they are more of a high-level thinker or more detail-oriented etc. And of course, it nicely weeds out the (surprisingly high) number of people who cannot really program, without relying on any memorization of keywords. Plus, it's pretty realistic - nobody ever writes code on a whiteboard, but doing code reviews of code somebody else wrote is something that happens all the time.

Most candidates find that task quite fun - and with really good candidates I quite frequently learn something new myself.

I was planning to do a blog post about why and how I do that review - let me know if that would be of interest to you.

When interviewing someone for a more senior position, I would always ask, "What was your worst [work-related] mistake?" If they couldn't come up with anything, they were either lying or they just coasted through their previous jobs. If their answer was mostly about how it was really someone else's fault, then I'd consider them lacking in the kind of attitude I consider important in a co-worker.

On the applicant side, one of the more interesting questions I've been asked (as a product manager) was something to the effect of:

"What is something you believe about product management that differs from conventional wisdom (or what the majority of other product managers believe?)"

I thought it was a good question, because it gives the chance for the candidate to talk about how they think, and it gives them a license to speak a little more honestly than they ordinarily would say in a normal interview. It shows you how much thought the person has given to their profession and how they approach their job.

If you were asking this during hiring, I think it should be done with care on your end, because I could see it easily being misinterpreted by the wrong team/interviewer.

For example, if someone came in and said something like "Compared to others, I think A/B testing is a waste of time", it would behoove you to dive in a little bit more to understand why they think that. It shouldn't be disqualifying if you're a team that does a lot of A/B testing.

For me there are two critical questions I ask of a candidate.

1. I tell them the story about a massive screw up in my career (its funny) about how I thought I was getting fired about being frank about it... etc. I then ask "do you have a story about a major screw up in your career. The answer should say a lot. Dealing with crisis, dealing with mistakes, can you laugh about traumatic things (a great coping mechanism as a programer). I'm looking for insight into you in a professional setting. There have been occasions that this one question takes up the BULK of my allotted time and has on occasion gone over.

2. Can you read and talk about a piece of code GIVEN to you. The bulk of the battle for most devs is READING existing code and trying to figure out where to fit fixes in, or how to integrate what they are doing into a larger, standing system. The provided sample should have errors, room for improvement and plenty of ambiguity where the reader has to make assumptions or ask questions.

Generally, asking opinions rather than specific technical answers.

Asking "Do you have experience with technology X" is useless - everybody knows that "yes" is the expected answer.

Asking specific technical questions is random - they might or might not have come across that particular problem. Also, in practice the answer would simply be looked up, and you don't want to hire for memorization.

Instead, ask things like"How did you find working with <technology X>? Can you compare it to <common alternative>, or <similar tech also listed on their resume>?". Or maybe "what worked really well with <technology X>? What pitfalls did you fall into? Anything for which you would, or would not, recommed it?"

This kind of info is hard to fake, gives you good insight into their thought process and priorities, or just gets people talking about their projects more easily than a generic "tell me about your work on project y".

More important than trying to find a question of adamantine perfection and blinding luster is the knowledge that regardless of how many hours you have to interview a candidate, your opinion will still be partial, influenced by biases and to some degree wrong.

When interviewing someone, "What will your next job be after this one and how can we help you get there?"

My follow-up is usually something like, "Explain that job title/position to me. What does that person do? What skills do they have?"

When they ask "Do you live with your family? What jobs your family members have? What are your hobbies? Where you were born? Are you married? How old are you?" then I know that I don't want to work there.

I can answer on the hiring side when it comes to programming jobs.

In a 100% honest world, you wouldn't even need to interview for technical positions; you could look at the person's resume and tell instantly whether or not they are capable of doing the job. But people lie a lot and over-embellish. So best questions to ask are about the items listed on their resume, because you find out who's telling the truth and who's not.

From the applicant side: Why are you hiring for this role? Is it a new position, or did someone leave it?

Let's use our time together well. I know you've read the position summary. Met with HR and members of our team here. What questions do you have for me?

Behind the question-- I'm probing for curiosity and intellection. Also, what's important and top of mind to them.

I like to ask about a project, could even be something from university days. I ask them to explain how they approached the problem, what were the challenges, how did they overcome them, and what was the final result of the project.

Applicant side (and software focused), asking interviewers how new functionality is defined, developed, and deployed gives a lot of insight to how the team works within the organization.

1) Tell me a little bit about yourself. 2) Tell me about an interesting challenge you had in your current position and how you solved it.

"Tell me about the last time you failed"

It usually reveals character on how a person deals with tough situations.

Just stare at them until you know whether or not they're a good employee. You can tell from their face.

what are the next lottery quick pick numbers