That said, sometimes diagramming things or writing down pseudo code is very helpful. It forces you to think about the correctness of your solution and the design, rather than the mechanics of making the thing run. I still have trouble reading long sections of code out of books, though, which is odd after all this time.

I have a bad habit of writing just enough stub code to test, and then alternating between testing and adding slightly more code. That's good in some cases, but I think I'd be more efficient if I programmed bigger chunks at once.

Either way, you should not count lines in a file with a one-liner like this, even if it's shorter. It frightens people:

perl -pe "END{ die }" file_name >/dev/null

Having your enviroment how you like it is very important. I have the small problem that my environments are different at home, work and Uni. Although I do use X at all of them with the same window manager (WindowMaker) so at least there is some consistancy there. I'm starting to think that it might be time to bring them all inline with each other. At work I use wterm with a transparent background, I'll probably change it to a solid background this week since it can be difficult to actually use (looks cool though!).

On your comment about how you write code I'm starting to believe this is a good way to do things. I've just found out about Extreme Programming and this is part of what they suggest. Although, the test cases should be written first... You might be interested in XP, it's kinda cool.

Cheers!

Not that long ago one of the managers where I work came by my desk and asked me if there was an easy way to count the number of lines in a file. He wanted to do this on an NT box, which didn't have CW. So I grabbed a pen and started writing Perl on my white board.

# First draft:
perl -we "@ARGV=qq'\42file name\42';1 while <>;print $.,$/"

# Quick, grab the eraser, that sol'n is too long!
# Second draft:
perl -we "1 while <>;print $.,$/" file_name
[download]

Part of the difficulty with writing out code (on paper or on a whiteboard) for me is that I type much faster than I write. My output buffers get filled very quickly with writing code down by hand and things get all jumbled up since ideas are flowing faster than they can come out. Mediating this process takes practice.

OTOH, I can draw pictures by hand much faster than using any sort of software to do so. (That's primarily because I haven't taken the time to learn packages like visio or dia or whatnot properly.)

Writing on a whiteboard is also a different experience than writing on paper, even if you're by yourself. You need to remember to keep the pen point slightly downward so the ink keeps flowing, and to write bigger than normal so other people can understand you. These sound like a stupid, small things but writing is something that's been drilled into you though rote from such an early age that picking these things up can be tricky, particularly if you do it infrequently. (People who attend lots of meetings are pros at this -- one of the best persons I've seen with a whiteboard is fellow perlmonk clemburg.)

I often write code to solutions on paper or white board just to see if I can do it that way. I don't get it right every time, probably 50% of the time. I also try different complexity levels.

My reasoning for this is varied from most peoples. I love to teach. Right now I just answer question among my peers like at this site or at my workplace, however, I'd like to be a consultant some day, similar to what merlyn does.

I practice on the white board so I can correctly answer question about code on the fly, similar to your problem.

I wouldn't question my knowledge of the subject, I would try the most simplified solution that I'm >= 90% sure will work.

--
Casey
   I am a superhero.

My next software job was a transfer from a writing group at Tektronix where I'd been leading a team of people documenting operating systems, compilers, assemblers, and debuggers (and met the famous "Lyle" and "Jack" attributed in the preface to my books), into being a software project manager for the group my writing group had been documenting. Again, no demonstration of my skills were required, as the group had had enough of me coming in to their specification phases and finding holes. {grin}

My first contracting job as Stonehenge was for a body shop that had badly blown a client's database implementation, and needed me to give a second opinion on how badly their first contractor had sucked (the client already having the first opinion). I was highly recommended by my software contractor friend, and therefore didn't have to demonstrate anything again. That cycle was repeated once again at another firm (demonstrating how much the previous guy sucked and why). (As you see, I have many years practice at code review. {grin})

After that, the next proper programming gig I got was working for a large chip company with some offices in Phoenix, who had advertised in 1994 for "someone who knows some Perl" to work on the now-ill-fated Iridium project. To which I replied "I know a little Perl; check the back of Programming Perl or Learning Perl for my brief resume and let me know if that's enough". Bingo, got a year-long gig from that. Again, no demo required.

At this point, with a 22-year resume, if someone asks me to demonstrate my coding ability, I'll probably just chuckle, and move on. {grin}

-- Randal L. Schwartz, Perl hacker

I can certainly understand your saying that you would move on if someone wanted you to write some code during an interview. There does come a time when something like that becomes not only trivial, but insulting.

May I reach that point some day... *sigh*

Roy Alan

I went job hunting some time ago and was not tested anywhere, although I expected to be.

Where I work, I keep a 'lab.pl' on every server/workstation that I come in contact with. It's basic make up is:

#!/usr/bin/perl -w
use diagnostics;
use strict;
$|++;

use Data::Dumper;

__END__
[download]

With that in a file with 700 permissions, I can almost work up to the "any time, anywhere" level.

If a co-worker asks me a coding question, I can mock up a demonstration at a terminal and teach them what I'm doing as I code. This is very handy.

And if there are errors, I just talk through them till I have a working model, then I can mail them my file and they have an example to keep.

--
Casey
   I am a superhero.

Yet, I love whiteboards for designing on, it's so easy to scribble stuff up and link things together. I also find it can easier to write small programs in it. I did one last week for a friend, I coded up a solution then said "Nope, we can do that better if we add this to here, and swap that around.".

It would probably be a good idea for you to try and get some practice with a whiteboard, they can make things easier - especially if you're designing/writing a system with someone else.

I personally have put interviewees on the spot, I broke a Linux box and they had to fix it. It's a shame, out of 3 people only one person made it past the first problem... We didn't hire any of them. (Those interviews all degraded into mentoring sessions...)

Cheers!

Being able to "program" on a whiteboard is an essential skill in analysis and design sessions. I think it is very valuable to practice this, since it enhances your communication skills like few other things do.

Advantages of whiteboards:

• After discussion, consensus is left on a whiteboard - not fragmented items like on flip-charts
• Whiteboards are "public thinking screens"
• Moving around when working with a whiteboard opens up group discussion (people get more actively envolved)
• Whiteboards force you to work out the code / design in your head
• Very fast to draw on - lots of people "think visually"
• Make differences in what is being talked about explicit

Disadvantages of whiteboards:

• Slow to write on (compared to a good typists speed)
• No perl -de 42 there
• Make people shy since they need to stand in front of other people
• Can be wiped by ignorants without you noticing (easy: take a digital camera and make a snapshot)

So, all in all, if you are working in a team, you need whiteboards. If you are working alone, it depends on your style of personality.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com

Unless it is a whiteboard which runs Perl, it isn't really an environment :) Personally, I haven't been asked to do any code in an interview (I make sure I send examples and a link to CPAN before going in), but have been asked to do pseudo-code and flow charts.

I think if I were asked to write actual code on a whiteboard that were more than any simple one-liners or few-liners, I would say something like "When I code I am generally on a computer. Writing code an a whiteboard is like taking a bath in the kitchen sink.. not the proper place to get it done correctly."

I must say, I found the whole thing disconcerting, and I'm not sure what it says about my grasp of what I know.

You know what you know! Interviews can be stressful as it is without pop-questions which you need to answer on a white-board in front of people which you do not know. But, being able to write code in an editor other than vi would be useful, in case it isn't available to you at some time.

Cheers,
KM