specialdragon

I've found it's always easier to argue your way round to /not/ doing something, rather than the reverse, and in doing so opportunities are lost.

I think you should stand and give the talk. My reasoning is as follows:

If you don't do it, those that could listen to you and learn from you, won't be able to. If hundreds of people are going to be there, a few are going to come away having learnt something they didn't expect to. You wouldn't have been asked if the person asking you didn't feel you had the knowledge to impart. Being shy and introvert is absolutely fine, although this talk sounds like a one off, and then you've done it, tick that box. You either love it, and really find your stride, or hate it, and have a more legitimate reason for Never Doing One Again.

That's my opinion, however, you also asked for advice.

One of the games I was forced to play in school involved the teacher bringing in something horrifically ordinary and covering it with a towel. Us kids would file in, sit down and the teacher would pick one of us, who would then stand up, and look under the towel. They had 5 minutes to create a 15 minute talk on the item. This exercise, which is quite quick, will teach not only how to create a presentation, but will put you in the horrible situation of, "Where do I start?", "I don't know anything about that", "I do know something about that, but there's masses, where do I start?". It'll also teach you to link one section to the next. You've got 5 months - do it as a party game, write a blog. You don't need to give the talk, you just need to write it as though you were.

A pertinent questions here is naturally - How long does your talk need to be?

It'll be interesting to see what the rest of HN suggest, and maybe tell us where it is so people can go and support in person?

When timetotrade were hiring we needed a Java developer. We created a Java program that would compile and even run, but was horrifically inefficient. First task for the interviewee - how would they rewrite it. It had spelling mistakes, a mixture of variable naming schemes, differences in syntax ( brace inline, one true brace ). If just you as the tech guy leading the interview create that test and hand it to the rest of the team you'll have a benchmark. We gave a programming task before the candidate got their foot in the door. I believe we did generation of Pythagorean triples. Once again, we wrote one internally for comparison. Grab the latest version of mono and write something similar in C#.

I don't have any experience with COM objects, I imagine the above would work for them too.

Ultimately it's going to depend on what you want from a successful candidate. If you want someone who lives and breathes work then it's going to be attributes A, B and C. If you want someone outgoing, active, social then you want attributes D, E and F. There might even be some overlap.

Basic questions are going to be - development environment, source control preference, latest languages dabbled with, interests outside programming. Don't think I've had an interview where I haven't been asked at least them.

www.timetotrade.eu