ࡱ> M wbjbj== WWpUEl    " j&j&j&8&t'" ',(,,,1a5 m6̔ΔΔΔΔΔΔ$ t- 6 11669 ,,49996* ,( ,̔96̔99<0 T ,' 'T," Hj&8v,PS<|l!8!9" "   Interviewing Software Developers   EMBED Package  Table of Contents  TOC \o "1-3" \h \z \u  HYPERLINK \l "_Toc204189859" 1 Introduction  PAGEREF _Toc204189859 \h 3  HYPERLINK \l "_Toc204189860" 2 Developers as employees  PAGEREF _Toc204189860 \h 3  HYPERLINK \l "_Toc204189861" 3 Interview general approach  PAGEREF _Toc204189861 \h 3  HYPERLINK \l "_Toc204189862" 3.1 Dialogue not inquisition  PAGEREF _Toc204189862 \h 3  HYPERLINK \l "_Toc204189863" 3.2 Removing the threat obstacle  PAGEREF _Toc204189863 \h 3  HYPERLINK \l "_Toc204189864" 3.3 Or hard ball?  PAGEREF _Toc204189864 \h 4  HYPERLINK \l "_Toc204189865" 3.4 First impressions  PAGEREF _Toc204189865 \h 4  HYPERLINK \l "_Toc204189866" 3.5 Scaling up, & Tests  PAGEREF _Toc204189866 \h 4  HYPERLINK \l "_Toc204189867" 3.6 Preparation  PAGEREF _Toc204189867 \h 5  HYPERLINK \l "_Toc204189868" 3.7 Equal opportunities  PAGEREF _Toc204189868 \h 5  HYPERLINK \l "_Toc204189869" 3.8 Shoe on the other foot  PAGEREF _Toc204189869 \h 5  HYPERLINK \l "_Toc204189870" 4 Assessment  PAGEREF _Toc204189870 \h 5  HYPERLINK \l "_Toc204189871" 4.1 Assessing experience  PAGEREF _Toc204189871 \h 5  HYPERLINK \l "_Toc204189872" 4.2 Assessing skills  PAGEREF _Toc204189872 \h 7  HYPERLINK \l "_Toc204189873" 4.3 Assessing common sense  PAGEREF _Toc204189873 \h 7  HYPERLINK \l "_Toc204189874" 4.4 Assessing intellectual ability  PAGEREF _Toc204189874 \h 7  HYPERLINK \l "_Toc204189875" 4.5 Assessing bravery and confidence  PAGEREF _Toc204189875 \h 7  HYPERLINK \l "_Toc204189876" 4.6 Assessing relationships  PAGEREF _Toc204189876 \h 8  HYPERLINK \l "_Toc204189877" 4.7 Assessing peer relationships  PAGEREF _Toc204189877 \h 8  HYPERLINK \l "_Toc204189878" 4.8 Assessing management relationships  PAGEREF _Toc204189878 \h 8  HYPERLINK \l "_Toc204189879" 4.9 Assessing customer relationships  PAGEREF _Toc204189879 \h 8  HYPERLINK \l "_Toc204189880" 4.10 Assessing lateral relationships  PAGEREF _Toc204189880 \h 8  HYPERLINK \l "_Toc204189881" 4.11 Assessing attitudes and drivers  PAGEREF _Toc204189881 \h 9  HYPERLINK \l "_Toc204189882" 4.12 Assessing delivery  PAGEREF _Toc204189882 \h 9  HYPERLINK \l "_Toc204189883" 4.13 Assessing quality  PAGEREF _Toc204189883 \h 9  HYPERLINK \l "_Toc204189884" 5 Complications  PAGEREF _Toc204189884 \h 10  HYPERLINK \l "_Toc204189885" Appendix A: Interview check list  PAGEREF _Toc204189885 \h 11  HYPERLINK \l "_Toc204189886" Appendix B: Sample Screening Test  PAGEREF _Toc204189886 \h 14  HYPERLINK \l "_Toc204189887" 5.1 Python  PAGEREF _Toc204189887 \h 14  HYPERLINK \l "_Toc204189888" 5.2 Software Engineering etc.  PAGEREF _Toc204189888 \h 14  HYPERLINK \l "_Toc204189889" 5.3 Maths / Physics etc.  PAGEREF _Toc204189889 \h 15  HYPERLINK \l "_Toc204189890" 5.4 Bonus Questions  PAGEREF _Toc204189890 \h 15  Introduction I'd like to share what I've learned about interviewing software developers over the last 20 years or so. Ive gained this experience in the context of managing development in several different companies, so my credentials include living with my staff selection decisions. I hope my observations are instructive and useful to you. Developers as employees I think software developers have a few note-worthy characteristics as employees. The main one in my experience is that their true value to your organisation can vary massively from one individual to another. I would quite comfortably rate true-value variance between the hot shots and the pedestrians as 10:1 quite easily. Of course pay and reward systems are unlikely to reflect this scale of variation, but it does mean that identifying and hiring the special people is extremely worthwhile. I have found a significant proportion of developers to be slightly more eccentric than the population at large, and to have some frankly quite quirky behaviours. In my experience these are no obstacle to doing a good development job and in fact are quite a positive indicator! The typical drivers and motivators for developers are worth a special mention. I think most good developers have chosen their career path because they like doing it. Quite a few do it at home for fun as well as at work. By and large these people have choices about where they work. You may be scrutinising them, but they are scrutinising you and the role you have on offer too. The interview approach needs to reflect this and meet their needs in this respect too. Interview general approach Dialogue not inquisition I think its pretty difficult finding out the things we want to in an interview with a software developer. The concepts are not the easiest to communicate in speech, and of course the positions the protagonists tend to adopt can cause all manner of blockages to candid communication. If have found the best general approach is to tap into our mutual enthusiasm for the topic of development and software engineering, and to have some fun talking about it but with a subtle steering process on the interviewers side to make sure the conversation visits the places you intend. Removing the threat obstacle I have found that without some work, our questions will be assumed by the candidate to be a cloaked challenge or probe into some aspect of their personal performance. Which of course can be exactly right. But these questions get answered with a corresponding level of defensiveness and adversarial spirit which helps neither party. So maybe these arent the right questions? Something that seems to work for me to get round this, is to ask the candidate about situations they have observed or been innocent parties to. I find this reveals just as much if not more about their own relevant qualities than direct questioning. Similarly, you can ask them to comment on, or critique the policies that someone else imposed on them about for example code reviews. Youll hear all about their perception of code reviews which is exactly what you want to know. Or hard ball? Occasionally, I have found the comfortable, friendly dialogue just isnt working generally with an extremely self-possessed candidate who is determined and obviously putting on a performance, and not really entering into the spirit of a meeting of minds. In these rare cases, perhaps it is worth asserting the upper hand in the power stakes and applying a little pressure. I find this is where its very helpful to have someone else in the room who can play the baddy leaving your opportunities to resume friendly dialogues in tact. Try to break the act and then work back to a more constructive dialogue again. First impressions A trap I now recognize from having fallen into it, is forming a too favourable impression of a candidate very early in the interview, and that dissolving my critical faculties somewhat. The remainder of the interview can easily be viewed as corroboration of your first impressions. Of course candidates are constantly briefed about this first impression stuff, but perhaps we interviewers need to be more careful about it. This again is where another person being present is invaluable to prick the bubble. Scaling up, & Tests Dealing with detailed technical questioning in a developers interview can be problematic. First of all it is time consuming, and secondly it introduces a false context for the candidate to demonstrate their knowledge and skill. Sure, some developers thrive on the cut and thrust of agile thinking and communicating face to face with someone else. But there are many more I suspect who do their good thinking quietly and privately. I experimented with preparing a test for candidates some years ago, when I had to recruit quite a few people at the same time. And havent looked back since. I was concerned that it would put candidates off, but it has the opposite effect. Candidates have told me that it implied more about what was expected in the job than all the other materials, and that furthermore it was quite fun. I ask potential candidates to do the test at home, in advance, and I use the result to determine whether to interview or not. Usually recruitment agencies like to manage the tests. N.b. I dont believe there is any meaningful risk of fraud associated with allowing the tests to be done in private. You dont need to invest a huge amount of time in developing the test it doesnt have to perfect. I usually find that my questions have unintentional ambiguity which becomes clear, only when you receive a range of reasonable answers. But this doesnt matter, you learn what you need from the candidates answer anyhow. If you have never tried this approach I heartily recommend it. Because you are reading material in a structure that you designed and control, you learn a very great deal extremely quickly. I now always look at the test results before the CV. See Appendix B for one my recent example tests. Preparation I find a check list useful for interviews. It works as an aide-memoir for where to steer the conversation and also helps to marshal what you learn in an interview. I have great difficultly remembering details about earlier interviews once I have interviewed a few people in sequence. I have included a sample checklist in an appendix to this document. Equal opportunities In my 20 plus years experience, women have represented less than about one in twenty applicants for the roles Ive sought to hire for. Even with a level of positive discrimination, I cant see how we can achieve very much about this dilemma at the interview stage. Shoe on the other foot Its worth remembering that for some interviews the process morphs into the groundwork for a selling exercise because you decide in due course that you want to hire the candidate. So we have to bear this in mind from the beginning. We have a responsibility to paint a positive picture of our workplace, but we also have a responsibility to try to find out what the candidate perceives as our pros and cons, and what objections may need to be overcome for them join us. This gives us the opportunity later to be creative and pro-active about handling the job offer process. Assessment This section deals with the attributes we are trying to assess during an interview, and how we can set about finding out the things we want to know. Assessing experience First of all, developing software is not bricklaying. You can't just go out and hire someone who has the experience to just write your software on the day they arrive because all non trivial software presents a very significant learning curve, no matter how well versed someone is in the language etc. Ok you might stumble across a particular expert in your domain, but that is the exception rather than the rule. So the experience we need to probe is the experience of being an effective software engineer per se. Hopefully these sample interview questions below make this clearer. What different approaches to source code branching have you come across - and what seemed to work better or worse? Have you had the opportunity to work with Iterative or Agile development approaches? What happened? Up sides? downsides? The traditional waterfall lifecycles are rather unfashionable at the moment. Is this fair and sensible? (Looking for engagement with continuous improvement and knowledge of the pros and cons of alternatives) Tell me about a bug fix you did recently that you are really pleased about because you found and fixed it really quickly? How about a shocker that soaked up time - or worse still came back again? What lessons were learned in hindsight? (Looking for intelligent application of quick and dirty opportunistic approaches with high bang-for-buck if they work, versus need for systematic approach at other times. Consider your most recent software design. Give examples of design patterns used. What's the point? (Nowadays people really should be versed in these and use them routinely. Too few are. Absolutely must recognise importance of de-coupling and actually do it.) Consider the most recent example of you pair programming, code reviewing or design reviewing. How did it work out? Would you do it again? Would you do it differently? (Looking for genuine engagement with these activities. Beware everybody says they endorse them.) Most people have seen thorough up-front design really pay off, with fast clean successful implementation and tests resulting. Should we always do it that way? Why? Why not? Looking for recognition that design is very important, but consideration over how much to do in what order in relation to development - needs adaptation to each and every development. As a bonus, do you recognize that architecture design should be considered separately from the details and should be sorted up front. Also that it is ok to write code to help develop architectural ideas. Have you used test driven development or more generally unit testing? What happened. Pros and cons. (Looking for intelligent testing approach that fits the projects and development technologies used - particularly with interpreted languages.) Consider your most recent development. What alternative approaches cropped up or were available. How choose? (Looking for recognition that this should be routine thought process. Quite often it is not, with emphasis on getting it to work instead). Consider your most recent development. What did you do in what order. Why? Looking for ability to see importance to tackle the risks early. I.e. the biggest and most consequential unknowns. Assessing skills You will of course want to find out the skill levels of candidates in your languages, OS, and application domain. I have found the quickest and most effective techniques for this in ad-hoc recruiting is to go for straight for the jugular with demanding questions that only highly skilled people will be able tackle and then to backtrack to easier questions if necessary. I explain this approach to the candidates up front. The questions don't have to be that relevant to the work - they are exploring the depth and breadth of the candidates knowledge for the sake of it. For example: In C++ - when would you use private inheritance? In Python - what is a property(), or say list comprehension? In Perl - how do you create constructors for OO programming? In C, what does static do? In Linux, what shell commands could you use to identify files with both name and last modified date constraints. In Windows, what graphics sub-system are there / have there been available? (or class libraries environments) Assessing common sense This can be worth special consideration for this particular candidate group - particularly when considering spectacularly bright individuals. It's usually obvious by the end of an interview how the land lies, but it is a useful checklist item. However I would not necessarily pass over an extremely bright developer if I thought they lacked common sense a bit. But make it a conscious decision. Assessing intellectual ability In my opinion, this is potentially the most valuable commodity by far. The really valuable developers are always very bright, but it certainly doesn't follow that all really bright people are really valuable. Use extreme caution judging this from academic qualifications. (UK experience). I have met plenty of dullard PhDs, and razor sharp thinkers without degrees. In my experience, intellectual ability is usually pretty obvious by the end of the interview - but it's worth a note on your check list . Assessing bravery and confidence This may be an unexpected section? But quite a few software engineers get intimidated and over cautious with large bodies of code, that are stable, in-use, and that have been written by other people. But of course this is the normal situation in development. And someone has got to be brave enough to change this code! You are looking for a mature understanding that yes - there is risk in changing it, but also that radical changes to the code base are also a natural and necessary evolution of your product or technology. Ask about opportunities that have been taken in the past to do this, and what happened. Assessing relationships Try to find out how the candidate deals with the usual challenges in the following relationships. It's no good just asking the direct questions on this one - you have to explore a concrete example from the candidate's experience and talk around what happened Assessing peer relationships First and foremost, accept that quite a proportion of very good software developers are abysmal team workers. They don't like working closely with others, and do not perform well when asked to do so. That's ok. Get real. Go with the flow, and don't use them like that! However its still valuable to know their tendencies. What you do need is good team citizenship. Not breaking other peoples code with their changes. A willingness to provide expert help when needed, and the ability to negotiate with colleagues over priorities and problem resolution. Try asking about a situation when they have needed someone else's help in the past, but that person could not or would not provide it. Did they see the need and value to explore the obstacles, search for mutually agreeable remedies? Could they be assertive without prejudicing the relationship? Did they know when and how to escalate such problems? Assessing management relationships As a manager, you know what you want as behaviours in your team. But does the candidate? When and how to escalate things. What you need to know. And don't want to bother with. How problems should be presented in terms of alternatives and recommendations. A willingness to accept overrulling authority occasionally. Ask about concrete examples of these situations from the past. Assessing customer relationships These are often weak. Does the candidate understand firstly the importance of the difference in customer perceptions and priorities from his own? Secondly, the fundamental importance of satisfying the customer? Ask about the 'imperfections' of his previous customers. Ask about the 'relative merits' of producing a system when it was agreed to, versus a little bit later, but with some great new features in it. Assessing lateral relationships Does the candidate know how to work effectively with sales and support people? What matters to these people, and what does not? Does the candidate understand the dangers and boundaries implicit is some questions. Senior sales person asks junior developer if the software can do XYX. Junior developer says yes that should be possible - meaning he can visualise roughly how the software could be developed to do it. Senior sales person commits company to sale of said functionality later the same day. Catastrophe for setting and meeting expectations. Catastrophe for exercising informed decisions about priorities. Head support person drops by and persuades developer to drop everything to work on customer crisis. But what about the promise you have made to deliver your project by the exhibition next week that requires 100% commitment from the same developer? Every candidate I have met has good and instructive stories about these situations. Assessing attitudes and drivers Candidates will usually reveal their drivers and motivational factors if you ask them to identify the projects they have enjoyed most. Don't expect developers in general to place 'serving the business or organisation' as a key driver. The good ones don't do it for that reason. Get real. They do it because they like it, and a reasonable living can be had from it as a side effect. I've had senior management taking great exception to this, and saying that we shouldn't hire these people - and instead look for the people who will drive the organisation forward - who also happen to be talented software engineers. This is fantasy (as a strategy), and it's best to accept that fact. The fact that your developers might not be motivated by what your boss thinks they ought to be doesn't mean it isn't important for you to know about. Developers will often be motivated by peer recognition of skills or ability. Or by an introverted desire to solve difficult problems. Or by the warm glow of satisfied (or impressed) customers. Don't confuse this with a desire to serve the business / organisation. It is an egocentric rather than a serving motive. Another motivation factor to look out for is the desire to build or diversify skills as part of a career management tactic. Assessing delivery Perhaps sometimes we are too analytical. If you think about your current developers, you just know without thinking which of them really 'deliver' in the loosest sense of the word. These are the type of people you want more of. How do we find out if our candidates are in this group or not? Their previous line managers will know. The candidates will also know if their previous line managers held them in esteem or not. So why not ask to get in touch by phone? The deliverers will usually be enthusiastic about this prospect. Assessing quality Developers tend to have quite diverse attitudes towards quality, and it is valuable to have people from different points in the spectrum. You need some people who produce creative stuff very fast but have to be reminded about quality, and you also need the people who will sacrifice any semblance of speed to get nigh on perfect quality. It usually easy to get people in the latter camp to wax lyrical about their approaches, which implicitly identifies the other camp too. Complications I have had my fingers burned a few times by complications about a candidate that have emerged only once the person has been employed, and it may be worth exploring the potential for some of these in the interview. The first is an enthusiastic over optimism on the candidates part about the practicality or viability of temporary living or commuting arrangements. If these dont work out in a big way when youre four months into a project and dependent on the person its a serious matter. Another is the presence of high-maintenance professional commitments in the candidates life that can compete with their dedication to your role. For example pressure to write up a PhD, or legacy software development or support commitments to a previous employer or customer. Or even a fully fledged entrepreneurial business. Another example which seems to be on the increase, is people harbouring a closet intention to negotiate a working from home arrangement, but keeping quiet about it until they are in-post. If this is something that is genuinely important to the candidate, both they and we are better off from dealing with it up front. Appendix A: Interview check list Personal detailsCandidateDateExperienceSource code control systemsDevelopment lifecycles / continuous improvementBug fixingDesign patterns / de-couplingCollaboration Pair programming, code and design reviewDesign versus implementation approach Intelligent work sequencing Importance of architecture designTest strategies / practiceConsideration of alternative solutions Not just getting it workingSmart work planning Mitigating riskSkillsYour first relevant skillYour second relevant skillYour third relevant skillYour fourth relevant skillSoft characteristicsCommon senseIntellectual abilityBravery / confidenceRelationships Peer, management, customer, lateralAttitudes / drivers / motivationThe delivery qualityQuality approachOtherComplications Commute, accommodation, professional distractionsShoe on the other foot What will make / prevent this candidate from joining us? Appendix B: Sample Screening Test Note to Potential Candidates This test is intended to help YOU as well as me. The questions are designed so that, if you really are suitable, you will be able to answer most of the questions straight out of your head, and it should take only about one hour. These are not beginners questions. If you need to research the answers not only will it take up a significant chunk of your time but it is likely to be ultimately futile ( Im not looking for beauty or poetry. All I care about is if you know the answer. Im not looking for essays either. Please answer as briefly as you can Ive hinted at the scale of answer Im looking for with each question. Python What type does Pythons standard library provide that would help with removing duplicates from a collection of objects? (<= one sentence) They may know the language, but can they apply it? the best candidates come up with two answers (set / dict). What is the point of exposing a class attribute via a property() ? (<= 5 sentences) How broad is their knowledge of the language? ask about a feature that is a little off the beaten track the best candidates give a real world example. How do you change what print(your_object) prints? (1 sentence) Again, slightly off the beaten track the best candidates discriminate between __str__() and repr(). Why might you choose to use a list comprehension? (<= 2 sentences) Novices wont have a clue. The best candidates mention aspects of coding elegance and convenience, but also run time performance. Will this work, if my_obj is an instance of a user-defined class? (<= 3 sentences) if my_obj in some_list: foo Some candidates object to the lack of parenthesis on foo but the best candidates raise the good code-review context question of what did the coder intend for this to mean? i.e. instance identity check, or object equivalence check? Software Engineering etc. What is the main benefit of the single responsibility software design principle for large object oriented designs? (<= 3 sentences) You get all manner of theoretical answers for this one but the best candidates make the golden observation that ultimately it makes code easier, quicker and less risky to change. Name three design patterns you have exploited in your code in the last month (we will discuss these if we have an interview!). (3 design pattern names) some people say whats a design pattern. If you do interview ask about a DIFFERENT three the candidate will have read up on the three they wrote down. In general, at what stage of development should we try to optimise code to improve execution speed, and why? (<= 6 sentences) We are trying to assess if the candidate recognizes that the cost of optimizing code for speed is usually complexity, and that therefore it should in general only be done once the code is working properly functionally, and has been shown to be problematically slow. Even better if the candidate says that in some situations run time speed should be an early design consideration as distinct from a coding consideration. Name a practical difficulty you have observed with Agile style lifecycles and your suggested remedy. (<= 6 sentences) Do they really know what Agile entails and have real-world experience. Are they an observer of problems or a fixer of problems. Name a practical difficulty you have observed with test-driven development, and which key Python features help with this approach. (<= 5 sentences) As above plus some familiarity with testing tools and infrastructure like UnitTest / Nose. Why do GUI programs have event loops? (<= 4 sentences) Probably a useless question everyone can answer it and never had anything inspirational back from it. Maths / Physics etc. Would the candidate be able to relate usefully to end-users who do this kind of thing day in day out for a living? What is the fundamental difference between how you solve a quadratic equation and higher degree polynomials? (<= 3 sentences) Name a mathematical model that might be suitable for the computational representation of the complex curves we encounter in domains like aircraft design? If you have data representing air pressure measurement samples finely distributed over an aircraft wings surface what can you obtain by mathematically integrating these data? (one sentence). In optimisation algorithms where does mathematical differentiation come in? (one sentence) What is the very common interpretation of this Greek letter () in science? (one sentence) Bonus Questions Qualifying the  nice to have rather than the necessary experience for the role. List some Python add-on packages you have used  i.e packages that are not generally included in standard distributions? (word list) What is Qts messaging system, and can you identify one of its distinguishing features?     Interviewing Software Developers Page  PAGE 5 of  NUMPAGES 15 Peter Howard  HYPERLINK "mailto:peterhoward42@blueyonder.co.uk" peterhoward42@blueyonder.co.uk  HYPERLINK "http://peterhoward42.blogspot.com" http://peterhoward42.blogspot.com I grant permission to copy and modify this document for any purpose, provided the reference to me as the author is retained.      01346789IJKLM^_`wxyzȵȘȄ~upuiffXiS0JCJj>*B*Uph0J j0JU0JCJj0JCJU 0J5^J0J!j0JB*CJU\aJphjK OJQJUV!j0J5B*CJUaJph$jB*U\aJmHnHphu0J5B*CJaJph 5CJ$\%jB*CJUaJmHnHphu 59CJ0\jUmHnHu   -./0234567_% PP$xa$ $xx^xa$ $x^xa$dvvw !"#$%&'CDEFGHbcd~ԕ0JaJj>*B*UphjUj>*B*Uphj Uj>*B*Uph j0JUjU jU0J5CJOJQJaJmHnHsH 6$%&@ABCDEFGHdefgjkxyzѭїjo>*B*UphjUju>*B*UphjUj{>*B*Uph0J j0JUjU jU0JaJCJOJQJaJmHnHsH ;FLUV   @  w 8 H\  *+,FGHIJKLMNjklmpq|}~լՖj Uj] >*B*Uphj Ujc >*B*UphjU0JaJji>*B*Uph0JCJOJQJaJmHnHsH  j0JU jUjU8345OPQRSTUVWstuvwxݴݤݎjK >*B*Uphj U5CJOJQJaJmHnHsH jQ >*B*Uphj U0JaJjW >*B*Uph0JCJOJQJaJmHnHsH  j0JU jU4     # $ 4 5 6 P Q R S T U V W X t u v w z {    լՖjUj9>*B*UphjUj?>*B*UphjU0JaJjE>*B*Uph0JCJOJQJaJmHnHsH  j0JU jUj U8       6 7 8 9 < = ] ^ _ y z { | } ~      : ; < = > ? @ A ݴݞjUj'>*B*UphjUj->*B*UphjU0JaJj3>*B*Uph0JCJOJQJaJmHnHsH  j0JU jU;A B ^ _ ` a d e      . / 0 1 5 6 U V W q r s t u v w x y ҭҗjUj>*B*UphjUj>*B*UphjU jUCJOJQJaJmHnHsH 0JaJ j0JUj!>*B*Uph0J9      2 3 4 5 6 7 8 9 : V W X Y ] ^ o p q ´ԬžԖjUj>*B*UphjUj >*B*Uph0JjU jUCJOJQJaJmHnHsH 0JaJ j0JUj>*B*Uph6 %&'ABCEFGHIJfghiհ՚j>*B*UphjnUj>*B*UphjtUj>*B*UphjzU jU5CJOJQJaJmHnHsH 0J j0JUj>*B*Uph4 9:;UVWYZ[\]^z{|}ϫϕj>*B*Uphj\Uj>*B*UphjbUj>*B*Uph0J j0JUjhU jUCJOJQJaJmHnHsH  0J_HaJ:\!mt[K   Eƀcf^ &   ^ `      mn//<<z^^^_O_k___r```/aHaaaaXcYcd>eueȼ|v|l|6B*]_Hph33 jJ_H_H 5\_H0J CJOJPJQJ^JaJmH sH jUmHnHu mHnHujCJUmHnHu0JCJ0JCJaJmHnHu j0JCJUaJmHnHuCJOJQJaJmHnHsH  j0JUjV U jU)[viJ+ & F Eƀcf^ K   Eƀcf.^ K   Eƀcf^ KY "D%{''gK   Eƀcf.^ &K   Eƀcf.^ '')+)4*K*,,*-gK   Eƀcf^ &K   Eƀcf.^ *-?-//r0B123478999<P<<<<V==& & F#&K   Eƀcf.^ ==>f??~AADDE;EHH^JJL;LO PUU&@ ^@ K   Eƀcf.^ U+W?WY'YY[Z\]]]caaaa&K   Eƀcf^ K   Eƀcf.^ &@ ^@ ]]]]]]]t0z$$Ifl0J ,"  064 la$If$If & F]]]]$Ifm$$Iflv0J ," 064 la]]]]4$If$Ifm$$Iflv0J ," 064 la]] ^ ^x$Ifz$$Ifl0J ,"  064 la ^ ^=^>^?^J^K^L^j^k^l^z^^^^^^4$Ifm$$Iflv0J ," 064 la^ _ _ _&_'_(_O_k_l_m______t$$Ifm$$Iflv0J ," 064 la$If_____pz$$Ifl0J ,"  064 la$If________ ` `tpt$Ifm$$Iflv0J ," 064 la ``%`&`d$If$Ifm$$Iflv0J ," 064 la&`'`4`5`<$Ifz$$Ifl0J ,"  064 la5`6`K`L`M`b`c`d`r`````````\\d$Ifm$$Iflv0J ," 064 la````L$Ifm$$Iflv0J ," 064 la```` $Ifm$$Iflv0J ," 064 la```/a0a$Ifz$$Ifl0J ,"  064 la0a1aHaaaaaaaZc>dEd?e.fHtt & F%^` & F$Ifm$$Iflv0J ," 064 la ueee-fEfWfoff5gggg hhiNjjklm"nn:ooo9pOpptt^ttu_v`vavdvevgvhvjvkvmvnvpvvvvvvvvvvvvvvvvvjCJUaJ mH sH 5CJ aJ mH sH  mHnHuCJaJ jU^JmHsH6B*]mHph33sHCJOJPJ^JaJo( 6]_H6B*]_Hph33_H5OJQJ\^J_H<.ffggh hhiOjkmno:pOppAqqrr>t^tuve^e.-^n^n & F%^`v^v_v`vavbvcvdvfvgvivjvlvmvovpvvvvvvvvww$a$+ & F, & F%7$8$H$^`vvvvwwwwNwOwPwqwrwtwvwwwwwww jx?U j#UmH sH j!CJUaJ mH sH 0JCJaJ mH sH jCJUaJ mH sH j CJUaJ mH sH CJaJ mH sH wswtwuwvwwwwwwwwwwww+ & F$a$h+p,p-p.p1h/R / =!"#$%4567F'e$JFIFC    "$$"!!&+7.&(4)!!0A049:=>=%.CHCU`?V ѕ3a+ ˤV0(T+ eǠ< Vo6X`q enU|hxGBE$R.8@n?\"<Ҡ0MЈ@ @e VB1P@_"<"0 A00 A@@'BH`LR0`7+_BN4X74@H*,Z@/G<XTe)B% 0V5Q/ `i5LD<#,dR(AX*3@fACKtBI} "V+ 13V0ђR xt!FXEJDZ(gtxOQA aX A@vExeLPT̩@)XPa} h(tU U30 I ZEtvT"3t&ݐPCu%$@UE'BG?W(2XP~| ŽGr2UCt( P )@EIJVeI0#%LɀBOHteQPH ɐ7X7h3ŁeEQCǁ P%M~H 0&(P A"'H 7l(¡Q&siHPF F"L ]_HOa[7a( C(֐ v耥L -J2(x(Yg2Z(/00pf@P.I;d1(h-HTb4-, BvF@$8nX oPH *2Tt&x+*)\xeI 1t"."@@/  T(D5R+ '4 "Ȋ0E0ȕ '`(R*9戤J4,dUQI"+.ʝSP\PDhVP:}*5˸% 'lʺ5!! ALE LR" aP=#jZ(D* j*BE0ZHPI„z45XDgDTphCXh (jT)Qb)5j%@VH @t#"Q(8To`FlN[hWR@ -RY0(Cǥ\l S QB`+Rx *tjhEpXj\ZN3Q 訁|vB*k@nCۢUh@^?d `VST@ 0ViAQYh+πL+<E &$XT<^Ae`q~Z h B=d XE"vJ7h7 @QB9Q-h(+0 F@`TU)񈊼@Z(X:eAd%A2 "OV ZZ ^?B2 .qf*&E*PA@x 2_?}E `Bn-ղtB"+-@#T(L(1ZrhJ*ѸsDV@52N07h <``2d@PR֐4]CKn0 TPaYS8P@/^X*ECcRtAiO2(tB848aC_ 4H,G3 ~M: 5L  $@P բ-R[9bUѠx&E40k z%V"ORGG*YPvEG5JJSCo4H2S/G\(bsiDAm$ޅ[`?,l N+%*eOTtPAގ.T,)tR(/o5 6TJxȥH 4@J$@5@d Ei uQDR0_mE_b$Xf@\((1_}"DRO@HeCz:<E 3M\JR P8Ef: ɶ@a %/ N4B E[ ,(g@*fZChe(2 bd P2AHТ_k@57xTO_ V$+HU݀Q(@ lT ,`7 d `dHdPEALTfd"fR8PKQ*(Y0DDkH%HtZ99<'EG<(ְ+G- H 1-/EDdH`ik$ ', K h\( @ 4Q2 2aF`R.2i %洐 Pc(Ӱ t9[TX,Q?GDVit -(RZ\,FX+HhXeA 00 ̣ 0 d䊳*Q@`R3@XPuPd2 tMo8QaEPSy 贊_`e2T/* c7E+`R@A@+*E p Q(ƈ q:|G 4@XPr U 'Q(_@_*[aQ%~|5&JbT"ItTl}P(+poHb*3wŽoDeH €++*<>2Œ@Y0t %D"Rrv PG1F@` 3VQ#"RToDiLboiH%@}',dS'1F]&*uL)Hc4  lG:xeE"H(tA6ER* p ` ϤR4@X0H-7PVX<`DT Cc Lhb^HZH%V'@N1 h #d  FUH(b$d  1UOzoVX2+Q,@@T^Fx`/:"tP mQhZ*#,dQ@*N0(S[*ׂk(TJ,@ p@fIQ3{+`<J^PP b"(@Mƈ0:E K DRp.衐 ݔVOB 1T|bӀsrDSЃ- YQ@{l ((HqDT5 +)P iPj „dg , Y% +XTd'Fkn`<P@5@&M*ohT%?BMS""bEf A"…l]ZdT*Sd;KH("*_(CZ_4p TdU>TU+ҡҤ(OW`޲(T;0o8ҲN{ T0U @E`0a@`@+t@c^# GJdoHE3D ,*3 +YFR@cI `3;X™p!54bQXƊ$=(hƀ_GKV@PX f%d(E Tl@l R(2PTEZ"` XhjSɀcx(g%"  =E P )PP+ 7HIC* t @:EN@D_H H2DQ(QRvȠ\ t lip 2(oMeht |(IaSA?‰ tjV*) < AX@lυˀMhPR6@b#j tDdC.EKH`S!`W%   ,`?Dde0  # A21#/|E-WDq`!1#/|E-WJ2 ixcdd``.c```baV fx2+`$@!$1#?7A;CXk4c]FIp3f112B@"+g^qQir^VA"*~v{&121)W20b`bPc h{ 320&}DyK _Toc204189859}DyK _Toc204189859}DyK _Toc204189860}DyK _Toc204189860}DyK _Toc204189861}DyK _Toc204189861}DyK _Toc204189862}DyK _Toc204189862}DyK _Toc204189863}DyK _Toc204189863}DyK _Toc204189864}DyK _Toc204189864}DyK _Toc204189865}DyK _Toc204189865}DyK _Toc204189866}DyK _Toc204189866}DyK _Toc204189867}DyK _Toc204189867}DyK _Toc204189868}DyK _Toc204189868}DyK _Toc204189869}DyK _Toc204189869}DyK _Toc204189870}DyK _Toc204189870}DyK _Toc204189871}DyK _Toc204189871}DyK _Toc204189872}DyK _Toc204189872}DyK _Toc204189873}D  !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~*Root Entry  FU,@Data [WordDocument ObjectPool T,U,_1267461376 FT,T,Ole CompObjPObjInfo  !"#$%&'()*+,-./0123456789:;<=>?@ABD FPackagePackagePackage9qOh+'0  8 D P \hpxss Peter HowardoOle10Native1Table!SummaryInformation( DocumentSummaryInformation8 Insruct2.jpgC:\pch\tss\MARKET~1\pics\insruct2.JPG&C:\pch\tss\MARKET~1\pics\insruct2.JPGdJFIF``C    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?nEJz))yTז(-yHE,9ªJǥyOOI<9lYdXgP}3H.}o aj&[`kcE.cj0ܲue\u<-XK[!Ll[cS̍=}dHڳŔKm'B>e!5UwHSzawu UIu02^CwgҨ$!=ꤨ3[ܼsH'Pw#Ҧ6+*m}u㩎& qT0*Ouir${:s.=khc dU]# Е|A4L -!l81X3 qUΉT 46zv2 ,HR)`*wJ@Iy8lRx '6 Dd4*Ϛҳ0C==- _D$MQSZ.[}̘ bƩ\Kֵ9e+jI"pZp7r0kyZe+zut&+0=h+AF= &x!A+*0r2=+4i1,Gq5Qs9GNiUȈU ;~dzZsHJwjwjm1 #/qOcZҳ V9& Z|J+p3jߊCp1wcqN.X4[M[Ng'[2rl/p(Ҋf~Hkw:e;pm | im|a(;Iw9 DƹgKG>晑Nz:1pr W^~,R9.nnW<3_8)V 2ln*eV<>͙0_U?w9>~y#>%C[;xwCy(;5flWHe2yh5n )GZZM\ ,B!CA}w~v`i1iFhp=N+Oώ hW9Asgq] Gp:?cS(˹Wn~AJz5& 0xhTk{Zwʜ`ڶ_ !`Oj~8,B2zU+bYن 7VmmZ^T"kԤdy5fRGa7c =W9} ;+J¥guv0l-AwQ!SM$p6~W;OvF zWiW:>f]jXn$OަAF\C1Ҋº ?\$FyM҅ƪxkM6zHWg55\(Ҳ)\Uxy*DZ `3xִd4G_p.4@yR`ת:~*[]]@I?Jrќ87"KXEm w {?)jz^[zh†6Gq F54:u@ g'ω/9zW4xzJ3Z9/AV&8{]i@F:s@Ɗ[>{75<;1鐥䑗iۖ[*Ѵ,gT1r9+qҽNlJ(0Bɉ*d/O$\P]$88޷l {2n]g eFG"k-o=+m@qHBroUj8ڥX2WX cy?ƻ6h~C۱@#[\Y>*>+_LWm #Ri|0^xמθ[kNT+tZ+3>t=#'k{H~X?u7Q>el>9Yӫ=Ўq +x%Ziwϗ{M +dw H80y5QI y,֩֟(u!<"+n"#ՌȲS^>V>JQMR# +uͽ2D W{8!I 5,x+jrRfrͪy;)WsRy#U imp0%,1̿\su ),ڣ"#ͯhWĒj;v#5^YO*Hb$ۇm"LQLy wu6m d_j] Kpi̪Mhi}/Q^Ĩ|[s]׍cO r 5EiXS3V$Fܤ0NY@/L?ѥ'9FsVawFYcT`Ѹ}8޵%5vXaqGR^KzԥŽҮ~Wbq˱?z.Gz:2L$Wfwn&9:Q@yvٮ;ۨ$g2s"]=.0:O ǭ^O493$JՄ#;!-w,:W}o+)Gᑚ,&wd"ka"u9Y)G.&+ĺz56b2qWL<,zWӐB"6 1Lq#]:F9kW=+#<5p*řQY0~ v0GuYWq:x5# l54]N<#G^a f8h\%ќ~mug+< gƞS)}Mzޗ3WwL7ҵ/kQ4bMGQXRJ;׹Y&fbq4SndOһ>044Hx|<ϟ~'ߥ׊͒ &իnK4^$&u&O+kSVS)"$ ENiC:N=]5{KPڈ#cבt}ՠa68R1gō|~'kR=d`Yio$db^4F4$ e>׎HvjTeE*s~ZKx%khK6ñAC=3\qq^>O?+𫉝_1JOǪm: 4y<ѹOkž#\[vZLX?tAM|⏃tѭi+uh4a֯xNXkY C dĎLĚ5͵.iPN9|k^9II'J G@9G,1ɀW&\S|9koHd{2Ms|[m4PRARЅ呤Zǵi cc񯛬]գʺ̅O}+š=sZg&'teJ \z=c^(j&Nioԛ];Kj [}Tγ 3})Hׂj cf*amц٢VP=L𭎥o}Ա0p9ּ;WGk^+kW_f "஡c.ӨDצ[RpHQH'Zu=XIkriVO۳1UD'|}.1עʽ~䚍ll5~׮J9cgM]njCҚ:đbʊ*X%56*J+/qD(ta3%袹U^3n?ͨ&5~{Q]'(SwED>G$7IB}cY$ph=|%HZi!r!bT~\C+A(#j,*1PW8!&D'GES%}VH~/|޾QYѿ?_b{׭|sc&οZQEuۭ,(yK _Toc204189873}DyK _Toc204189874}DyK _Toc204189874}DyK _Toc204189875}DyK _Toc204189875}DyK _Toc204189876}DyK _Toc204189876}DyK _Toc204189877}DyK _Toc204189877}DyK _Toc204189878}DyK _Toc204189878}DyK _Toc204189879}DyK _Toc204189879}DyK _Toc204189880}DyK _Toc204189880}DyK _Toc204189881}DyK _Toc204189881}DyK _Toc204189882}DyK _Toc204189882}DyK _Toc204189883}DyK _Toc204189883}DyK _Toc204189884}DyK _Toc204189884}DyK _Toc204189885}DyK _Toc204189885}DyK _Toc204189886}DyK _Toc204189886}DyK _Toc204189887}DyK _Toc204189887}DyK _Toc204189888}DyK _Toc204189888}DyK _Toc204189889}DyK _Toc204189889}DyK _Toc204189890}DyK _Toc204189890DyK peterhoward42@blueyonder.co.ukyK dmailto:peterhoward42@blueyonder.co.ukyX;H,]ą'cDyK "http://peterhoward42.blogspot.comyK ^http://peterhoward42.blogspot.com/yX;H,]ą'cwDd{ n OO  C ^AF..\tss\marketing\pics\insruct2.JPGR5fd뭋3i~H}E#qFu5fd뭋3i~HJFIF``C    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?nEJz))yTז(-yHE,9ªJǥyOOI<9lYdXgP}3H.}o aj&[`kcE.cj0ܲue\u<-XK[!Ll[cS̍=}dHڳŔKm'B>e!5UwHSzawu UIu02^CwgҨ$!=ꤨ3[ܼsH'Pw#Ҧ6+*m}u㩎& qT0*Ouir${:s.=khc dU]# Е|A4L -!l81X3 qUΉT 46zv2 ,HR)`*wJ@Iy8lRx '6 Dd4*Ϛҳ0C==- _D$MQSZ.[}̘ bƩ\Kֵ9e+jI"pZp7r0kyZe+zut&+0=h+AF= &x!A+*0r2=+4i1,Gq5Qs9GNiUȈU ;~dzZsHJwjwjm1 #/qOcZҳ V9& Z|J+p3jߊCp1wcqN.X4[M[Ng'[2rl/p(Ҋf~Hkw:e;pm | im|a(;Iw9 DƹgKG>晑Nz:1pr W^~,R9.nnW<3_8)V 2ln*eV<>͙0_U?w9>~y#>%C[;xwCy(;5flWHe2yh5n )GZZM\ ,B!CA}w~v`i1iFhp=N+Oώ hW9Asgq] Gp:?cS(˹Wn~AJz5& 0xhTk{Zwʜ`ڶ_ !`Oj~8,B2zU+bYن 7VmmZ^T"kԤdy5fRGa7c =W9} ;+J¥guv0l-AwQ!SM$p6~W;OvF zWiW:>f]jXn$OަAF\C1Ҋº ?\$FyM҅ƪxkM6zHWg55\(Ҳ)\Uxy*DZ `3xִd4G_p.4@yR`ת:~*[]]@I?Jrќ87"KXEm w {?)jz^[zh†6Gq F54:u@ g'ω/9zW4xzJ3Z9/AV&8{]i@F:s@Ɗ[>{75<;1鐥䑗iۖ[*Ѵ,gT1r9+qҽNlJ(0Bɉ*d/O$\P]$88޷l {2n]g eFG"k-o=+m@qHBroUj8ڥX2WX cy?ƻ6h~C۱@#[\Y>*>+_LWm #Ri|0^xמθ[kNT+tZ+3>t=#'k{H~X?u7Q>el>9Yӫ=Ўq +x%Ziwϗ{M +dw H80y5QI y,֩֟(u!<"+n"#ՌȲS^>V>JQMR# +uͽ2D W{8!I 5,x+jrRfrͪy;)WsRy#U imp0%,1̿\su ),ڣ"#ͯhWĒj;v#5^YO*Hb$ۇm"LQLy wu6m d_j] Kpi̪Mhi}/Q^Ĩ|[s]׍cO r 5EiXS3V$Fܤ0NY@/L?ѥ'9FsVawFYcT`Ѹ}8޵%5vXaqGR^KzԥŽҮ~Wbq˱?z.Gz:2L$Wfwn&9:Q@yvٮ;ۨ$g2s"]=.0:O ǭ^O493$JՄ#;!-w,:W}o+)Gᑚ,&wd"ka"u9Y)G.&+ĺz56b2qWL<,zWӐB"6 1Lq#]:F9kW=+#<5p*řQY0~ v0GuYWq:x5# l54]N<#G^a f8h\%ќ~mug+< gƞS)}Mzޗ3WwL7ҵ/kQ4bMGQXRJ;׹Y&fbq4SndOһ>044Hx|<ϟ~'ߥ׊͒ &իnK4^$&u&O+kSVS)"$ ENiC:N=]5{KPڈ#cבt}ՠa68R1gō|~'kR=d`Yio$db^4F4$ e>׎HvjTeE*s~ZKx%khK6ñAC=3\qq^>O?+𫉝_1JOǪm: 4y<ѹOkž#\[vZLX?tAM|⏃tѭi+uh4a֯xNXkY C dĎLĚ5͵.iPN9|k^9II'J G@9G,1ɀW&\S|9koHd{2Ms|[m4PRARЅ呤Zǵi cc񯛬]գʺ̅O}+š=sZg&'teJ \z=c^(j&Nioԛ];Kj [}Tγ 3})Hׂj cf*amц٢VP=L𭎥o}Ա0p9ּ;WGk^+kW_f "஡c.ӨDצ[RpHQH'Zu=XIkriVO۳1UD'|}.1עʽ~䚍ll5~׮J9cgM]njCҚ:đbʊ*X%56*J+/qD(ta3%袹U^3n?ͨ&5~{Q]'(SwED>G$7IB}cY$ph=|%HZi!r!bT~\C+A(#j,*1PW8!&D'GES%}VH~/|޾QYѿ?_b{׭|sc&οZQEuۭ,(wDd{ n >>  C ^AF..\tss\marketing\pics\insruct2.JPGR5fd뭋3i~H}?qFu5fd뭋3i~HJFIF``C    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222" }!1AQa"q2#BR$3br %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz w!1AQaq"2B #3Rbr $4%&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ?nEJz))yTז(-yHE,9ªJǥyOOI<9lYdXgP}3H.}o aj&[`kcE.cj0ܲue\u<-XK[!Ll[cS̍=}dHڳŔKm'B>e!5UwHSzawu UIu02^CwgҨ$!=ꤨ3[ܼsH'Pw#Ҧ6+*m}u㩎& qT0*Ouir${:s.=khc dU]# Е|A4L -!l81X3 qUΉT 46zv2 ,HR)`*wJ@Iy8lRx '6 Dd4*Ϛҳ0C==- _D$MQSZ.[}̘ bƩ\Kֵ9e+jI"pZp7r0kyZe+zut&+0=h+AF= &x!A+*0r2=+4i1,Gq5Qs9GNiUȈU ;~dzZsHJwjwjm1 #/qOcZҳ V9& Z|J+p3jߊCp1wcqN.X4[M[Ng'[2rl/p(Ҋf~Hkw:e;pm | im|a(;Iw9 DƹgKG>晑Nz:1pr W^~,R9.nnW<3_8)V 2ln*eV<>͙0_U?w9>~y#>%C[;xwCy(;5flWHe2yh5n )GZZM\ ,B!CA}w~v`i1iFhp=N+Oώ hW9Asgq] Gp:?cS(˹Wn~AJz5& 0xhTk{Zwʜ`ڶ_ !`Oj~8,B2zU+bYن 7VmmZ^T"kԤdy5fRGa7c =W9} ;+J¥guv0l-AwQ!SM$p6~W;OvF zWiW:>f]jXn$OަAF\C1Ҋº ?\$FyM҅ƪxkM6zHWg55\(Ҳ)\Uxy*DZ `3xִd4G_p.4@yR`ת:~*[]]@I?Jrќ87"KXEm w {?)jz^[zh†6Gq F54:u@ g'ω/9zW4xzJ3Z9/AV&8{]i@F:s@Ɗ[>{75<;1鐥䑗iۖ[*Ѵ,gT1r9+qҽNlJ(0Bɉ*d/O$\P]$88޷l {2n]g eFG"k-o=+m@qHBroUj8ڥX2WX cy?ƻ6h~C۱@#[\Y>*>+_LWm #Ri|0^xמθ[kNT+tZ+3>t=#'k{H~X?u7Q>el>9Yӫ=Ўq +x%Ziwϗ{M +dw H80y5QI y,֩֟(u!<"+n"#ՌȲS^>V>JQMR# +uͽ2D W{8!I 5,x+jrRfrͪy;)WsRy#U imp0%,1̿\su ),ڣ"#ͯhWĒj;v#5^YO*Hb$ۇm"LQLy wu6m d_j] Kpi̪Mhi}/Q^Ĩ|[s]׍cO r 5EiXS3V$Fܤ0NY@/L?ѥ'9FsVawFYcT`Ѹ}8޵%5vXaqGR^KzԥŽҮ~Wbq˱?z.Gz:2L$Wfwn&9:Q@yvٮ;ۨ$g2s"]=.0:O ǭ^O493$JՄ#;!-w,:W}o+)Gᑚ,&wd"ka"u9Y)G.&+ĺz56b2qWL<,zWӐB"6 1Lq#]:F9kW=+#<5p*řQY0~ v0GuYWq:x5# l54]N<#G^a f8h\%ќ~mug+< gƞS)}Mzޗ3WwL7ҵ/kQ4bMGQXRJ;׹Y&fbq4SndOһ>044Hx|<ϟ~'ߥ׊͒ &իnK4^$&u&O+kSVS)"$ ENiC:N=]5{KPڈ#cבt}ՠa68R1gō|~'kR=d`Yio$db^4F4$ e>׎HvjTeE*s~ZKx%khK6ñAC=3\qq^>O?+𫉝_1JOǪm: 4y<ѹOkž#\[vZLX?tAM|⏃tѭi+uh4a֯xNXkY C dĎLĚ5͵.iPN9|k^9II'J G@9G,1ɀW&\S|9koHd{2Ms|[m4PRARЅ呤Zǵi cc񯛬]գʺ̅O}+š=sZg&'teJ \z=c^(j&Nioԛ];Kj [}Tγ 3})Hׂj cf*amц٢VP=L𭎥o}Ա0p9ּ;WGk^+kW_f "஡c.ӨDצ[RpHQH'Zu=XIkriVO۳1UD'|}.1עʽ~䚍ll5~׮J9cgM]njCҚ:đbʊ*X%56*J+/qD(ta3%袹U^3n?ͨ&5~{Q]'(SwED>G$7IB}cY$ph=|%HZi!r!bT~\C+A(#j,*1PW8!&D'GES%}VH~/|޾QYѿ?_b{׭|sc&οZQEuۭ,(eteete 01172825.dotoPeter2596eMicrosoft Word 9.0@4nK@/@@=,J\՜.+,D՜.+,@ px  77/r  Title (T\  _PID_HLINKS _TemplateIDAD 6_Toc2041898906_Toc2041898896_Toc2041898886_Toc2041898876_Toc2041898866_Toc2041898856_Toc2041898846_Toc2041898836_Toc2041898826_Toc2041898816_Toc2041898806}_Toc2041898796w_Toc2041898786q_Toc2041898776k_Toc2041898766e_Toc2041898756__Toc2041898746Y_Toc2041898736S_Toc2041898726M_Toc2041898716G_Toc2041898706A_Toc2041898696;_Toc20418986865_Toc2041898676/_Toc2041898666)_Toc2041898656#_Toc2041898646_Toc2041898636_Toc2041898626_Toc2041898616 _Toc2041898606_Toc204189859z#http://peterhoward42.blogspot.com/n&mailto:peterhoward42@blueyonder.co.ukNRw#..\tss\marketing\pics\insruct2.JPGNRw#..\tss\marketing\pics\insruct2.JPG6 j0305790[1]TC011728251033  FMicrosoft Word Document MSWordDocWord.Document.89q      !"#$%&'()/ i<@< NormalxOJQJ_HmH sH tH \@\  Heading 1$ & Fh<@&5B*CJ KH \^JaJ phffh@h  Heading 21$ & F @<@&^`5CJ\^JaJN@N  Heading 3$ & F<@&5CJ\^JaJR@R  Heading 4$ & F<@&5CJOJQJ\aJL@L  Heading 5 & F<@&56CJ\]aJN@N  Heading 6 & F<@&5CJOJQJ\aJH@H  Heading 7 & F<@&CJOJQJaJN@N  Heading 8 & F<@&6CJOJQJ]aJD @D  Heading 9 & F<@& CJ^JaJ<A@< Default Paragraph Font,@, Header  !, @, Footer  !@@@TOC 1  h! 5CJaJmHnHuF@FTOC 2 ! h<<^h mHnHu.U@1.  Hyperlink >*B*ph8OB8 Normal + Blue B*ph8OQ8 Normal + Bold5OJQJ\DObD Bullet + Blue  & Fx B*phpORqp )Style Normal + Bold + 18 pt Not Bold Blue B*CJ$phffbOb Style Blue Before: 6 pt & F h@ @ P^@ >'@> Comment Reference 6CJaJ,@,  Comment Text8O8 Comment Subject5\@O@  Balloon TextCJOJQJ^JaJ>V@> FollowedHyperlink >*B* ph:>@: Title $a$5CJPJ\^JHOH Style Left: 1.75"   ^ VOV Style Left: 1.75" CharOJQJ_HmH sH tH 8Z@8  Plain Text! OJQJ^JD0@"D  List Bullet" & F hh^hHO1H List Bullet CharOJQJ_HmH sH tH 6:@B6  List Number 2 $ & F*B@R*  Body Text%xHM@QbH Body Text First Indent & ^ @C@r@ Body Text Indent'hx^hLN@qL Body Text First Indent 2 ( ^ DOD Body Text CharOJQJ_HmH sH tH FOF Body Text First Indent Char.6@.  List Bullet 2+B/`QB List ,*$1$CJOJQJ^JmHsHtHNR`N Body Text Indent 2-^ B*ph33XS`X Body Text Indent 3 .e^e6B*]mHph33sH;=>AD6r;=>ADG6r -./0234567_%FLUV@w8 H \    ! m t[vKYD!{###%+%4&K&((*)?)++r,B-./0345558P8888V999:f;;~==@@A;ADD^FFH;HK LQQ+S?SU'UUWZXYYYYYYYYYYYYYYYY Z Z Z=Z>Z?ZJZKZLZjZkZlZzZZZZZZ [ [ [&['[([O[k[l[m[[[[[[[[[[[[[[[[[ \ \\%\&\'\4\5\6\K\L\M\b\c\d\r\\\\\\\\\\\\\\\\\/]0]1]H]]]]]]]Z_>`E`?a.bbccd ddeOfgijk:lOllAmmnnVofoo@`  0Vrtuw 3 5 6 8 X p  & B E F H h  : V Y Z \ |  6r: X%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%TX%T̕5<>CNQW!CbeGXX_R$e$'jqb$ ˄w>U,qR$`l0A(nsȫEqR$|AJכ1KlqR$Ať{H"q@(  t  S 6A j0305790[1]"`\  3 "` \  3 "` b  C "` H  #  N  3  B S  ? 07 m 6r q3t< tg} Zt| tRwt R~$t! _Toc81967944 _Toc204189859 _Toc204189860 _Toc204189861 _Toc204189862 _Toc204189863 _Toc204189864 _Toc204189865 _Toc204189866 _Toc204189867 _Toc204189868 _Toc204189869 _Toc204189870 _Toc204189871 _Toc204189872 _Toc204189873 _Toc204189874 _Toc204189875 _Toc204189876 _Toc204189877 _Toc204189878 _Toc204189879 _Toc204189880 _Toc204189881 _Toc204189882 _Toc204189883 _Toc204189884 _Toc204189885 _Toc204189886 _Toc204189887 _Toc204189888 _Toc204189889 _Toc204189890  m [vK#%4&(*)59f;~=@AD^FHKQ-SUY]>`d:lVo7r  uX#*%J&(>)59;=@:AD~F:H LQ>S&UYY]D`eNleo7r8ah&Qt'^N!l.SnK?s9B,"2(!ISC>!l.B-xr~}|1v"<+Kspj .`%%Ԗ                 6A`,A4[|kc8b4!Iv t&                  )b        ܊                  POg|̆zڪzF                                                       MYYYYYYYYYYYYYY Z Z Z=Z>Z?ZJZKZLZjZkZlZZZZ [ [ [&['[([k[l[m[[[[[[[[[[[[[[[[ \ \\%\&\'\4\5\6\K\L\M\b\c\d\\\\\\\\\\\\\\\\/]0]1]]]]7rMMY}0@  D  (7o7p6rp@ptp@Unknownlinda moschellGz Times New Roman5Symbol3& z Arial[& ??Arial Unicode MSCode2000;Wingdings?5 z Courier New9?Code20005& zaTahoma"1hwftÆ`J\/y!G 40drX'?) 2qHPC:\Temp\01172825.dot Peter HowardPeterCompObjCj