Microsoft changed how it interviews software developers • Hacker News Board

Re: Microsoft changed how it interviews software developers

#151

Post by grumpydba » Sun, Dec 30, 2018, 11:53 PM UTC

JustSomeNobody wrote: post #14

> But the aha moment for me was that not everyone does well in those fast-paced brainstorming sessions. A lot of people (including me) prefer to sit with a cup of coffee and some data and try to think things through. This is me. Hard to get that across in an interview, but once people work with me, they're cool with me coming back an hour later in an email with some thoughts on the last meeting topic. They know and r…

We french have an expression for that: "l'esprit de l'escalier", literally "staircase spirit".

It's meant to characterize people who think about what they should have said/answered only when on their way out, in the staircases.

I think I work this way. Maybe it's a way to ignore my lack of wit, my slow paced brain, and to maintain some self esteem.

Re: Microsoft changed how it interviews software developers

#152

Post by kronin » Sun, Dec 30, 2018, 11:58 PM UTC

0x445442 wrote: post #150

kronin wrote: post #124

Earlier quoted context omitted.

I've interviewed and been interviewing for over a decade. I have had the displeasure of interviewing many people who have very impressive resumes yet when asked how they would judge their skillset in an area, and being told from them that they would say "expert", being shown exactly the opposite when it came time to answer some questions in that area. One data point... Senior engineer that founded the local java user…

> Couldn't code a simple reverse string algorithm You were interviewing senior engineers with Java experience and they couldn't come up with Assert.assertEquals("radar",StringUtils.reverse("radar")); I suspect you were actually looking for the implementation of StringUtils.reverse() and if that's the case then you were focused on the wrong skills.

It's the start of the coding interview. It moves on from there. This candidate didn't even ask if he could use Apache commons, and I hadn't yet specified that he couldn't use a 3rd party library. So yes. He failed on many counts.

1) not asking clarifying questions 2) not being familiar with some well-known libraries 3) not being able to implement a basic reverse string 4) not being able to explain whether or not a simple method was thread safe (with multi-threading experience all over his resume)

I expect engineers, senior or otherwise, to be able to write code. If you can't do that, don't put it on your resume.

If you honestly think implementing a reverse string method is "too complicated"...

Edit: sorry, leaving the response as-is, but I recognize you didn't state "too complicated". You stated "focused on the wrong skills". I posit that an engineer that can't reverse a string, as a litmus test, will be likely unable to solve a more complicated problem.

Re: Microsoft changed how it interviews software developers

#153

Post by dietr1ch » Mon, Dec 31, 2018, 12:01 AM UTC

chillacy wrote: post #127

qls wrote: post #105

Earlier quoted context omitted.

This is a pretty standard linked list question (called cycle detection) – one of the easiest questions on LeetCode. You can use the two-pointer method to just detect if there's a cycle. If you want to find the node that the cycle starts at, you can just walk the slow pointer from the slow/fast meeting point and a pointer to the head of the list 1 step at a time until they both meet (there's a simple explanation for t…

I must admit I didn’t figure that one out till I saw the solution which was a “oh duh” moment. I don’t think i would have ever stumbled upon it without lots of hints during an interview.

The constraints, if correctly stated, can help a lot to figure what to do if you take a look at them closely.

In constant memory there's not that many things to do, a single pointer clearly won't be enough as you can't recall if you already visited the node or not, so `K>1` pointers must be used. If any two pointers moved at the same pace they would be duplicated and the second won't give any information. That and the fact that you can only move forward leaves a pretty constraint situation and acts as a guide.

It's not a bad thought problem, but I guess the fact that it's really unlikely to happen in a real world scenario plays against it (the memory on a hash table is probably way cheaper than the extra reasoning this takes). Also, knowing a bit about the answer is an unfair advantage, it might be more of a test on memory than on reasoning, which makes the problem bad for interviews.

Re: Microsoft changed how it interviews software developers

#154

Post by bicubic » Mon, Dec 31, 2018, 12:09 AM UTC

TheSoftwareGuy wrote: post #141

avisser wrote: post #138

Earlier quoted context omitted.

> taken to working with candidates to solve a bug or feature as part of the interview process This is unethical. How is this anything other than unpaid labor?

A little bit of unpaid labor is honestly fine. Especially since I can’t imagine this being easy to exploit in a way that really impacts a company’s bottom line. It’s like getting a free sample of food at the store, before committing to a full purchase

Imagine being a carpenter applying for a job and being asked to make a small bedside table for free. So the employer can sample your skills before committing to a full purchase.

Absurd.

Re: Microsoft changed how it interviews software developers

#155

Post by twblalock » Mon, Dec 31, 2018, 12:11 AM UTC

seanmcdirmid wrote: post #122

twblalock wrote: post #118

Earlier quoted context omitted.

> HR will be told to give that guy an offer and, optionally, collect a resume to keep on file. No, HR will be told to get that guy into the interview pipeline as soon as possible, so he can go through the same process everybody else does for a similar position.

The sad part is that the generic generalist interview will have nothing to do with X, and if you need someone great at X-ing, might yield painful false negatives or even worse, false positives (since you can’t hire specifically for X).

I would argue that if you’re in a position to be picky you would want to hire experts in X who are also good generalists. One-trick ponies don’t do well after project X is finished and they need to contribute to other efforts.

Re: Microsoft changed how it interviews software developers

#156

Post by borgfriend » Mon, Dec 31, 2018, 12:11 AM UTC

kronin wrote: post #124

mancerayder wrote: post #39

Great, now can Netflix, Google and Facebook do this, too? Not because I want to work in these places, but because they influence everyone else and as a senior engineer in the systems space I feel I shouldn't need to study days or weeks for fizzbuzz sorting algorithms questions that are designed to test comp sci recent grads. I have a proven career, and was never suddenly stumped in a project due to not being able to.…

I've interviewed and been interviewing for over a decade. I have had the displeasure of interviewing many people who have very impressive resumes yet when asked how they would judge their skillset in an area, and being told from them that they would say "expert", being shown exactly the opposite when it came time to answer some questions in that area. One data point... Senior engineer that founded the local java user…

Why do you assume that the person is lying? Why do you start your relationship with your new co-worker on distrust? There is a way to weed out the liars - you hire them and then when it does not work out you fire them. You would be astonished how little people lie on their CV.

They may exaggerate claims - yes, that is why you gave them a call in the first place. But then again you exaggerated your claims in the job posting of which skills are required for the job.

The one thing that I noticed is that only the US companies have this awkward parallel reality 'technical-interview' hiring process. In other countries like Germany or France the interview process is mostly focused on the person and the desire to work for the company and the willingness to learn the skills needed for the job. Just because you fail to answer immediately to a random question it does not mean you are unqualified for the job.

When I conduct an interview I try to only ask open questions like: * What is your favorite IDE? - Whatever the person answers, tells a lot about how he works, what tools he uses, and if he is aware of the common tools * What feature of the new Version of do you like the most? - A) you may learn about some weird feature, b) you can discuss how that feature will improve code * Do you prefer JavaScript or TypeScript (dynamic vs typed language)?

There is no right answer. It is all about how the candidate argues his answer. You learn more about the person and if you can deal with him on a day to day basis (and if he has the brains to think about things).

Re: Microsoft changed how it interviews software developers

#157

Post by tills13 » Mon, Dec 31, 2018, 12:15 AM UTC

whack wrote: post #65

Here's what they are doing, from the linked blog post: > Our dev teams had taken to working with candidates to solve a bug or feature as part of the interview process. It was a collaborative effort with the candidate and the team working together to solve a real problem. Sounds like a great idea. Except it's so variable. What if you get lucky and you get a easy bug, whereas someone else gets something much harder. Le…

It's less about solving the issue and more about how you approach it.

Re: Microsoft changed how it interviews software developers

#158

Post by kleinsch » Mon, Dec 31, 2018, 12:16 AM UTC

mancerayder wrote: post #39

Great, now can Netflix, Google and Facebook do this, too? Not because I want to work in these places, but because they influence everyone else and as a senior engineer in the systems space I feel I shouldn't need to study days or weeks for fizzbuzz sorting algorithms questions that are designed to test comp sci recent grads. I have a proven career, and was never suddenly stumped in a project due to not being able to.…

Netflix already does this. Just interviewed with them for a full stack role. All interviews are dependent on the team, but generally feature less whiteboarding than FB/Google. I did a takehome technical exercise, in person interviews were tailored to my experience. They were mostly about system design, general concepts, and a heavy heavy focus on interpersonal skills. Their approach seems to be:

1. Make sure you actually know what’s on your resume

2. Make sure you have the strategic thinking and interpersonal skills to own the system you’ll be working on

3. Make sure you’re a good match for their fairly unique work culture

Re: Microsoft changed how it interviews software developers

#159

Post by bboreham » Mon, Dec 31, 2018, 12:17 AM UTC

Matthias247 wrote: post #35

billsix wrote: post #30

Earlier quoted context omitted.

In constant time? O(1)?

Isn’t that normally the 2 pointers (tortoise/hare) thing? If yes then I agree it’s not constant time. I personally hate this kind of interview question. It’s one that is easily answerable when one heard the exact question before (in training for interviews). But super hard to answer if not. And it even does not have big applications in practice - in 20years of programming, I never encountered a problem like this. In…

I used to ask this (cycles in linked list) question all the time, and I found it useful as a way to see how the candidate worked through an unfamiliar problem. No-one gave the 2-pointer answer, ever.

For me it wasn’t a pass/fail “do you know the right answer” question, it’s more of a “can I work with this person” question.

Re: Microsoft changed how it interviews software developers

#160

Post by epicureanideal » Mon, Dec 31, 2018, 12:30 AM UTC

m0zg wrote: post #131

smsm42 wrote: post #114

Earlier quoted context omitted.

Though I just realized "regex parser" can mean either "parsing some text using regex" or "code that compiles regex syntax into some kind of data structure but does not actually do anything else". The latter obviously is a much easier task.

It's neither. There's a DP solution for this problem and a recursive solution without memoization (with exponential complexity). The shortest solution I have seen was 18 lines of code.

Please show me a regex parser in 18 lines of code! Even 36! I did this exercise once and it took 100s of lines, I think using C++... but it's been a long time. Maybe it's significantly shorter in Python? But still 18 lines is impressive.