I don't mean to personalize this to you, but your story kinda illustrates one of the problems. There's so much ego and self-worth tied up in both sides of this style of "interview". Both sides have this overwhelming need to show how smart they are.

It's understandable in some ways. It's part of what attracts people to the field, showing off intelligence. I'm guilty of it myself.

But it makes the "interview" process have an adversarial nature most of the time. That's not helpful to the actual goal of hiring people who will make your team successful.

One thing that might work along these lines- Bring in a hard problem that the interviewer doesn't know how to solve and spend some time trying to solve it with the candidate. As a team, discussing different options and problems with those options. You know, like people do in actual work situations...

> One thing that might work along these lines- Bring in a hard problem that the interviewer doesn't know how to solve and spend some time trying to solve it with the candidate. As a team, discussing different options and problems with those options. You know, like people do in actual work situations...

^This guy gets it.

I've never understood why interviews are set up to put the interviewee on edge and make him or her feel out of place, while simultaneously putting the interviewer in a temporary position of ultimate power. Said position does one of two things based on their personality: Makes the interviewer feel superior and aggressive, or makes them uncomfortable and ready to get it over with. Neither situation is good for the people involved nor the process itself. You're basically testing an employee on non-work-related problems under artificial pressure, which is pointless.

And I say all of that as both an interviewee and interviewer in the past.

Candidates naturally feel uneasy when interviewing. In the end, one hour of chatter will either get you a job you kind of desire, or not.

I think it's our responsibility, as interviewers, to make people as comfortable as possible so that they can perform at their best. It's our responsibility to prepare for the interview, smile to the candidate, downplay any hiccup they may have.

I don't believe all the BS about "taking people out of their comfort zone": 98% of people will feel uneasy at an interview and they will be well out of their comfort zone already.

Identical experience. They had me design and implement a practical thing. It was an interesting problem, not something I would normally be able to do in 30 minutes. They wanted it in 30 minutes. After about 20 I stopped coding on the whiteboard and started explaining where I was going with it. It was not complicated, just using a hash to store things, but the removal involved moving used blocks a free list of pre-used slots so the overhead of adding a new costly element was way cheaper. This would beat a binary tree for the scale of elements they where talking about but still easily kept in ram. I am sure they didn't have a clue what I was talking about. I think they wanted an RB tree based algorithm and a more primitive solution. Right after the interview I implemented it and sent it to them. I didn't even get a reply. About two months later I got a survey. This was after three interviews. The happy ending is I have used that bit of code several times since and it rocks. :)

I also drew a complete blank at an interview in a coding problem... and then went home an implemented it (taking quite a bit more time than I'm comfortable admitting ;-) ).

Interviewing is hard (from both sides). Sometimes it just isn't your day. Sometimes it just isn't your job. I was quite depressed when I screwed up that interview because it was the first one I had done after taking 5 years away from programming professionally. I was definitely rusty and I was secretly worried that I wasn't going to recover.

But, in retrospect, I'm glad I didn't get that job. It's a bit like the situation of being asked to TDD building Pascal's Triangle. I am an avid TDDer and I would have a hard time doing justice to that problem. Of course it is easy to get started, but then at some point there is going to be a "and then there is magic" bit because you are trying to test a function that is outputting an infinite sequence. It could make a fascinating conversation, but I think it says alot more about the interviewer than the interviewee.

Unfortunately, just like there a people who look like they would be amazing an amazing hire, but turn out to be so-so (at best), employers are the same. The the 10x employer is probably more mythical than the 10x employee.

Unit test are not just for people who write bugs (parent comment), a good start would be to test for the 9th row the problem was asking for. Since you can't test all possible values a representative sample would be good enough.

Just to be pedantic: It's not TDD if he already wrote the functional code ;)

I think that's the point, though. If I were to build this TDD, I would probably make use of the fact that that the value at any point is the sum of the values above it, in the previous row.

I could write a failing test that PT(1) = [1]. I could make it go green easily, and then write a failing test that PT(2) = [1,2,1] and make that pass, using my algorithm. Depending on how much you did in the last step, there may be no more failing tests that you could write. I can imagine maybe one more failing test, but after that you are done.

That's what I meant by "and then there is magic". The "test driven" doesn't really help the "design" at all. Your first test is the trivial case and the second test is "did it work?" I could arguably skip the first test altogether, and whether or not I wrote the second test before I wrote the production code is completely irrelevant because the test doesn't help you write the code.

Now, you might want to "refactor" this to be:

PT(n) = (n.choose(i) for i in [0..n-1])

(This is just pseudo code for a list comprehension that returns an array of n choose i for all the values of i from 0 to n-1). I could then write the code for choose(), but I'm in the same boat -- there is no benefit to writing choose() TDD because your first test will be trivial and you r second test will require the full answer.

While my "refactor" could use the tests I wrote with my "TDD" of PT(), I haven't demonstrated the value of TDD at all because the "refactor" is not related to the tests. I could just have easily written that code first and then written a test to see if it was correct.

Finally, if a bug is introduced to the code, the tests may pick it up, but are almost certain not to shine light on what went wrong because the tests are not related to the design of the code.

This is an excellent example of code that I would not write TDD (and I write 99% of everything TDD). I might not even write it test first depending on my mood.

Trying to be slightly diplomatic, the point of my post was that in all likelihood, a person who gives you this programming problem to demonstrate your TDD abilities has no clue about TDD. The alternative explanation is that they intentionally picked a problem that doesn't work well for TDD and wanted the person to explain why this was a sucky problem.

If you weren't very familiar with TDD, I could imagine this tripping you up pretty badly. You'd think, "what the hell test am I going to write?" As you point out, it doesn't really matter -- you can write any test that will sort of test that your code can grossly come up with the right answer. After that there's not actually anything beneficial you can do.

To fill in one gap - our hiring process has an extra layer of insulation to better control individual biases. Your interviewers all submit feedback and an independent hiring committee makes the decision, on a different day, with all due deliberation.

The reason nobody has anything to say to you at the end of the day is because none of that has happened so nobody knows what to say at that point, and I don't think it's likely to make you feel better to have somebody give you a completely generic speech that has got nothing to do with you.

As for the more general thing that keeps popping up - do people seriously believe that all the thousands of Google engineers who do interviews haven't figured out that people writing code on a whiteboard under stress aren't the same thing as people sat at their desk grinding out code?

Of course they know that writing code on a whiteboard under stress isn't the same thing as sitting at a desk grinding out code. The problem is that it's pretty hard to sit down all the applicants for a position for a few weeks and work with them long enough to actually get a sense of how they work, and it's quite wasteful for the 95% who don't get the job.

Some companies actually do this, eg. Coinbase requires that you take a week off from work and work with them (I think unpaid, but perhaps you get contractor wages) on a project. They've been widely criticized as exploitative here, with many people saying "Why should anyone who has any choice at all agree to that?" They also open up a rats nest of legal & IP issues.

The best way to get a full-time position at Google - or most companies, really - is to get an intern or contractor position and then convert to FTE at the end. Hiring rates are way higher for successful interns (and the interview process is shorter), because they have lots of people inside with first-hand experience grinding out code with them that goes directly into Google's systems. But getting that internship or contract itself often requires an interview...

Yes, "thousands of Google engineers who do interviews haven't figured out that people writing code on a whiteboard under stress aren't the same thing as people sat at their desk grinding out code?" I am pretty confident they don't know that. I know people way smarter than me who flunked the google interviews and, working in the same building, know even more that got in who are very good but not great. Also, they are ageist and "don't consider experience at all" (and that is from a direct quote from a person in an interview).

Here's an alternative hypothesis: the interview process is selecting for different traits than what you are expecting.

https://www.google.com/about/careers/lifeatgoogle/hiringproc... is a pretty good explanation.

The whole point of this topic is they don't consider role related experience.

> The reason nobody has anything to say to you at the end of the day is because none of that has happened

I just meant typical American (or global?) politeness stuff -- escort your guest to the door, thank them for coming, you'll hear from us soon, etc.

Nice attitude! The fact that your curiousity drove you to figure out the problem long after its solution had immediate utility...that's always a good feature for a programmer.

I once figured out the weakness in my response to an interview problem 3 years after the interview. It was something basic too. Made me feel like an idiot, yet relieved at the same time.