Hacker News Reader

Comment by RandoHolmes | Hacker News Reader

Give the person 3-5 presentation topics they can choose from and have them come in and present to your company (non-technical & technical). Afterwards hold a Q&A where the technical and non-technical identify themselves as such and then start asking questions.

It allows your company to learn, to get a feel for the person's ability to communicate, and to stay away from stupid things like tests.

It's also easily the best interviewing process I've ever experienced.

---

edit: Since it appears that multiple people have taken this to represent an hour+ long presentation, let me clarify here.

A better way to think about this would be a long-form discussion about a topic. The initial "talk" would be 5-10 minutes, with a Q&A afterwards to ask for clarifying questions.

I've been working in this field for over 25 years. I spent roughly 30 minutes of prep for the interview and it was easily the best interview process I've ever experienced.

View on HN

Unless the job is mostly giving presentations, it seems like its optimizing for the wrong thing. For all the talk about software development being a collaborative field, for most people it really is still mostly isolated mental work.

Yeah, asking me to spend 5+ hours building a powerpoint deck is a lot more annoying than asking me to spend 5+ hours on some code project. I'd probably just bow out of the process if asked to do that.

Perhaps presentation is the wrong word, lets say "talk" instead. Not even a requirement to have anything graphical, just a long form discussion followed by Q&A afterwards.

Doesn't matter. The people who do well will spend 5+ hours on it since that is how long it takes to put together a talk, refine it, go through it a couple times, get feedback, adjust based on feedback and so on.

Perfect filter! I would rather not hire someone who doesn’t want to explain their projects and finds it onerous. Win-win.

There's a difference between being able to say "you need to explain your work and projects to me" vs. you're going to spend the entire interview day preparing and giving presentations.

I agree with the other commenter, it baffles me that we think that asking someone to write code, when the majority of their job will be writing code, is somehow an unfair interview process so the solution is to have them give only hours of powerpoint presentations.

All day doing presentations? That isn't what we are talking about here. Starting the day with 30 minutes of "open mic" to introduce yourself and tell us about something cool that you did is an outright invitation to start the day by getting us excited to hire you, a 30-minute uninterrupted opportunity to show yourself in the best light. How can that be a bad thing? Some so presentation-phobic that they won't do that is not going to bring a lot of value to the organization.

You seem to have an impression that a certain personality type will be better at doing their work than others. That's a very limiting view in my opinion, and you're going to pass over entire groups of people who can bring a lot of value. Neurodiversity can be just as important as gender diversity and cultural diversity. If you work with only one kind, then your world-view will be limited by that kind.

I've come across many a smart person who would abhor the idea of listening to a presentation, let alone give one. Give me a document they'll say, and they will go through it at depth and collaborate amazingly over text. A mix of both is required. You don't want everyone to be giving presentations all day, just as you don't want no one to be attending any presentations. Diversity is essential, and it's more effective to create structures that allow different types of people to work with one another than to mould people into personalities.

It's not possible to create a "perfect" interview process. I can literally give your criticism to every single interview process you can ever imagine and be correct in that criticism.

It's akin to saying that because some people have anxiety issues, we should completely do away with interviews and just let people randomly walk in and do work.

Because that's the only way to potentially avoid the criticism you gave here, only that's also not true because locale comes into play. "You didn't create a building every 500 feet that people can walk into, so now you're disenfranchising people without cars!".

My point here is that this is not a useful criticism. Come up with a useful grievance, one that's actually actionable, and then maybe we can talk.

Well to start with, I would put more onus on the interviewer to extract information rather than on the candidate who is already likely to be stressed.

Not every personality difference can be reduced to anxiety. That is precisely the kind of closed world-view I was talking about that can form within homogeneous groups.

Imo this is plain stupid, sorry. Many people don’t have such abilities, and 95% of the people I know never needed to present something to any audience so they don’t have experience in it either. This sounds awesome for a marketing or PR manager or even for a vice president, but a weird method for software engineering positions.

> Many people don’t have such abilities, and 95% of the people I know never needed to present something to any audience so they don’t have experience in it either.

You act as if the people listening aren't aware of this.

What is it you believe exactly, that if person A sounded nervous they wouldn't be hired?

The entire point is to get a conversation started, and the following Q&A allows them to do something everyone needs to do in a job, which is to answer questions.

No interview process is perfect. You can literally give me a description of any interview process and I can start finding problems with it.

Just as you can literally give me a description of any software solution and I can start finding problems with it.

That you can find problems with it doesn't make it useless or harmful. Please come up with better criticisms.

> Some so presentation-phobic that they won't do that is not going to bring a lot of value to the organization.

I can do presentations, however you are asking me to hold a free 30 minute lecture teaching your employees about something. I'd rather not, basically every company gets excited to hire me anyway and I'd rather spend a few hours doing some comfortable coding over spending a few hours preparing a presentation.

What baffles me is that you wrote this after my edit and are still pretending that I was suggesting hours long powerpoint presentations when I very specifically said otherwise.

> Unless the job is mostly giving presentations, it seems like its optimizing for the wrong thing.

Technically speaking, if we're in an interview to "optimize for the right thing", then we would just have them come in and type.

But we all know that's also optimizing for "the wrong thing" despite it being what we do physically day in and day out.

This is because you _CAN'T_ "optimize for the right thing" in an interview. It's not possible and this needs to be acknowledged.

Therefore you go for something else. Anyone who is a software developer can listen to a 5-10 minute presentation from another developer and start forming general, broad opinions. They can then start asking questions afterwards to help clarify those opinions.

But the Q&A also has another purpose. Way too often interviewers will come to conclusions that don't follow (non-sequitur). I once had someone tell me they didn't feel I would be a team player because I told them as long as I had headphones, open office would be ok. The main difference I've found between business people and technical people is that business people will ask clarifying questions. The Q&A sets the expectation for the _INTERVIEWER_ to ask clarifying questions.

All modern software jobs are mostly about explaining your solution to others (stakeholders, reviewers, senior/staff engineers, managers, executives).

If you can’t boil your work down into accessible presentations and adapt them for technical or non-technical audiences, you won’t get anywhere.

Nobody will agree to help you, allow your team to grow, give you budget for tools you need, make compromises with you around integration requirements or shared design patterns, unless you can frequently convert your software work into highly professional presentations.

I’d argue that competent presenting and writing skills are of equal, or even greater, importance than software skills or expert knowledge, whether for a research software job, software contractor job, SWE within tech / ecommerce / banking etc industries - across the board there are pretty much zero types of software engineering jobs in which software skills are actually the most important thing. Presenting and writing are frequently much more important.

I agree with your description for senior devs, technical managers, and above. But in my experience there is no reason such a burden needs to be a core part of a mid-level team member's job description.

To be clear, explaining your work is a part of every developers job. But top notch presentation skills don't need to be a part of it. Developers can talk to other developers in sub-optimal ways that are still effective. But when your hiring process has an hour long presentation as a part of it, you are optimizing for the thing that is very likely not the most important feature of the role. The point is to structure your hiring process such that it optimizes for the right things for the role.

I've updated my initial post with a clarification since you're not the only one who came away with the impression this was an hour long presentation.

But also, I really really dislike when others talk about "optimizing" people. It's not possible to optimize your hiring process for anything useful. Due to this, there should be a lot more empathy in the hiring process than their actually is because everyone wants to make it robot-like by "optimizing" something.

> All modern software jobs are mostly about explaining your solution to others

This isn't true in my experience, there are plenty of well paid jobs where you don't have to talk to non-technical people. For example, lets say you are developing infrastructure at Google, how often do you think you talk to non-engineers? Never, everyone in your management chain will be engineers, your product managers are ex-engineers, your users are engineers etc. This is true for directors managing lots of people as well as well.

And even when you develop services much of it is just getting the technical parts right so you can work there as well at Google with very little time spent talking to non-technical people, so senior positions there are mostly about technical stuff.

You could argue that Google and other big companies are a special case, however if we exclude low paid jobs where you just earn half of what you'd do at Google or Facebook then pure technical work like this is a very significant fraction of the market. I'm not sure why I'd work on my presentations skills so I could get hired by a company paying me less.

> “ For example, lets say you are developing infrastructure at Google, how often do you think you talk to non-engineers?”

I can speak from experience since I help run the site reliability incident response team in my (large ecommerce) company.

How often do rank and file SRE ICs need to speak with non-technical staff about projects? All the time.

They give tech talks and council presentations, they contribute work to quarterly roadmap project pitches, and they give business scorecard presentations to walk higher level managers through the breakdown of costs and benefits, why we should pay money for a new cloud tool, what time & effort some org-wide planned migration or upgrade is going to require.

Let alone basic stuff like writing effective tickets / issues / RFCs / PR descriptions, postmortems, etc., and walking teammates through work artifacts daily.

For every two hours of software work, I’d expect 1 hour of “wider audience communication” work - and that is for deeply technical ICs in roles like SRE. The closer you get to product engineering, the more the ratio shifts towards communication.

I can tell you this translates specifically to Google & Facebook - because most of the SRE colleagues in my company came from Google & Facebook, and attest to that being the case there too.

I worked as a SWE at Google for several years on two different teams, I never talked about work with a non engineer, and one person I worked with talked to non engineers. SWE's outnumber SRE's by something like 10 to 1 at Google so my experience should be more common than the people you talked to.

Your described experience is so wildly different and long tail uncommon from the hundreds of other ex-Google SWE colleagues I’ve had over the years that we unfortunately just have to exclude it as extremely unrepresentative.

I've met many talented developers who would describe that as their worst nightmare. Presenting to a group, especially a group you don't know, and with an added high-stakes outcome is incredibly stressful and not at all relevant to the work that most developers will ever have to do.

Explaining things well to a wide range of people is one of the most important skills for a developer.

Yes communication is important, but communication rarely needs to happen in the format the parent comment suggested. Unless the position involves working with sales or things like developer advocacy, the described approach seems unnecessary. Especially given the original question was asking for ways to create a great candidate experience.

Some developers are more comfortable with communicating via 1:1 conversations, design documents, proof of concept PRs, etc.

I've done a lot of public speaking and presenting, but am aware I am in the minority of developers. I've also managed a lot of people and many of them have struggled with self confidence and presenting to large groups. This has not been a reflection on their performance as an engineer.

I just want to say that this is an attitude that's come up over time and as an older person it baffles me.

To explain, college curriculum's require atleast 1 public speaking class. These classes are infamously difficult for a lot of people who find it scary to talk in front of a class of 30+ students. But society as a whole considered it to be the young persons responsibility to overcome this fear.

Nowadays, it's far more likely that people are going to make arguments such as "the class shouldn't be required" or some other thing to try and help the young person avoid the scary public speaking.

My point here is that yes, it's true there are going to be some who struggle with presenting to 5-6 people. That's on them. If they can't talk to 5-6 people they're going to find something as simple as a daily standup to be scary as well, should we just get rid of it? (Actually, I hate standups and think they're a waste of time, but you get the point).

It's also not clear to me why you characterized this as a "large group", but I'll give you the benefit of the doubt and say maybe you're used to interviews where 20-30 people get involved. That's certainly not what I'm suggesting.

And finally,

I can't imagine a young developer not being able to have a 5-10 minute talk in front of others about something like, say "What is memory safety in rust and why should it be used for new projects" when we're hiring for someone to work in rust.

A more senior person would obviously get more generic options. The one I personally spoke about was roughly "What can we as a company be doing to empower software developers to create the best software possible".

The question posed in this thread was "interview experience better for applicants". I stand by the point that presenting:

* in a formal setting,

* to people you don't know,

* with a high stakes outcome (performance determines whether you get the job)

Is not neither a skill that developers need to have, nor is creating a "better experience for applicants". This is in no way analogous to giving an update at standup.

I've had applicants physically shake during interviews when I'm doing my best to create a comfortable environment. Some people just get really nervous. And when hired those same people have become comfortable quickly and performed well in their day jobs.

I would rather say it’s an awesome skill to have, especially if you have ambitions to move to higher levels (lead, management, director) but not a crucial one to a strictly ‘technical’ person. I know guys who are senior devs for 20+ years and they want to code until the rest of their career. They are good developers, but usually someone else is the leader and ‘talker’ of the team.

This is the normal approach in a lot of other fields. I'm still floored it's not more common in tech.

I've done a lot of both traditional interviews (presentation on research or previous work followed by 1:1) and "tech" interviews (coding challenges and whiteboarding) from both sides. Tech-style interviews evaluate a much narrower swath of skills are are much more easily gamed.

I feel that a presentation evaluates broader things: how well do you communicate and how comfortable are you discussing and answering questions about a topic you know well.

It's a better indicator of job performance, i.m.o.

We have people do a 30 minute presentation on anything they think we might find relevant. It is a really great way to start off a day of interviews with a candidate. It is a great self-introduction and a great stimulus for meaningful interview questions.

Our group hires people in the software+hardware+mechatronics space, and we look for people that bring diverse skills we don’t yet cover well. The kind of person we want can teach us something new in 30 minutes, and a good project for that could be backyard hackery or university research. Either is good. I totally love the format. (Then again, I am a “Talk is cheap. Show me a working (even if janky) robot.” kind of person.)

Related, a former BioMed engineer coworker said Medtronic used a similar process - start the interview day with a presentation.

SpaceX is the only company I have interviewed with that does something like this, there is a 30 minute presentation followed by a technical q&a and then 1v1 interviews with the team.

This approach is really common in academic libraries, but there candidates typically only get one topic so they can be more easily compared with each other.

Reply on news.ycombinator.com