A funny thing happened on the way to the whiteboard...

[Michael Ernest]

I couldn't code my way out of a paper bag. It was quite the illuminating experience. And I'm talking I couldn't do s---!

Here's what it was: a series of interviews with members of a development team: the QA testers, the core developers, the systems guys. In two cases they asked me to write some code on the whiteboard, to wit:

a) write a reverse program (e.g., given 'abcd' for input, produce 'dcba' for output).

b) write a program to walk a file system, assuming no restrictions on memory (i.e., make it simple, don't worry about it).

I couldn't finish either. They were really, reallly nice about it. I couldn't anticipate this problem, seeing as I teach and quite often throw ad-hoc code on the board for any number of student questions that come up. If I'm on that day, chances are I never compile twice.

Once I got home, I wrote them both out according to the specs I remembered in very little time, and sent them off just to say, 'look, I *can* do this -- just not on a whiteboard.' And in coding out the solutions, it became clear to me why: I don't write code that way, meaning, from the top down. I write from the inside to the outsides, and I re-factor, and change my own like a dozen f*in times, etc.

These are probably rote tests just to see if I know what I'm doing, so they were forgiving and we concluded, based on the other parts of my interview, that I was rusty. The question remaining was how rusty.

After that experience, I don't think I can fault anyone for memorizing a few of these types of questions. While I never felt nervous in this time, I certainly wasn't in charge, like I am in a classroom, and it had a major effect on my ability to think in there. I would not have guessed that ever, as self-confidence in a group like that is not a weak point for me.

If I had one comment to pass back to the interview team, it's that each section seemed to start out with the hardest question first, followed by some that were so rudimentary they surprised me. Another good reminder that it's really easy to overthink the question offered -- I did this on almost every opportunity today.

Just thought I'd pass some notes out there. Someone who claims a decade of experience with Java and a book to his credit and can't write a reverse program off the top of his head -- woo. Embarrassing.

[Mark Herschberg]

Michael, thanks for sharing such a personal story. It's one which will be sure to inspire future job seekers who also encounter an occasional setback.

--Mark

[Sameer Jamal]

I remember one of my college professor sometimes he couldnt answer few basic questions, that dosent mean that he was not good but remembering basics after a certain level I think is difficult.

[Manish Hatwalne]

Thanks ME for sharing all this!!!

- Manish

[Michael Ernest]

My pleasure. Just for fun, here are the two solutions I sent back:

public class Reverse
{
   public static void main(String args[])
   {
      int i = args[0].length() - 1;
      
      while ( i > -1 )
      {
         System.out.print(args[0].charAt(i));
         i--;
      }
      System.out.println();
   }
}

Nothing very hinky about that.

The next one might look a little odd at first:

import java.io.File;
 
public class DirFile
{
   private File topNode;
   private File files[];
 
   public DirFile(String rootDir)
   {
      topNode = new File(rootDir);
      if ( topNode.isFile() )
      {
         System.out.println(rootDir);
 System.exit(0);
      }
      
      files = topNode.listFiles();
   }
 
   public void next()
   {
      next(files);
      System.out.println("\n**End of File Walk**");
   }
   
   private void next(File f[])
   {
      int i = 0;
 
      while (i < f.length )
      {
         if ( f[i].isDirectory() )
         {
            System.out.println("\nDir: " + f[i].getAbsolutePath() + "\n");
            next(f[i].listFiles());
         }
         else
         {
            System.out.println(f[i].getName());
         }
         i++;
      }
   }
 
   public static void main(String args[])
   {
      DirFile dir = new DirFile(args[0]);
      dir.next();
   }
}

I keyed in on a) support for dir.next(); and b) the "assume no limit of memory," which I typically interpret as "use recursion, don't worry about the stack." The overload of next() might look gratuitous, but you gotta pass in the starting point somewhere, and dir.next() says it can't happen in the user interface.
[ July 20, 2005: Message edited by: Michael Ernest ]

[Mani Ram]

When I read your post, this is what I thought regarding the first problem

public class Reverse {
   public static void main(String args[]) {
 
   StringBuffer sb = new StringBuffer(args[0]);
   System.out.println(sb.reverse());
   }
}

[Michael Ernest]

I'd call this a 'better' solution if the test centered on Java skills. They just wanted to see me write some code, C or Java, didn't matter. I decided to write a C-like solution using Java to show I could think...well, a couple hours later in my living room, anyway.

Some time this afternoon I am supposed to receive an 'assignment' on email. I get 60 minutes to work on it. I'll describe it here after I'm done. I expect it might be somewhat involved; I'm told no one's ever finished it.
[ July 20, 2005: Message edited by: Michael Ernest ]

[Jay Shin]

public class Reverse {
   public static void main(String args[]) {
 
   StringBuffer sb = new StringBuffer(args[0]);
   System.out.println(sb.reverse());
   }
}

[/qb]

---

</blockquote>



No. Typically, when asked on interview to reverse a string, one of the best answers is the following (it's kind of weird to write this in Java, but it's one of the favorite C questions using pointer):

public String reverse(String s) {
   char[] c = s.toCharArray();
 
   for (int i = 0; i < c.length / 2; i++) {
      swap(c[i], c[c.length - i - 1]);
   }
 
   return new String(c);
}
 
// Write the "swap" method also if they require

[ July 20, 2005: Message edited by: Jay Shin ]

[Michael Ernest]

I like that answer the least, personally. It's not immediately obvious why you're dividing c.length by 2 for a limit test, for example. Why make anyone think about what you're doing? Why assume your interviewer is secretly checking for the most clever answer possible? The conversion to an array then back to a String seems overwrought to me as well.
[ July 20, 2005: Message edited by: Michael Ernest ]

[Jay Shin]

Originally posted by Michael Ernest:
I like that answer the least, personally. It's not immediately obvious why you're dividing c.length by 2 for a limit test, for example. Why make anyone think about what you're doing? Why assume your interviewer is secretly checking for the most clever answer possible? The conversion to an array then back to a String seems overwrought to me as well.

[ July 20, 2005: Message edited by: Michael Ernest ]

Sorry you had to write this in Java, but I was asked the same question on an interview, and the following was what the interviewer was expecting.

The trick is dividing the length by 2 and iterate only half way through the array.

void reverse(char* c) {
   int length = strlen(c);
   char temp;
 
   for (int i = 0; i < length / 2; i++) {
      temp = c[i];
      c[i] = c[length - i - 1];
      c[length - i - 1] = temp;
   }
}

[Michael Ernest]

Oh sure, I know what you're driving at. These "expected" answers function as shibboleths. The real test is not what you say but how you say it.

When I was angling for that kind of thing as a tech interviewer, I followed a specific pattern that would work like this:

1) Code a program that takes 'abcd' and outputs the reverse

2) Now, revise the program to reverse any string passed to it

3) Now, revise the program to deal with a long string in the shortest number of steps

A good technical interviewer, in my opinion, wants to assess the ability of the candidate by degree. By a staged approach of questions, I can test:

- Ability to follow directions
- Ability to cope with additional requirements
- Ability to learning something along the way

Plus you leave yourself open to other possible answers.

One of my questions had to do with how best to test performance on the outer and inner regions of a disk, without knowing what file system type was in use, and without knowing how the physical disk was organized. Long story short, the interviewer had this actual problem and wanted to see how I might deal with it. Afterwards he said "That's not how I solved it. Your answer is more elegant than mine was. I like it better."

And I've certainly had interview responses that ended on "That's not how I solved it." Well, was this a mind-reading test, then?

Your code answer, of course, would have answered "my" three questions all at once. But I wouldn't have liked it right off the top. So in my estimation you know the problem well enough to go right to the all-encompassing answer. Now I need another test, becase I want to know how you think and learn, not just what you already know.

[Manish Hatwalne]

This is K&R hangover, one silly interviewer wanted me to write it this way 6 years ago when I was tested on c/c++ skills. I wrote correct code but not this and he spent 20 mins telling me why divide by 2 solution is better. I accepted that it was another way of writing code, but didn't comment on "better" aspect. I got selected after 3 more technical rounds, but when I joined, this interviewer always had a bit of grudge -- luckily I never worked with him!

- Manish

[soniya saxena]

When I read your post, this is what I thought regarding the first problem

public class Reverse {
   public static void main(String args[]) {
 
   StringBuffer sb = new StringBuffer(args[0]);
   System.out.println(sb.reverse());
   }
}

I guess only a lame interviewer would expect that solution.

[soniya saxena]

Jay, I have to agree with Michael here.

Originally posted by Michael Ernest:
Oh sure, I know what you're driving at. These "expected" answers function as shibboleths. The real test is not what you say but how you say it.
.
.
.
Your code answer, of course, would have answered "my" three questions all at once. But I wouldn't have liked it right off the top. So in my estimation you know the problem well enough to go right to the all-encompassing answer. Now I need another test, becase I want to know how you think and learn, not just what you already know.

[Jay Shin]

Originally posted by Michael Ernest:
The real test is not what you say but how you say it.

Sorry about that. I agree with you on this too.

[Mike Gershman]

It's not unusual for your mind to go blank under pressure. You'll do much better after a few interviews.

As for using StringBuffer.reverse(), I always understood that it was better to use core library methods rather than recoding them yourself. They won't have bugs. They were optimized by people who thoroughly understand the compiler and execution environment. They are immediately understood by the next programmer who looks at the code.

The worst thing that would happen in an interview is that you are asked to do it again without reverse().

The problem with Jay's answer is that it's the kind of algorithm where it's easy to make a hard-to-spot fence post error. Unless this method is a big piece of a high volume application, it's not worth the risk.

To illustrate my second point, here is the actual Sun code for StringBuffer.reverse()

public synchronized StringBuffer reverse() {
if (shared) copy();
int n = count - 1;
for (int j = (n-1) >> 1; j >= 0; --j) {
    char temp = value[j];
    value[j] = value[n - j];
    value[n - j] = temp;
}
return this;
    }

Notice how the author (charter Java programmer Arthur van Hoff) used a shift instead of a divide by two and took two subtract operations out of the loop? This may or may not matter depending on how javac and the jvm work. The author is in a position to know.

So if I were still hiring programmers, I'd take the StringBuffer.reverse() answer every time.

[Ali Hussain]

  
 
public class Reverse {
   public static void main(String args[]) {
 
   StringBuffer sb = new StringBuffer(args[0]);
   System.out.println(sb.reverse());
   }
}

I would give 100% points to this one. This code does not attempt to reinvent the wheel! Keep it simple Sxxxxd

[Michael Ernest]

So the coding exercise went exactly according to my thoughts posted earlier. Four exercises, each adding a piece of functionality to the last.

From a high level, it was really easy to see the progression and to see where the whole thing was going. I was to write a simple program, add a feature, add a feature, add a feature.

Each one incorporate a new command line argument, so the exercise was effectively a test of building in one new aspect at a time, allowing for a test cycle, add new thing, test, etc. So the whole program was clear -- that's the good news.

The bad news was I had an hour. Not enough time to shake off the rest. I produced a working copy of the first two exercises, shaking out little mistakes and bugs I almost never make.

Interesting, how hard it is to relax for these kinds of tests. It wasn't hard, and that was likely my biggest problem. Even today, I was ready for being tested on the spec, certain operations of the VM, knowledge of some subsystem (serialization, reflection, RMI, etc.) And the questions were really simple. Doing it under time was the element I simply did not take into account.

So I'm going to sit down tonight and write 3 and 4, and hand them in for personal satisfaction. The test is over, but I don't want to feel beaten. The only thing that would bother me about this is thinking I did not finish what I set out to do.

[soniya saxena]

Re-inventing the wheel does not apply in this situation. This is an interview where the interviewer is ideally trying to evaluate as to how you can think and not your power to remember crammed up APIs.

Originally posted by Shahid Afridi:

I would give 100% points to this one. This code does not attempt to reinvent the wheel! Keep it simple Sxxxxd