What We Value in Engineers

It’s becoming less controversial to say that code is mostly best written by machine. Not just todo apps. Real products used by millions of people.

So what do we value in engineers when the engineering is best done by machine?

The interview that still works

My goto technical interview for the past 4 years has been unusual. Though everyone’s doing unusual things now. The interviewing industry has become so tuned and studied and collapsed in on itself that “unusual” is the norm. Anyway. I’ve gotten good results from this through hundreds of interviews. I think it still works today.

I ask the very first problem from Cracking the Coding Interview. Write a function that determines if a string is a palindrome. Whatever language you like. Use AI if you like, whatever editor. No, don’t worry about performance. We’ll come back to that.

Even recently some people will type it by hand because they’re excited to show they’ve done their homework. Everyone knocks it out in the first 10-15 minutes of course.

Then we review it. Maybe I nitpick a bit, I do have opinions after all. I invite them to disagree. They wrote it differently, why?

What this looks like

They share their screen. Maybe they open a fresh file in VS Code, maybe they pull up a browser playground. Ten minutes later:

function isPalindrome(str) {
  const cleaned = str.toLowerCase().replace(/[^a-z0-9]/g, '');
  return cleaned === cleaned.split('').reverse().join('');
}

Me: Why JavaScript?

This is where we go off the rails. Normal technical interviews would give a way harder problem. Then ask them to make it performant. Tell me the complexity. Write some unit tests. Convert it to a class.

I feel for the people doing these interviews. It’s hard. Two full days of interviewing. So many people. They’re likely doing this at multiple companies. Rejection is always a business decision but always feels personal. Truly one of the hardest things to do.

Nope. Why JS?

Almost always I sense a “snapped out of it” here. Which is nice. Suddenly someone is in the room with me. Who is that? Let’s find out.

“Them: Well, JS is easy to run anywhere. I can just open the browser console if I need to test something. No compile step, no boilerplate.”

Now we’re talking. Now I can ask about how they build and why. Do they care about this stuff? Do they have opinions about their tools?

I don’t think caring deeply about keyboards is required to be a good engineer. But if you type all day and you happen to care about the difference between Cherry MX reds and browns? That’s a good signal. It means you’re paying attention to the thing you do all day. Same with editors, same with languages, same with AI tools.

Me: Why the regex?

Them: It’s the cleanest way to strip non-alphanumeric.

Me: Is it? What about someone reading this in six months who doesn’t know regex?

Now they have to defend a tradeoff. Maybe they say regex is standard and any engineer should know it. Maybe they say they’d add a comment. Maybe they push back and say the function name is self-documenting. All fine. I want to see them think about maintainability and have an opinion.

I always try to say they did something wrong that they didn’t actually do wrong. “This won’t handle unicode properly.” It will, actually. Do they know that? Do they check? Do they just believe me because I’m the interviewer? I want them to stand up to me. For themselves. Even with power imbalances.

Something new

Next I find something they don’t know. A language they haven’t used much. A framework they’ve only heard of. I want to watch them learn.

Me: You wrote this in JS. You have much experience with Go?

Them: Some. Not a ton.

Me: Let’s port it. Use whatever tools you want.

Now the code-by-hand people stop being so proud. They open Copilot or ChatGPT. They paste in the JS and ask for a Go version. This is the job. This is exactly what they’ll do on day one when they need to touch a service in a language they don’t know.

func isPalindrome(s string) bool {
    var cleaned []rune
    for _, r := range s {
        if unicode.IsLetter(r) || unicode.IsDigit(r) {
            cleaned = append(cleaned, unicode.ToLower(r))
        }
    }
    for i := 0; i < len(cleaned)/2; i++ {
        if cleaned[i] != cleaned[len(cleaned)-1-i] {
            return false
        }
    }
    return true
}

Me: Ok. How do we know this does the same thing as your JS version?

Some people stare at it and try to read the Go. Some people immediately say “I’d write a test.” Some ask the AI to verify it. Some actually run both versions with the same inputs. All of these tell me something.

Me: The AI gave you this. Do you trust it?

Them: I mean, it looks right.

Me: What’s the rune type?

If they don’t know, do they admit it? Do they Google it? Do they ask the AI? Do they pretend they know? The engineers I want to hire say “I don’t know, let me check.” Or even better: “Why?”

There’s a million interesting directions this can go from here. I usually let their interests and curiosity guide us. Two primary paths though. Either they find out I know something they want to know and I get to teach and see how they learn. Or vice versa.

The actual job

Feedback I’ve gotten from folks hired through this process: it’s the easiest and scariest and most painful and enjoyable interview. I agree! Software engineering is a lot of things.

The job is not typing the correct string of characters on a keyboard. It is interpersonal communication. Ability to discuss tradeoffs. Standing behind your work. This has not changed.

There’s a big caveat to the title of this post. What engineering is done by the machine? The engineering we tell it to do.