
Ask HN: What does your ideal software engineering interview look like? - andher
Posted this before but it got lost quick, so trying again. I&#x27;ve seen many posts talk about the deplorable state of interviewing today, calling out whiteboarding, take-homes, multi-days, algorithmic, etc as all have massive shortcomings (and I think many who&#x27;ve done the rounds of the interview circuit would agree that its a stressful pain in the ass situation). Maybe the answer is that there isn&#x27;t any one-size fits all situation here, but I was generally curious about what people think their ideal software engineering interview would look like?
======
caymanjim
The best interviews, and the best places I've ended up working, are the least-
technical. A simple free-form conversation in a casual environment (over
coffee, lunch, beer, whatever) is sufficient. Talk shop. Geek out about
something. If you can joke with the interviewer about how annoying it is that
Docker Swarm punches holes in your firewall; playfully debate Vim vs. IDEs;
have an opinion on the quality of open source web frameworks in Go vs Python;
have a favorite Linux shell; can relate a horror story migrating a UI from
React to Vue; etc., then I'm going to learn a whole lot more about you than
I'd ever learn in a formal interview. Gotcha questions, whiteboarding,
hypothetical situations, etc. rarely demonstrate much actual experience
writing software. The bulk of the work that most developers do doesn't involve
inventing anything; it's usually just wiring things together.

If you've got a specific, narrow skill that you're hiring for, then you might
need to get more technical, but you should have vetted that already by
selecting your candidates from a PhD program or a prior successful job where
you're already familiar with their research.

If you're hiring someone right out of undergrad, there's no technical
interview that's really going to help. You just need to find someone smart and
motivated to learn, and a casual conversation is better for that as well.

~~~
caymanjim
My response above is perhaps a bit overly-dismissive of technical questions. I
always ask technical questions, but they're more open and conversational, and
I learn more from going off on tangents. There's rarely a single right answer.
I'm trying to get a sense of your experience and how you approach unknowns.

Here are some of the more-technical questions I ask interview candidates,
which are still best done in a casual way:

* What happens when a user enters a URL in their browser and hits return? If they start talking about DNS, protocol/port mapping, networks/firewalls, web servers-application communication, cookies, page rendering, etc. then I can go off on various tangents.

* How do you test your software? Can get into the differences between unit/integration testing, mocking/fixtures, QA, etc.

* How do you deploy software? Leads to discussions about SCM/branching, CI/CD, containerization, IaC, cloud services, the benefits/drawbacks of self-hosting vs cloud hosting.

There are plenty of others along these lines. My goal is to see if the person
has actually done anything in a real environment, formed opinions, and stayed
up to date on modern technology and practices.

------
mytailorisrich
"Fantastic CV. You're hired. Any questions?"

------
cyberbanjo
One where I end with a job.

