Ask HN: What do companies WITHOUT a whiteboard interview ask?

[xokr8s]

Hey,

So I'm in college and preparing for interviews (swe). I've always found Leetcode irrelevant and would rather learn how to actually build stuff.

So I was surprised to find that a ton of companies have actually done away with the traditional style (https://github.com/poteto/hiring-without-whiteboards).

There's a lot of advice on "how to crack the coding interview", but how do you crack these kind of interviews? What should I expect and how should I effectively prepare?

Thanks in advance.

[larrykubin]

The company I most recently interviewed at asked questions about the particular technologies and associated libraries that were required for the job I was applying for. For example, what is your experience with React? What have you built using it? Have you used Storybook, Jest, etc? Tell me about a scalability problem you solved. What is your experience with AWS Lambda? My resume listed out my jobs for the past 10+ years, and they didn't feel the need to give me a leetcode interview. There was nothing to "crack" or study for, I just told honest stories about what I have done over the course of my career, and we had a conversation. Working out well so far!

[muzani]

I never hire or have been hired from whiteboard interviews. They seem irrelevant in our situation - we're hiring people to write bug free code that works but is being optimized by someone more senior.

One of my favourite is architectural discussions. Tell them how the app is and ask them how they would do it. Show them a screen we plan to make in the app: How would you implement pull to refresh? What about this complex layout here? What about pop up dialogs? How do you prevent the pop up from crashing the app if a phone call comes in here? How would you suggest caching on this kind of screen? Now assume with have an architecture of X, how would you implement a cache within 4 hours without changing the architecture? Okay, on this page we'd like to take photos and make sure they're not tampered with; you can ask help from the back end to verify but keep the workload to a minimum.

The good answers will propose a solution. The really good answers will offer some solutions and say which don't work and why, and what factors might sway the decision. Acceptable answer is googling and showing the thought process of selecting/rejecting that solution.

I think the only way to really prepare is to get good at making apps, maybe browse subreddits on the topic.

[decafninja]

FYI, from personal experience, at least some of the companies in that "hiring without whiteboards" do, in fact, whiteboard you with leetcode questions. I think it's really a team by team basis even within these companies.

It sucks, but I would highly suggest you study for leetcode interviews. There are many more companies that will leetcode you than not, and the numbers are growing. Many companies that did not leetcode candidates several years ago are now doing so.

It's better to suck it up and play the game to maximize your chances, instead of trying to hunt the elusive white whale that is a great company that won't leetcode you. At least if your intention is to target companies in one of the big US coastal tech hub cities (SFBA, Seattle, NYC, possibly a few others, and at least London if you're in Europe).

Granted, some companies are doing away with leetcode interviews too (especially in the frontend), but they seem to be the exception, not the norm, and still rare.

[mrfusion]

My best interview ever was just meeting for coffee with my future manager and having a conversation about software development.

[rocketpastsix → mrfusion]

These are my favorite types of interviews. Tech skills can be learned, but getting along with various people including managers and leaders is more important.

I've been lucky I have been able to build up my network via conferences and user groups and twitter. The last time I looked for a job, all the conversations were more or less personality based over tech based.

[stevekemp → mrfusion]

I think most of my interesting positions have started with things like that; once we went for pizza/lunch and chat, once we went for beer, and other times just random meeting for coffee (outside the office).

Getting the chance to talk about different things in a more natural environment is a lot simpler for everyone involved.

Of course there are downsides too, but these are the kind of interviews I prefer the most.

(In fact the past two interviews I had also involved me bringing my child, just to make things even more unpredictable! )

[EllipticCurve → mrfusion]

This is pretty much how the interview with my current position went. It felt really good to just talk about software development, private projects and other topics instead of doing tests in one form or another.

[vanusa → mrfusion]

These are pretty much the only kind of interview I want to have, these days.

And the thing is - it's actually pretty easy to tell where the other party is at, skill-wise. As in, within 10 minutes or so usually.

[2rsf → mrfusion]

Same

[muffa]

I've had interviews with take home assignment, nothing to big, like refactor and write unit-test.

Other interviews have been more a conversation about my resume, like it said I worked at X company with Z, Y technologies and just had a conversation about that.

Honestly I think this is enough, if someone managed to study at a university for 5 years get an engineering degree hold similar positions as the one you are applying to, why do whiteboarding, take-home etc. You can tell rather quick when you have a casual conversation if the applicant knows what they are talking about and also if you would like to work together. This is usually something you can tell after 5-10 minutes talking to each other :)

[dynamicdox]

I have helped interview at my current company which is a Fortune 50. Typically it is split depending on whether the person is more senior or junior. Since you mentioned college I’m going to assume you fall somewhere on the junior side of the scale.

For junior positions I am mostly looking to see that the person is eager to learn and has a good mentality. This means that the person doesn’t have a huge ego, talks passionately about projects, etc. red flags would be not knowing extreme basics like functions or variables. IMO for junior positions culture fit is way more important. I want someone that will learn and grow with the team.

[peruvian]

A few weeks ago I had to complete a project. That was the only technical interview I was given.

I was sent a zip file with a README, Dockerfile, and specs for the project. I had to zip and send back the completed project with instructions on how to run it and document it. I had 3 hours to do it.

Pros: Less studying abstract problems, more practical

Cons: Essentially gave up a whole evening; was given no feedback, just a "we've passed on your application".