Describe the Best Interview You've Been In

My favorite ones were the ones that felt more like a conversation than a test.

One comes to mind where the interviewer was so at-ease he put me at ease immediately. It sounded more like a conversation between a junior developer and a more experienced one mentoring ("You don't like CSS, don't we all (chuckle), you should totally look up Flexbox Zombies when you get home (while scribbling it on a post-it and giving it to me)").

Of the more technical ones my favorite was one where instead of the interviewer asking me questions, we screen-shared and pair programmed together. She was typing, and I was talking, she would write a test, and I provided the code to have that test pass. It was totally chill; I was mostly talking pseudo-code so no issue with freezing up on syntax under stress. It was overall a very enjoyable experience.

My favorite interview was one where I was able to bring my own laptop to do a code exercise that was mostly communicated ahead of time. They also allowed me to use any tools that would be accessible to me in the real world: other developers in the room, Google, Stackoverflow, etc.

This is pretty close to my favorite interview. I really felt like I got to shine. There was pressure but no big rush especially.

In thinking about this, I'll contrast it with one of the worst interviews I was a part of: It was a two part interview:

• The part where someone asked trivia questions about how HTTP works off a piece of paper.
• The part where an engineer from the team who is clearly reluctant about hiring someone and basically saying "I like to keep my headphones on and do my own thing, that cool with you?"

After not getting much right in the random HTTP trivia portion, I never heard back from them, which was good.

Back to the good one. We've recently tweaked our interview process to be a bit more like that one that you're describing.

My favorites are the ones where I got the job. Given my "advanced" age, this happens less often than it used to happen.

That aside, my favorite type of interviews are discussions. Let me describe my most recent project(s) in detail, drawing them out on the board. Ask me about the design decisions that were involved, such as why this particular design pattern was used, what were the advantages/disadvantages of doing it that way and what kind of testing was done. Even ask lower level stuff like , "How did you use LINQ in this C# application?", "Did you use/write the stored procedures for this application?" or "What HTTP verbs did you implement in your web service?" Ask me about stuff in my project that might be applicable to what you need to have done.

I had an interview a few years back and it's still stuck in my mind. It was an interview where I learned something. Even if the job didn't work out (and it didn't), I ended up wiser afterward.

I did a live coding session using one of those apps where people can collaborate and I was asked to implement a couple of cool features using promises.

I think the feature is called multiplexing but essentially, I had to come up with a small function/library that allowed a multitude of callers to ask for the same URL/resource and instead of firing off a bunch of requests to the same URL. I believe my solution was to create an object like this:

let pendingPromises = {
  'posts/all': {
    promise, //actual promise that I used to ask for the data from server
    awaiting: [], // array of callers that asked for `posts/all` before it returns
  }
};

The other features had to do with sharing a single URL but ask for separate resources. Eg. you'd ask for posts/all but at the same time, you also ask for users/all and let's say posts/1. The challenge was to combine the several URLs in a single tick, and then ask the server for all those resources. I didn't create a full implementation for this one but basically, I combined the above feature to gather all URLs and their callers and then did something like this:

fetch(`/api/multiplex`, {
  body: JSON.stringify({
    resources: Object.keys(pendingPromises)
  })
})

And explained that I'd use the server's router to figure out which resources to fetch, do a Promise.all on them, and return an object like so:

{
  'posts/all': { data: [] },
  'users/all': { data: [] },
  'posts/1': { data: [] },
}

I still think about that interview and how much it taught me!

This wasn't my best interview, but it felt like one. dev.to/rommik/it-is-possible-to-co...

If I had to interview somebody, I would do it this way:

1) Clear expectations about the skill, experience, and salary range. Why waste someone's time if they don't match. I hate when companies are not transparent and not able to tell what they expect from a candidate. You can spot them by a very long list of requirements, no salary range or low salary with a requirement of 20+ years.

2) An outline of the interview. You will meet with Person A, B, C. They will cover your skills, experience, and they will give you a test. It will take 3 hours. I commit to the schedule as much as possible. I've been to interviews that dragged out for 5-6 hours, instead of allocated one hour. This is simply disrespectful to a candidate in my opinion.

3) If it is a multi-day interview, the decisions are made each day. Don't make a candidate go through the whole process to reject them at the end because they expect 5k more than you can afford and they've been clear about it from day one.

4) Give honest feedback. If somebody comes to my interview and they don't match what I look for, I owe that person the reason behind my decision. It's not just polite, it's a professional toward my peer.

I politely demand the above points when I got for interviews too, and I judge companies based on how they do interviews too.

The best interview I've been in was probably one where it was a casual conversation. It was only supposed to be about 20 minutes but turned into about 2 hours of technical and non-technical talk, where both I and the CTO were very relaxed.

That's from a personal point of view.

I've never had a good technical interview, though. Either they're pointless box-checking exercises or they're handled so incompetently I wouldn't want to work with such a team anyway.

The best interview I had was with the company I am at now. It was a one on one chat with the guy who would become my boss and he was honest about the company, answered all my questions. Didn't sugarcoat anything, told it how it was and made sure that I was well informed.

I was then introduced to 2 senior developers and we did a paired programming task, allowed to use Google and use them as help, they were acommadaiting, it allowed me to see the company culture first-hand.

Got feedback from my agent as soon as I left the building, I got the job.

I like the ones that include airfare, a hotel, and cover expenses for the weekend. :)

My favorite interview was for the job I'm currently in.

The interview started with me sitting with 3 of the staff and they introduced me to the products the run. As they were explaining the third of the products, I couldn't help but grin. They were describing a chat bot that did "where is my order" and "order returns" for large retailers.

They asked me why I was grinning and I explained that I'd just built a chatbot that did all of that for a fictional retail website. They were very interested and asked to see it afterwards.

They gave me a technical test which was a printed page of code. All I had to do was talk my way through it and explain what each bit did. It included some SQL query code and they asked me whether I thought it was an effective query. I have almost no experience writing raw SQL so I didn't know, but I would use a library like sequelize to create the query. They said that's often a smart decision.

I managed to find a few improvements in the code and explained what I'd have done differently and why. It was a more like a code review of their code than a high pressure test of my coding skills.

Finally I showed them my chatbot and they were really interested. Tom, who I now work on the chatbots with, asked about the way I had it set up and if he could see the code. We ended up talking through my code for a good 30 minutes. I explained API.ai and how it all worked and they seemed really impressed.

They gave me a tour of the building, including the gym on the ground floor, and the founder drove me back to the bus station. In the car, he let me know that I'd be hearing from them soon with an offer.

For my current position, I was invited for a 4-hour interview that consisted of 4 different sessions: coding, architecture, processes, and general Q/A with the manager. I liked the processes part the most: two people from the Security department prepared a role playing game for me based on an actual incident they had had few weeks before. I played the Engineer on Duty and I had to explain my decisions, with them interrupting me unexpectedly at times with "It's 2:30 PM, another machine becomes unreachable" etc. I had to ask a lot of questions (and I learned a lot about my future work that way) to be able to find a solution, and the questions were probably more important to them than the final solution (which was, accidentally, the same as the one they had made).