Coding interviews and TDD

[Marcus Milanez]

Hey guys,

I'm currently participating on an interview process for this big U.S company. The process is not similar to anything I've ever done in life here in Brazil, from difficulty levels to how and why they found me.

Until this moment everything happened remotely, where I first had to get some HR questions answered, later my updated resume has been asked, and after that I had to resolve in Java, within 60 minutes, two exercises that in my opinion (and according to my skills) were extremely difficult. The problems were heavily based on mathematics and algorithm skills, and to be honest, it has been quite some time since I had to create a binary tree with my own hands/ideas, or find the shortest path between to different branches in a graph.

Although I knew some bugs were present, I could successfully get the mandatory test scenarios pass, and I could also promote some nice code refactorings before I mailed them the answers (again, I must publicly thank Uncle Bob and all the fellows behind Clean Code and CleanCoders.com because that material drastically changed my development skills, although I know that there's still a long way ahead) and the result is that I've been approved. The next step is a 6 hour in-person interview that is about to happen in the end of February, and as far as I know, this last stage involves writing a lot of code in a white board, following the same difficulty levels requested remotely - binary trees, linked lists, breadth first search and so forth...

One thing that still bothers me though, is the fact that although I did write a single unit test per problem, to check whether my solution was correct or not, I must be honest enough to say that I didn't use TDD. I was so concerned about how difficult those problems were, and how short the window of time was, that I started thinking that I wouldn't have been able to get them solved if I started following a TDD attitude. I'm not defending what I did, and in fact my decision still makes me wonder why I did that, but the fact is that for some reason I thought that under that huge pressure, TDD would slow me down (furthermore, I still don't know how to TDD heavily algorithmic base stuff like BST or BFS) ...

If that happened to me during an interview, that can possibly happen to me during a regular day of work. I never thought TDD should only be used during moments of calm breezes, but I never thought that I would completely ignore it during that terrible storm!

Since my current masters research is heavily based on the psychological and economical effects of unit tests in software development projects, I would like to once again here your opinions about what has happened to me. Would you guys do the same? Do you think that I could definitely accomplish the same objectives by using TDD as well? Is it possible to TDD heavily algorithmic/mathematics based stuff like that? Talking coding in white boards, is it possible in any manner to TDD code written in a white board?

Thanks in advance!

--
Marcus Milanez
http://theordinarydev.wordpress.com

[Tim Ottinger]

You can win and you can lose. It's gambling. 

If I could just "write the answer" and do it perfectly, it would be faster than doing TDD and this is what that old Left Brain Interpreter likes to tell us we can do. Data suggests we cannot. Experience also suggests that our mental plan may often not be the right thing to do ultimately. Unit testing after-the-fact adds some safety, but with a lot of effort.

TDD is of course going to give us the best blend of safety, speed, and opportunity to steer.

But when a friend and I decided to race to see who could write a word-counter faster, I didn't TDD it. It struck me as strange that I didn't, but the deal was "fast and I win" and "errors are forgivable here; worse case I lose and nothing is on the line".

So I did an experiment. I had people do an exercise with TDD and without. They could try either one first. 

If they did non-TDD and got it right, it was up to 40% faster. However, if they made any mistakes along the way, it easily took double the time that the TDD code took. 

Assuming a whopping 40% faster completion when perfect,  and only 200% slower when failed, in order to break even on 10 simple 2-hour tasks, I have to be perfect without TDD 60% of the time. That sounds reachable (that darned LBI again!).

OTOH, all of those cases build without testing are not "naked" code, and will give no indication of failure if they are broken by subsequent changes. This perpetually reduces the chances of me being able to make a perfect, fast change in the future. The game is a clear loser. The worse 

But what if there is no future, and I'm pretty certain of my solution, and my success does not really totally hinge on the success of this piece of code (i get partial credit for thinking well, coding pretty, trying hard, etc)? 

I think that it's not an ethical failure, it is just a statement on the operation of chance-taking part of the human process. We sometimes go for the risky win instead of the safe bet. 

Tim

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Tim
----
http://www.industriallogic.com/

[Dereck Haskins]

Yes, this is a hard choice and a gamble. I definitely lost out on a job interview doing TTD once. I didn't finish the whole assignment and I could tell afterwards - they'd already flipped the 'bozo bit'. I'd be unable to advise u what to do, but Good Luck!

[Raoul Duke]

one interview where i wrote up some small test cases on the whiteboard
first before any code, really seemed to blow away the interviewer, and
i was in like flint. of course, most other places, it hasn't been
clear if it mattered or impressed or anything or not.

[Steven Smith]

You could always ask. "Would you like me to solve this problem using
TDD, or is that not something you're looking to evaluate here?" The
worst that will happen is they'll say "Use whatever you think is best"
and you're no worse off than before. And if you go the TDD route, and
they disagree that that's "best", then maybe they just failed your
interview of the organization...

Remember, interviews are two-way.

Steve

> --
> You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
> To post to this group, send email to software_cr...@googlegroups.com.
> Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--

Steve Smith
http://Ardalis.com/
http://twitter.com/ardalis

[Raoul Duke]

> You could always ask.
> Remember, interviews are two-way.

(i'd instead phrase it as interviews are a fuster cluck. or, that one
should not be put off if the interview doesn't work out, since
everything is very subjective and people are all very different. i've
been in interviews where it really felt like just asking that question
was enough to tank it, there was that feeling, that oh we're short on
time just write some code already you ivory tower tdd'r.)

but, yes, overall, i believe what you say, and will take it to heart.
if people don't want me asking such a basic thing of course that is a
good data point for *me*.

:-)

[Doug Bradbury]

Thanks Marcus for the great story and great question.

I have one thought on principles and practices.  I really think my commitment to a practice like TDD is revealed when the pressure is really on. These are the moments when I really find out what kind of coder I am and what I really believe about writing good software.

As to why TDD is a practice I always lean back on, I think it is because it gives me quick and consistent feedback.  As we are making something like software by hand, we need to see right away how our last changes effects the final product.  TDD gives me this hand-eye feedback.

Can you TDD difficult algorithms? Yes. Even if I know the algorithm I am trying to implement (say like A* for path finding) I will break the problem down into piece that I can TDD (say the "f" calculation for two adjacent nodes), then put it all together with higher level tests.

Asking people to code at a whiteboard makes about as much sense as the hand-written coding tests I took in college. It's like asking a woodworker to use a saw with a blindfold on. There is no hand-eye feedback. Somebody is going to lose a finger.  Take heart though, usually people will put that in an interview simple to see you how you deal with stress.  They don't often actually care that you can get the solution right, just that you can stay calm and keep thinking about the problem.

Good luck to you!

Doug

On Thu, Feb 7, 2013 at 10:34 AM, Marcus Milanez <mmil...@gmail.com> wrote:

--

[Marcus Milanez]

Doug,

Thabks for your great advices! I'm stydying a lot and trying hard to remember things that I used to do in college, like quicksorting an array without using existing libraries, because I strongly believe that the opportunity I have in my hands right now, only hapoens once in a life time. 

I agree with you that white board stuff tends to analyse other aspects of coding, because I don't think intervieers will be able to compile the entire code in their minds. However, since these are the rule of this game, the best I can do is be as prepared as possible!

Thanks again! I hope I an share some good news with you guys at the end of this month.

Marcus

[kelly french]

>> So I did an experiment. I had people do an exercise with TDD and without. They could try either one first.

 

You gave the results of those who did not use TDD, what were the results for those who DID use TDD?

[Tim Ottinger]

The same people did TDD and also skipped TDD. They did with and without.

I held TDD-ing as the standard (the 100%) mark.

If they did a perfect job, it was up to 40% faster than TDD, but it left them with no tests at all. None of them did the work and then came back to do the testing (AFAIK).

However, most of them did not do a perfect non-TDD job and that left them using debuggers and chasing down problems, and it took them at least 200% of the time.

So I would say that TDD is clearly the safest way to go, and the most consistent.

If the work is not a quick hack on the side for fun, but something you are going to continue working on for the next few weeks, months, or year, then not doing TDD is somewhat irresponsible.  

Tim