Adam White

Here is the feedback that I received from the TASSQ board on my presentation. All the feedback is anonymous so I can’t track it back to the people who said it.

 

It is interesting to read some of the comments as they often tell you more about the values/ideas of the person commenting than on the subject that are actually commenting on – my presentation in this case.

  

Total attendees	Surveys completed	Additions to mailing
61 (including speakers)	42	5

 

Needs                                                                                Exceeded

Improvement                                                         Expectations

	1	2	3	4	5	Null
Presentation was well organized		2	9	28	3
Appropriate level of detail		3	13	22	4
Relevant to your job		8	8	19	5	2
Clearly presented	1	1	16	19	5
Speaker’s knowledge on subject		2	7	24	9
Speaker’s presentation style		3	13	21	4	1
Overall rating for tonight’s meeting		2	12	22	3	3

 

Comments / suggestions

Each bullet represents comments from a single evaluation form, in no particular order,

with editorial comments in italics:

 

·         Too junior (Comment on: Relevant to your job).
When Adam went to Disneyland, did he ever get off the Roller Coaster? He sounds like he loves to on the edge, like a train wreck waiting to happen! Some good ideas but it is high risk and/or more experience then required.

·         One of the slides was useful, “What we are looking for”.

·         Very knowledgeable and passionate speaker

·         Question period was more relevant than the presentation content

·         Very refreshing topic. Speaker needs to polish his presentation, especially the “Ummm, Ummm”

·         Very informative

·         Do your filing, paper work after the presentation. It was distracting when the reception desk was managing paper work

·         Excellent Q&A session

·         Very useful topic

·         I enjoyed this. Even though I’ve done this before, I learned some new “tricks”

·         Seemed uncomfortable or nervous (Comment on: Speaker’s presentation style)

·         Very candid and personal experience driven discussion (Comment on: Speaker’s presentation style)

Back In March back I did a presentation called "Hiring The Next Generation of Skilled Software Testers". I presented to a testing group called TASSQ. I believe the attendance was between 50 and 70 people. This is the biggest crowd of strangers, that I didn’t know, that I’ve ever presented to.

 

 

Overall, it was a great opportunity for me to build my personal brand. I learned much from it. I had a great  turn out from my support group which included my whole team and Neetu (my girlfriend). They gave me some great feedback on my presentation and my style which I will incorporate into my next speaking opportunity.

 

I’m going to also post the feedback that I received on the presentation.

I’ve been attempting to assess the troubleshooting ability of candidates that are applying for techincal testing postions at my company. I’m having mixed results so I’d like to ask a question.

 

How do you establish whether or not a person has raw troubleshooting ability? How do you tell from an interview  that when you put a person down in front of a real world problem they will perform proper root cause analysis and come to the right conclusion. No worries at this point about speed.

 

I’ve given candidates black box testing machines from workroom productions. http://www.workroom-productions.com/black_box_machines.html The machines let me see how the candidate approach problems and basic testing techniques. We have a two way discussion and work through the examples together

When the candidate comes in I expect a certain level with familiarity with basic computer troubleshooting. During screening and in person interviews I ask basic computer and network troubleshooting questions which weed out some candidates (more than I expect) but I’ve found that just because the candidate gives an adequate answer does not mean they have raw troubleshooting ability when they are hired. Between the questions and the testing machines there is something missing. I need something more.

 
I’m trying to figure out what is missing between troubleshooting questions and the testing machines. Using these methods doesn’t really tell me anything in terms of real world performance. I’m finding this especially tricky with senior people because there is underlying assumption on my part that because they are senior their troubleshooting skills are top notch. (whether my assumption is wrong or right is another debate). I’m also working under the assumption that the candidate knows they are applying for a technical testing position (since I think it’s pretty clear from our product info on the website) where they will be dealing with operating systems at a low level and not at a browser driven business logic level.

 

If you have any suggestions on techinques you use or any tips the help you in your interview process I’d love to hear about them.