> You seem like a smart person, who hasn't done very much coding. That makes you a bad risk,

Assuming Microsoft actually measures this stuff, that's kind of surprising to me. I've never placed much weight on being able to write a program on the spot.

>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.

Oddly, I had the exact opposite experience interviewing at Microsoft.

I blazed through all the questions the manager asked, and the manager told me I was the most talented person he'd ever interviewed and would definitely get the job, and then I didn't get the job, and got no further feedback. It was the most confusing interview process I'd ever been in.

I sent him to ask him if there was some sort of mistake, and he didn't even reply directly, just sent me back a message through the recruiter saying no, it wasn't a mistake.

Yeah, big company, lots of variation in the interview process. Ultimately, the hiring manager has final authority, but if someone came out strong against you for some reason, they might be loathe to override. But it does sound like a strange experience. Just consider it an anti-loop. (https://steve-yegge.blogspot.com/2008/03/get-that-job-at-goo...)

How'd you do on the interpersonal questions?

It was ten years ago so I don't remember. I don't remember anyone disliking me or anything, though.

Nice experience, thank you for sharing.

Luke Hohmann, author of The Journey of the Software Professional, advises to give such feedback. I've endeavored to do so.

FWIW, though I've been insulted and hazed and ghosted many times, I've yet to be given constructive criticism.

A few times I've been told why I didn't "pass". One guy was upset that I didn't favor aspects (a la Spring). Another was disappointed by my answer for how to resolve a hypothetical impasse ("try both").

That sort of thing.

Job interviewing is just dating. I accept that most people can't articulate why it's a "No." But I can't abide by the tortured rationalizations of poorly socialized geeks and accompanying general purpose meanness used to mask their own inadequacies.

Said more kindly, most people, and especially geeks, shouldn't be allowed to conduct interviews unsupervised. It's a teachable professional skill like any other. Asking the unprepared and unsuited is just cruel to all parties.

I find I'm much more comfortable giving feedback to new college graduates. Often times there is glaring weaknesses they can work on improving to get the best job possible.

I find that reply a bit puzzling. It was an internship, how bad of a risk could that have been?

It’s actually kind of a bit risk for the applicant, which makes it a big risk for the interviewer if you have half a heart.

If you get fired four weeks in to your internship, because no amount of coaching from the senior employees is worth the investment by the company.... that’s a tough situation to be in. It’s pretty late at that point to start looking for another internship for the summer.

And if you’re the kid’s supervisor... that’s not a fun conversation to have.

Oddly, I had a slightly opposite reaction to a similar experience. But, to be fair, it was mostly because of red tape. I interviewed at Microsoft, got feedback something like, "you did pretty good, but you dont understand low level code enough for this team, you could do great somewhere else at the company." Microsoft has a policy that you can interview only once per year. I didn't get to pick the team I interviewed for, and apparently they only interview for their own team. So, I was basically told that I was good enough, but because of HR, I won't be hired. That, for me, felt significantly worse than "sorry but you didn't get the job" generic feedback would have been.

> Microsoft has a policy that you can interview only once per year.

Wonder how long ago this policy was in place because when I interviewed last year I was able to interview with multiple teams.

Coding “challenges” are absurd.

The gotchas are ridiculous.

If an interviewer googled the question - why do I need to know the answer?

I recently had an interview and I spent _literally_ over an hour trying to figure out the algorithm or a mathematical function to solve it and I finally got to the point that I gave up.

I asked the person what algorithm they used to solve it and they said “brute force” and were expecting nested loops that under real world load would have been O(n^2).

I definitely don’t consider myself an algorithm expert, but my feedback was, and I shit you not, that I didn’t know ruby. I’ve been developing in ruby since 2006.

Anecdotes and all. Our industry’s interview process is flawed AF.

Same here, but from IBM--and it's burnished my impression of the company ever since. It was polite, actionable and a nice recognition that I had /also/ given up an entire day for their interview.