undefined | Better HN

story

0 pointsben5096y ago0 comments

"I need a function to add two numbers together."

Innumeracy is the norm: I'd guess > 85% of people don't understand the concept of a function.

And they probably can code if they were working independently. Or they've done some classes, wathced some videos and think they understand it.

But when you add the pressure of an interview, your unpracticed skills fall apart. Also, you have to think on your feet to fill in the blanks in a question.

That's how it should be, because we're not hiring hobbyists; candidates need to be able to demonstrate that they're pros, and able to do so under the pressure of an interview.

I've done my share of phone screens who were flatly unqualified as developers. (Thankfully we've never had someone completely clueless land an in-person interview. That's also a disservice to the candidate as we should provide better guidance through the phone screen.)

Some of them are junior, possibly they lie on their resume and simply keep applying to job after job. That's the 99% that Joel wrote about[1].

You also occasionally get guys who were in management or similar roles and are looking to transition to being engineers. And I think these may have a similar problem to the senior engineers: they have lost the skill (or never had it) and are finding out the hard way.

[1]: https://www.joelonsoftware.com/2005/01/27/news-58/

0 comments

rhombocombus6y ago

I simply can't get behind the idea that having someone whiteboard an algorithm is analogous to either their programming skill or their ability to work within a company. I spend a minuscule fraction of my time writing algorithms in my daily practice, most of my time is spent integrating disparate technologies, data wrangling, and working across teams to get the information I need to make our product. Clearly there needs to be some vetting of someone's skill, but problem solving and troubleshooting are way more valued skills in my group than the ability to write a fibonacci sequence on the whiteboard. I have had far better success asking questions around diagnostic process and troubleshooting to find talented devs than I ever did using whiteboard like tests.

ben509OP6y ago

> I simply can't get behind the idea that having someone whiteboard an algorithm is analogous to either their programming skill or their ability to work within a company.

It's not an analog. It's the actual skill up close. They should be explaining their thoughts as they go, and you're asking why they do A instead of B.

> I spend a minuscule fraction of my time writing algorithms in my daily practice

A good problem isn't simply an algorithm, but also tests how they break a problem down, how they compose a solution, how they think through engineering tradeoffs, and how they communicate all this to you.

Consider the difference between an artist and an amateur painter. That the artist has practiced brush strokes is not surprising, anyone can practice painting a lot. What really matters is the artist can take the image in their mind and composing it into a complete scene and then express it all that through their medium of choice.

> but problem solving and troubleshooting are way more valued skills in my group

Is that a good thing? If your group wrote better code, wouldn't they have less troubleshooting to do?

Yes, that's a tautology, but I've worked on code that was kludges on top of kludges. And while kludges can be inevitable, if they persist, it indicates the person doesn't have the mastery to see a better way to express a problem. That's a skill deficit.

When I'm analyzing someone's ability to code, I'm presenting it as a problem to solve. We solve problems by restating them in such a way that the solution falls naturally from the question.

The candidates who can do this well will put together well structured, coherent code, and my team will spend more time delivering features and less time troubleshooting.

j / k navigate · click thread line to collapse