All we did in the interview was to discuss things they have worked on before, going deep into all the details. Talking about why they decided to implement it the way it was implemented, what the trade offs were, what they would do differently today, the hardest problems they had to solve, how they would have implemented it given different biz constraints etc.

No white-boarding, silly puzzle questions, online coding games, or other BS nonsense. Just deep questions about things they claim they have worked on in the past. It works really well. It is easy to identify experienced smart developers by how clear their thinking is and how well they articulate their decisions, problem solving etc.

It’s simple. It works. Highly recommended.

I think that a short phone interview quickly followed by a cup of coffee and an on-site 1-2 hour programming task with an informal presentation and/or QA section about the task with the dev team would be enough.

Basically, hiring boils down to

a) candidate not being an asshole, and

b) candidate being able to write programs.

You can figure out a) by spending time with him/her and you can figure out b) by seeing if s/he's able to finish the programming task. Then when everything has been sorted out, the athmosphere is more casual to talk about the approach the candidate chose, about the corner cases and pros/cons that were traded off during crafting the solution which also reveals quite a lot of the candidate. And that's all based on some programming task that is known and common to both parties which gives a nice frame of reference. That is, as opposed to how usually developers want to talk about things they're working on themselves and the candidate wants to talk about things he has done so far himself.

They give the candidate some messy, done-in-a-hurry code (but not purposefully obfuscated) and ask them to refactor it to the best of their ability. The interviewer sits next to the candidate and talks to them throughout the whole process. It's pretty much pair programming, but the candidate has the initiative.

I found it to be a breath of fresh air after all the leetcode interviews. Of course, they have the luxury of doing this, because they know what exact technologies they are using and they don't need to measure candidate's ability to learn new tech, etc. In their situation they are more interested in topics like whether the candidate can produce maintainable code, name things properly or communicate with co-workers.

See, most interviews are along the lines of: Q: Are you smart and good looking? A: Yes!

This is why I don't really intervew all. When I take the "best" ranked applicants I give them actual work; small slices from our actual code base. I provide them a complete, functional dev environment with one restrciton: cannot commit to git. I can see their work directly, I work with them directly and get real-time data on what it's like to work with them, how they handle a project, how they communicate blockages, how they figure out our existing systems.

In four to eight hours of work I know who is the right fit for our team. My cost to find and filter is very very low and rather than waste 2-4 hours per interview for 10 candidates I pay for 16-24 hours of work for 2 or 3 candidates. The hard costs are the same, it consumes less of my (or my engineers) time and the candidate fit is very good.

Testing a candidate in one hour is really hard.

CV's can be very deceiving. What I look for is folks who are good coders and good communicators. I don't care about culture fit. Our team is diverse from 50 year Olds, 19 year Olds, males females, black, white, brown etc.

Having a github profile with interesting projects is a boon. Even better if you've contributed to some meaningful open-source projects. This is great because it gives lots of data. The issues you file, the commits, comments and code give good insights about you. Much more than a one page CV.

I use the same question on every candidate and evaluate them.

I allow my candidates to use google/Bing, chrome console, whatever resources they would usually use in day to day work.

I look for understanding of basic data structures like maps, sets and techniques like recursion. I also give a ton of hints to guide in the right path. I can only help though if the the candidate wants help. Some candidates really don't get the hints even after multiple repeats.

Some candidates just dive into code and then get stuck. They confuse them selves.

The best candidates are the ones who ask lots of clarifications at the start, they break down the problem into little pieces without writing a single line of code. They emulate a computer and trace the steps in an abstract manner. They think like "to solve Z, I need A then do B and C and D." They then slowly write code for the little steps.

I love candidates who can give me a deep dive into a subject they are an expert on. I get to learn a ton on random things. Also gives insight on what makes them tick.

Don't give up. Please keep on trying. Feel free to PM me for any help. I really want you to succeed.

Here's a summary, in case you don't feel like reading the whole thing...

LeetCode, code tests and whiteboarding, the flawed standard: I find that being asked to write code that works without an IDE or a compiler and solve problems without being able to look them up is quite unlike my day to day job. Larger companies may still use this approach because they don't necessarily experience a shortage of applicants even if a certain percentage are turned away by this, but that might not be viable for smaller companies. Furthermore, you might end up hiring people who are good at competitive programming, which may or may not be what you should optimize for.

Take home exercises, high risk but high reward: I'd say that one of the better approaches is giving the candidate a problem to solve and letting them do that with their own tooling and approaches to development, which can later be a great basis for discussion or reviewing the code together. The problem here is that not many have time for that sort of thing and it's not always trivial to figure out whether it's actually their project or a friend helped them out bunches with it (albeit the discussion should help). That said, allowing the candidate to offer up one of their public past codebases (if such exist) might be worth looking into, as an idea.

Just having a conversation instead: I've found that just conversing with the candidate is also good enough in many respects. Asking them a few technical questions, but also letting them express themselves, and learning more about them in the process. You might suggest that there are some people who are good at explaining things without quite having a grasp at them, but typically if you ask them to elaborate that becomes pretty clear. Not only that, but this is helpful in figuring out which are their stronger areas and which might need a bit more help from mentors, as well as what they're interested in themselves, you can even recommend some technologies for them to look into!

Doing some design work together: if you'd have even more time on your hands, something like a system design interview might also be nice. Actually, any kind of design work, be it creating an ER diagram of a DB schema for some domain, or a few UI wireframes and talking about the UX, or just drawing up an example architecture for some made up system. Regardless, seeing how people reason in detail is good, especially if the process is collaborative in nature, even with the occasional disagreement to explore conflict resolution.

Writing and/or reviewing some code together: while writing code without tools might be troublesome, sitting down to write or review some code with actual IDEs and other tooling is a far better experience. Actually, if there was a take-home task, in those circumstances refactoring some code or adding a new feature might be quite good, because the candidate will already be familiar with the codebase in question!

I'd say that you don't need to do all of these steps, or ask all of these questions, but when the volume of applicants is relatively low and manageable, having a humane approach to each individual feels like an okay way to go. It's actually good to be at a point where I don't have to scale this up to a 25-100 interviews a week and throw much of this out the window. Then again, other approaches are also good, whatever works for each set of circumstances!

When hiring 40+ people for a neo-bank, I did what you should have experienced: listen to people and get to know them.

The key point of success in a team is of course their skill set, but also the potential synergy.

Lots of developers are very bad if not terrible at presenting themselves, be it on a résumé or during an interview. And this has no relation to their actual skills.

So I always try as hard as I can to actually extract information from them.

First, I let them feel at ease, telling them that this is not a challenge but a time to get to know each other (which is actually true).

Then I ask a lot of questions about their experience, both in the technical sense, but also human one.

I try as much as possible to understand how they think and feel, what do they value, aspire to, try to achieve by joining the company.

I’m not a hiring manager but a 15+ yrs of experience developer. Yet, I find that hiring developers by actually being one goes much smoother than when you’re not.

Last but not least, I think that this crazed interviews are becoming more and more common practice because developers agree to pass them.

If you want to change this, then don’t go through them. There are thousands of other great companies that do no torture their candidates.

First, I've hired dozens of people in the last year, and the main piece of advice is this: I'm rooting for you.

Seriously.

I spend a TON of time sifting through resumes, doing phone screens, checking Github repositories, and on-site interviews. I really, really don't want to do it.

Ideally, the first candidate that walks through the door is perfect, and I don't have to even talk to anyone else. Done. Finished. Now I get to do real stuff at work.

I'm rooting for you. Honestly.

Second, the answer to your question is "No". You don't have to know how to invert a binary tree or re-implement quicksort. For good interviewers, the point isn't for you to reinvent or regurgitate complex computer science problems in 30 minutes, but rather to allow you to demonstrate your thinking. Can you write code? Can you walk me through your thought process? If I throw a curve ball, can you adapt your solution to that?

You don't need to know all of those things you mentioned, but you should be able to demonstrate that, given enough time, you can do those things.

We only get 30-45 minutes with you. The goal is to figure out what you do know quickly, and then gauge your capacity to grow beyond that.

Look, there are some things you must know to get a job with me, and there are some things that aren't important. "Can you write code?" is the bare minimum. I wouldn't hire a carpenter who doesn't know how to use a hammer, but just knowing how to use a hammer doesn't make a carpenter good, either.

There are an infinite number of skills out there that you can learn. I don't expect you to know them all. I expect you to know SOME of them. I expect you to be able to write code, but I expect you to do a little bit more than that.

Most jobs I've ever had required on-the-job training. I have to learn how the new job does code deployments, how they structure their code, maybe a new programming language. I have to learn how they do standups (if any), code coverage (if any), and one-on-ones (if any). I have to learn what's in this database and how it connects to that API and what framework they're using. Everyone uses frameworks differently, so I have to figure out the quirks and esoteric choices that this particular company made.

The point is this: you don't have to know everything. You need to demonstrate that you can code (the bare minimum of the job), you have to demonstrate that you can learn and ideally learn quickly, and perhaps most importantly, you are hopefully someone that I would like to sit next to for the next six months.

I'm not going to tell you not to stress out, because that's perfectly normal. But what I will say to summarize are these two things:

1. We are rooting for you.

2. You don't have to know everything. Just be your normal smart, enthusiastic self and do the best you can.

Keep those in mind and you'll be fine.

Personally I really like the interview process a previous empoyer used: shortly before the interview starts we had them look over a roughly CS 102-level programming project, then we ask them to design the architecture on a whiteboard while the interviewers ask questions/give guidance. What we're really looking for here is:

a.) how do they handle the social aspect of working with a superior who will often (gently) criticize your work and/or ask you to thoroughly explain why you're doing what. b.) that they have enough chops to architect a simple program.

If they can pass those test I'm confident they'll be an effective team member, because at the end of the day all you really want is someone who is competent enough to be useful, and fits into your culture/team. Everything else will shake itself out. You don't need some "superstar/rockstar/ninja" (unless you're solving a particularly hard domain-specific problem) so stop looking for them and excluding everyone else.

Instead start building an effective team.

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.

First an on-site talk at the company site, with a general discussion with the candidate about his personality, background and technical experience, as well as a presentation of the company and the people he would be working with. A polite and pleasant talk, to feel each other out while still getting the relevant information.

After the interview is complete, the candidate would be given a couple of sheets of paper with two written tests: (1) A general IQ test. A lot of people seems to find these controversial (ignoring for the moment any legal issues which I believe are overblown), but I find them pretty good at gauging an individual's logic skills. (2) A small number of programming questions targeted to the language/platform/niche that the candidate would be working with. Not too hard or complicated, but merely a filter to quickly assess the candidate's experience. Questions about some common development paradigms, best practices, knowledge of frameworks, stuff like that.

The candidate would get 10-15 minutes for each of the two tests, and can do them any way s/he likes, in any order and with no requirements to complete all the questions (the questions s/he chooses, and choice between speed/thoroughness is itself an indicator about the candidate). S/he would complete the tests in a room alone without pressure or distractions.

After this, the interview process is complete. The candidate goes home and can be assessed from both his presence and statements, and the results from the tests. No confrontation necessary. The candidate gets a chance to look his best during a relaxed and affable conversation. The recruiter is able to easily get a picture of the person's hard qualifications. Any embarrassing slip-ups on the tests are evaluated offline after the candidate has left. Code is, after all, usually not written on a whiteboard in front of a group of people you have never met.

My primary concerns are: Is the candidate going to be competent and capable of solving difficult problems and contributing to the team? Are they going to work efficiently and be productive? And perhaps most importantly, are they going to be enjoyable to work with?

It is less important to me that a candidate has a particular skill with a particular technology because those things can be learned easily by good programmers. I'm looking for more of an intuition, problem solving ability, and the ability to cleanly translate the solution into code.

To that end, I try to get candidates to code with me, usually by asking a challenging problem and then sitting down next to him or her to work it out. The whole process has been more difficult than I anticipated though. I find many candidates unwilling or unable to write code in an interview.

I'd love to hear some suggestions on hiring tactics and questions to help me better find my next co-worker.

I suppose, I just don't see why a shitty programmer couldn't be filtered out almost immediately through this technique. Maybe it's a company size/age difference - what size company do you have in mind?

Leetcode-style interviews became popular in the mid 00s, primarily because they were used by hot tech companies of the time. The thing to understand is that at that time, the idea of asking people to write code during an interview what sort of revolutionary. Prior to that interviews had little structure. It wasn't unusual for the hiring manager to make the decision, some times based on credentials, recommendations, or trivial-like questions.

This type of interview became wildly popular because it allowed budding unicorns to hire programmers of high quality at scale. The process was less biased than the alternative, reproducible and scalable. Here you have two blog posts [1][2] that show the line of thought at the time.

The reality is that big tech has elevated leetcode type interview to an art. They have reached a near local optimal through years of experiments and refinements. It is working well for them so they don't have the need to take big risks such as completely revamping their hiring process.

I love the topic of hiring and interviewing and I'd love to truly get at the bottom of which method works best. I like this article because it explicitly calls out shortcomings with typical alternatives that are not usually mentioned. I hope in the future a new crop of unicorns can take these practices to the next level and do a fair comparison.

[1] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid... [2] https://sites.google.com/site/steveyegge2/five-essential-pho...