When hiring senior engineers, you’re not buying, you’re selling

Re:When hiring senior engineers, you’re not buying, you’re s... by jlelonm on Monday January 21, 2019 @11:47AM (#18961535)

> Having gone through this myself it has taught me to ask very probing questions, as a candidate, during the interview.

Like what questions? I'm assuming the work you're looking for is more along the lines of "wonderful solutions" as opposed to "task completion" - is it as simple as asking, "How anal are you guys about code syntax and whatnot?" and, "How hard are your problems actually?"

Or is it more subtle than that?

[ Parent | on HN ]

Re:When hiring senior engineers, you’re not buying, you’re s... by austincheney on Monday January 21, 2019 @10:47PM (#18965867)

Here are some I thought of off the top of my head. These are based upon things I actually encountered.

What if I were to provide a solution that executes much faster, requires less documentation, passes test automation, and is a quarter of the code but ignores the framework or standard code style?

The standard DOM methods perform thousands of times faster than other options for interacting with markup. I can prove this with numbers. Code like that is not popular. Will I be allowed to write unpopular objectively superior code?

If I can reduce the application build from 5 minutes to 5 seconds will you let me rewrite the build from Java to Typescript?

A/B testing is a powerful way to determine preferential user behavior and a measured increase in conversion. Will I be allowed to write inward facing experiments to test developer behavior?

What if I provide a function as a solution the makes use of scope and nested functions but offers no support for inheritance?

Is it better to complete a task in 1 hour with original code plus tests or extend existing components with risk of regression and 4 days of effort?

[ Parent | on HN ]

Re:When hiring senior engineers, you’re not buying, you’re s... by handyman5 on Tuesday January 22, 2019 @04:12AM (#18967058)

A couple of these questions would be at least yellow flags for me as an interviewer or hiring manager, as they indicate a strong bias for throwing away existing systems ("ignores the framework", "rewrite the build", "original code").

There's a great quote from Lou Montulli[1]:

> I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.

Those frameworks and existing components most likely have a lot of hard-won experience embedded in them, and I would be uncomfortable hiring someone who did not appear to understand or appreciate that.