>I've never placed much weight on being able to write a program on the spot.

I don't disagree, and personally I hate in person coding exercises, but if you keep the question simple and allow the candidate to code in their native language, something fizz-buzz like will go a long way in weeding out the people who have languages on their resume but can't code.

At our company we offer two simple coderpad tasks to be done in advance with no supervision or pressure - write a linked list in CPP and solve a simple puzzle in Python. You pay attention to the candidates who use templates, destructors, smart pointers, even if they make mistakes those are the ones you probably want to hire.

> You pay attention to the candidates who use templates, destructors, smart pointers, even if they make mistakes those are the ones you probably want to hire.

Maybe I don't know enough C++ to understand this, but I don't understand why using fancier features would make you like the candidate more when they are making mistakes. Unless you ask them to write a templated linked list, why would you grade them for automatically deciding to write one (and then making a mistake while doing so)?

Trying to understand the thought process here since I have been on the receiving side of some of these "Look I used the cool feature!" candidate programs in Python, and they often make pretty bad mistakes while using said advanced features. That personally marks them down slightly in my estimation, but curious to know your view is the opposite.

Meta: Maybe the problem with hiring via takehomes/code samples is precisely exemplified by the above discussion.

>Maybe I don't know enough C++ to understand this, but I don't understand why using fancier features would make you like the candidate more when they are making mistakes.

It's not about cool features. It's about using the correct modern features which make the code safer and easier to follow.

Templates are a relatively advanced feature but trivial to write for such a case and I'm looking for a candidate who understands containers are typically generic and knows how to add the two lines. I take it as a marker of experience.

There's no excuse other than inexperience or old fashionedness to not use smart pointers.

Destructors are also a sort of minimal knowledge because they show that a candidate thinks correctly about memory management.

There isn't really a score to what we do. And in all honesty the first few times we gave the test I didn't really know what to look for, this is my first time from the other side. But it isn't too much to expect a competent cpp programmer to know these things and I'm looking for candidates who are willing to use the open ended opportunity to flex their muscles, provided their code is well structured and doesn't have severe, obvious bugs. I don't claim that this is perfect but it seems suited to screen for the basic kind of knowledge we look for. These are not entry level positions either.

It's been awhile since I last interviewed at Microsoft, but the only coding I did was on a whiteboard.

The best part about it? I was already a full time employee at Microsoft. I just wanted to switch teams. I still had to do a full interview loop with the team and well... I didn't get the job.

I interviewed several people who wanted internal transfers. People who took 30 minutes to write a function like "write a function that takes an array of ints and returns the largest value". I have no idea how they got hired in the first place.

Yeah, the space of things I can do quickly on the spot from practice, and the space of things I can get really good at after a few hours of re-calibrating, research, and trial and error are worlds apart. If I were hiring, I'd 100% look for people who can self-teach above all other technical qualifications (above and beyond whatever the basic competency level for the position is).

I only get an hour together or a bit more if I'm lucky.

In terms of people I've hired, if they can solve and code things in real time on a white board, then they can definitely do even better with more time and research.

Everyone does better with research, trial, and error. That's not unique. What's unique is problem solving on your feet in a foreign environment. I want those people.

But why? All of my software engineering has been done on my butt in a familiar environment.

> Everyone does better with research, trial, and error.

Better? Sure. Not everyone can go from 0 to competent in a new area within a reasonable time frame.

While you may not, Microsoft's hiring process (as well as others) clearly do.

Right. And like I said, I assume they've measured it. I wonder what the risk difference is and what the nature of the ultimate failures are?

All my info is old on this point, but I doubt that there was company wide measurement here. This was an individual giving their own personal opinion/reasoning.

It's possible the other guy being interviewed seemed like a smart person and had no trouble with the code. If they had to hire one, they hired the one that was less risky.