[overshard]

This also fails to point out the surprising number of developers who know their algorithms, know every "coding question" for whiteboard interviews, can copy and paste a ton of code off of StackOverflow to create a quick mockup but also still don't know how to code.

I've known some very talented developers who could never pass a standard software engineering interview but if you give them a week to create a project they'll have something to you that works.

I've also known some very talented interviewers who have never completed a project from start to finish.

I think we just need to all agree that interviewing is hard for Software Engineering and no one has a good solution for it yet. I am constantly on the lookout for someone who finds something that is both effective and doesn't waste a ton of time for both the interviewer and interviewee.

[ellius]

Here's mine:

1. I ask about prior experience, following up on any interesting resume items or comments. I try to act like a "biographer" (per the book "Who") and just learn their story.

2. I ask them to describe data flow in a basic web app. If I push this UI submit button, explain the progression of data from the client to the database.

3. I ask for an explanation of core concepts of the framework I'm interviewing for or any one they've used.

4. I ask about version control concepts and some specific git commands.

5. I ask about prior team practices, e.g. what types of meetings they have and what the interviewee thinks of their effectiveness.

6. I ask about their knowledge of ops/DevOps, e.g. explain how a pipeline works.

7. I ask about basic CS/object orientation/language concepts, e.g. static vs. dynamic typing.

8. I ask what their most interesting project or story was and why it resonated with them.

9. I ask what their toughest debug was and how they solved it.

10. I ask about their experience with testing and opinions on how best to do it.

Between all that you get a pretty decent picture of what level they're at and what is their capacity to learn.

[MperorM]

My problem with this style of interview, is that someone like me, who is a mediocre programmer, but stellar communicator will fare MUCH better than someone who is a brilliant programmer but poor communicator.

I spend lots of time reading about smart people's opinions on programming, and will be able to recite that knowledge and play it off as my own hard-earned experience. I could talk for an hour about tradeoffs between Vagrant and Docker, without ever having spent more than a few hours actually working with Docker.

If the interviewer is really sharp they could maybe dig deep enough until they see that there's nothing beneath the surface, but I suspect most wouldn't do so even if they were capable.

[ellius]

It depends on what you need. If I need a Docker expert, you can be sure I'll tailor my interview to a Docker deep dive with very precise and detailed questions about commands, concepts, etc. The first step in any interview process should be to think very clearly about what you need and to then adjust any template you have to those needs.

[MperorM]

Yeah, I was mostly thinking in the context of a junior role. Generally bullshitting of any kind will be caught out. My point is not that someone could bullshit their way through an interview of this style. It's rather that I think it unfairly favours people with a lot of general and high-level knowledge, over someone with strong fundamentals.

[cjohnson318]

This is a very good list. I especially like asking number 8. If they can't talk about something they were passionate about, then that's a red flag.

I also ask people to implement the Blum Mental Hash, which I heard about on NPR in 2014. It's easy enough to explain in five minutes or so, but difficult enough to write out in a half hour or so.

https://scilogs.spektrum.de/hlf/mental-cryptography-and-good...

[sh87]

This is good, no doubt, but judging programming ability based on how they answer these questions is severely prone to fail because 1) this relies heavily on the interviewer's skills and 2) its so easy to game this system.

I've had so many co-workers talk, passionately, about stuff they don't have the faintest scent about. It's shocking.

Unless you actually oversee a candidate work and reason through a representative problem, implement it and articulate it, there's no good way to gauge competence.

[ellius]

I actually agree with that and think that's something I need to mix in. But I will say it's hard to bullshit your way through every one of those questions. I've had people BS through 3-4 but pretty much inevitably they fell apart on the others.

[gwbas1c]

In the medical profession, doctors go through a formal, multi-day certification process. Interviewing a doctor is mostly about mutual interest in the workplace; because no one in the interview needs to prove competence.

In contrast, in our profession, certifications tend to be useless. (Certifications tend to be technology-focused, instead of broader skillsets needed to be a software engineer.)

It's like we, as an industry, need to come up with a robust certification process that determines competence.

[hellisothers]

Man this so hard. I would pay $1000+ per x years to go to a 3 day certification event where I have to create software and have that software be judged and certified competent. With the assumption that companies would pay the same very board $5000 for my results and I could skip the lame, poor signal programming portion of interviews.

[embwbam]

I just interviewed a bunch of folks for a Haskell position at my startup. We started with a video call, then I sent them a real world take home assignment. It was a list of requirements to solve a problem in our actual domain, slightly vague, with a simplified set of functions they’d need as a library to get it done. It wasn’t technical, just a general problem.

It was surprisingly easy to see who had both practical problem solving skills and technical ability. I could see how they modeled the data and the functions.

The best candidates emailed me to ask for clarification about the requirements. I was able to see how effective they were at communicating.

Some of the candidates said they loved the assignment. I think we need things that are closer to real work to gauge how good people will be at real work

[thatswrong0]

Did you make it clear that they were encourage to email / communicate if they had any questions? Because I could definitely see myself not emailing back unless that was specified

[embwbam]

Yes, definitely.

[ianai]

Finishing something is somewhat of a separate skill, I think. Like it’s some sort of mental skill to build and hone over time. Perhaps not too deep of a skill compared to others, but being able to create or identify and then execute an end point isn’t the same as coding or any other creative skill.

[Aperocky]

In my personal experience, this came down to hanging up there with all the algorithm and data structure knowledge but no idea of what implementation in real life look like. The majority of people that suffer from this is identified by the OS they use --- just like leetcode isn't 100% accurate, which OS you use should have no impact on the ability of people to program. But the gaps are significant and I've found that people who use Windows to (usually) be very behind on actual implementation of software (of course there are good programmer who use windows, but they're the exception in my anecdotal experience).

[jcadam]

> I've known some very talented developers who could never pass a standard software engineering interview but if you give them a week to create a project they'll have something to you that works.

> I've also known some very talented interviewers who have never completed a project from start to finish.

Yea, I'm definitely in the first group. From a career progression and remuneration standpoint, it would be much better to be in the latter. I sometimes wish I could trade in my "gets stuff done, right" skill set for "can invert a binary tree on a whiteboard in 2.5 seconds." Sometimes.

[ng12]

But the author is talking about FizzBuzz. It's just a loop with an if/elseif/else statement. Both types of developers you reference should pass it handily.

[azundo]

Since we all spend more time writing code than reading, my current tech screen is a small program in the tech for the role we're interviewing for that has a mix of obvious and subtle bugs, some poor data modeling, etc. First step is to get it working to spec, then refactor. I find it very engaging for interviewer and interviewee, is hard to game and gives me a sense of what the person will be like to work with.

[sanderjd]

> Since we all spend more time writing code than reading

I spend quite a bit more time reading code than writing it...

[mooreds]

I think gp reversed their verbs accidentally.

[oblio]

Everyone does.

[zerr]

"No one has a good solution" is becoming a meme as it seems :) when in fact lots of actionable options are mentioned in such threads.

[ypcx]

Here's a good solution - review the Github (or similar) of the people you are thinking to hire.

They may have the simplest of projects or contributions out there but you may infer how they think, how they behave, and what drives them.

If I don't have things to show for it, then I'm not really interested into programming. The immediate knowledge is secondary, the self-motivation is primary, because motivation makes you gain knowledge quickly, or, at all, in fact.

[schwartzworld]

I haven't contributed to my personal github in a year, but I love programming and do it every day.

[salawat]

I don't maintain a GitHub at all, yet I spend plenty of time digging through FOSS code at all levels. I generally don't contribute because any type of fix I'm doing is typically just a one-off for my own purposes, which may clash with the intent of the overall project.

I despise signalling for signalling sake. I just enjoy debugging, learning how things work, and doing the smallest tweak possible to fulfill my needs.

I minimize my digital footprint intentionally; people have a habit of trying to get to know you without engaging with you directly when you're too open, and I hate that.

I throw away and redo things in different ways on a regular basis. I change my working OS, workspace structure, buildtools, programming languages, etc. Keeps beginner's mind firmly in place, and helps keep me humble.

Point being, your vetting process completely fails to take into account someone that simply doesn't put themself out for everyone else's perusal, and who actually values their privacy.

Your method ironically would turn me off of most candidates. The Art of Software Engineering for me is to take what you have, look at the hole that needs to be filled, then coding a piece that looks like it belonged there the entire time. It's about building what you want with what you have.

I can admire idiosyncratic code that works in clever ways. Just as I can run screaming when it comes time to refactor it.

Point being, sometimes people's value add isn't conducive to being posted on GitHub, or isn't for personal reasons.

[thatswrong0]

Yeah, that’s a terrible idea. I’m good at programming and like doing it, but not enough that I’ll put in appreciable time outside of work because I have _other hobbies_, as incomprehensible as that sounds. I put a lot of time into them, and between them and having a social life, there’s no time for programming.. but that certainly doesn’t make me a worse programmer or less motivated when it comes to my work.