Surviving The Technical Job Interview

Surviving The Technical Job Interview

by: Chris Bryant, CCIE #12933

Ah, the technical interview. Nothing like it. Not only does it cause anxiety, but it causes anxiety for several different reasons.

How many people will be asking questions? From experience I can tell you there’s nothing like walking into a room and seeing nine people on the other side of the table.

Second, what will you be asked? You’ll sometimes hear people say the questions they were asked in a technical interview were ขeasyข, which translated means ขthey asked me stuff I happened to knowข. Sometimes you’ll hear people say the questions were ขhardข, which translated means ขthey asked me stuff I didn’t knowข, or ขthey asked me about stuff I’ve never even heard ofข.

Having been on both sides of the technical interview table, I’d like to share some tips for those being interviewed. In doing so, I’ll share some of the more memorable interviews I’ve been involved in.

No good interviewer expects you to know everything. The problem is, you’re not always going to be interviewed by someone who’s good at it.

Sometimes, the person who’s giving you a technical interview was asked to do it about ten minutes before you showed up. Maybe they’ve never interviewed anyone before, or maybe they’re just in a bad mood. I’ve heard of technical interviewers where the interviewer derided an answer, and that’s totally unprofessional. I’ve had many a job candidate give a bad answer to a question, and my only response was silence followed by moving on to the next question. If your interviewer mocks any of your answers, you didn’t want to work there anyway.

None of us know everything. If you’re asked a question you just don’t know the answer to, don’t try to BS your way past it. This is a good opportunity to tell the interviewer how you would research that particular question. It’s not about knowing everything, it’s about being able to find out anything.

If your interviewer acts like he/she already dislikes you, that’s because they do. I once worked with a technician who felt threatened by anyone who applied for a job there, but especially if the applicant had a professional certification and then had the nerve to know what they were doing.

This technician participated in a group technical interview where the applicant was an incredibly bright guy, and had a particular skill that the department really needed. Problem was, the technician considered himself ขthe manข when it came to that skill. Recipe for disaster, right?

The applicant fielded four questions from the rest of us flawlessly, then faced this particular tech for a question. The threatened tech had a list of questions for the interview, but decided to ad lib. Big mistake. He asked a convoluted question that Rube Goldberg would have been proud of. When he was done, the applicant answered:

ขYou can’t do what you just described.ข

The tech started defending his question, and it became obvious that he hadn’t been able to follow his own question! The interview went into a bit of a meltdown from there.

Realize right now that there are some unprofessional people out there giving technical interviews. Be prepared for it, but remain professional yourself.

Be prepared for a practical technical interview. The best technical interviewers find a way to get you in front of the technology you’ll be working with. A great way to quickly find out whether you know what you’re talking about is to ask you to actually perform common and perhaps some notsocommon tasks. We can talk about technology and take all the computerbased exams we want, but it all comes down to performance. Be prepared to prove you belong on your interview day.

Be professional. This covers a lot of ground, so let me make a quick list for you.

Show up 15 minutes early. Nothing makes a technical interviewer more surly than waiting for the applicant.

Dress for success. The way you look when you walk into a room leads to your interviewer’s first impression of you.

Don’t chew gum during the interview.

Don’t be arrogant. Look, there’s nothing wrong with having an ego and acting confident. I do, and you should. But don’t come into the interview room acting like you’re too good to be there.

Finally, relax. Easy to say, hard to do? Not really. Realize that the majority of interviewers you’ll ever meet are going to be professional about the entire thing. The world’s not going to end if you miss a question. If you were not qualified on paper for the job, you wouldn’t be in there.

Do not look upon the interview as something negative. Rather, look at it as an opportunity to prove you know what you’re talking about. With the proper mental attitude, your technical interview will be a springboard to the next step in your career!

Chris Bryant

CCIE ™ #12933

About The Author

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage. The Bryant Advantageกs website offers FREE ebooks and tutorials for the CCNA and CCNP exams, FREE subscriptions to กCisco Certification Centralก, and sells the best CCNA and CCNP prep courses and books on the market today. Visit his site at www.thebryantadvantage.com today!

[email protected]

This article was posted on February 13

by Chris Bryant, CCIE #12933

Five Questions To Ask A Technical Training School

Five Questions To Ask A Technical Training School BEFORE Signing Up

by: Chris Bryant, CCIE #12933

As with any field, there are good technical training schools, and bad ones. When you sign up with one of these schools, you’ve made a significant investment in time and money. You deserve to know everything about the school and your job prospects after leaving that school before you put down your hardearned money. The problem is, sometimes it’s hard to know the right questions to ask.

The point of this article is not to bash technical training schools. That’s how I got my start in IT eight years ago, and today I’m a CCIE™ and own my own Cisco training company and my own consulting firm.

Before I ever put down the first dime, though, I asked some tough questions. So should you.

What are my true job prospects and legitimate salary levels after I graduate from your school?

We’ve all heard the ads on the radio… ขDid you know the average salary of an MCSE is $80,000?ข ขAre you worth $65,000 a year? If not, call us!ข

I’m an optimist, and I often tell people that no field rewards individual achievement and drive like IT does. Having said that, none of us start at the top, and darn few of us start at that kind of salary.

I’m sure that there are some people who broke in at $80,000, but I haven’t met very many of them. Be very wary of technical schools that use the famous/infamous MCSE Salary Survey as a marketing tool. They tend to represent those salaries as starting salaries.

Ask your technical school what the average starting salary of their graduates is. And keep in mind that salary is not the most important factor to consider when looking for your first job in IT; it’s the experience you’ll be able to put on your resume later on that you should weigh heavily at this point.

In short, be very careful about schools that brag about starting salaries. It’s not where you start, it’s where you end up.

How uptodate are the courses you’re offering?

Make sure the school you’re going to attend has made efforts to keep their courses relevant. Ask what changes have been made to their curriculum in the last three years. No field changes faster than IT. If the answer to that question is ขnoneข, look somewhere else.

I want to work in IT security. Have you placed anyone in this field lately? If so, can I talk to them?

Technical schools are jumping on the security bandwagon, with a couple of schools running ads about training you to work in Homeland Security. If that’s your goal, that’s great, but keep in mind that you have to get a security clearance for any job like that.

And how do you get a security clearance? You have to be sponsored.

And who will sponsor you? Your employer.

Can you get employed in a Homeland Security job without having the clearance in the first place?

Hmmm. Probably not.

Hello, Catch22.

Again, I’m certainly not saying you can’t eventually get an IT security job; if that’s where you want to go, you can eventually get there. The key word there is ขeventuallyข. Ask the school you’re thinking of attending whether they’ve actually been able to place graduates in such jobs. Ask to talk to them. If the school’s managed to do so, they’ll be glad to put you in touch with such graduates.

What textbooks does your school use?

Some technical school chains use only books that someone in their organization wrote. I’ve heard some of their own teachers complain about the quality of these books. The technical school I attended used offtheshelf books, and the quality was very good.

If you’re looking into entering the IT field, you probably know someone who’s already in it. Use that resource for everything it’s worth. Ask that person what they think about the books, or for that matter, what the local reputation of the school is. IT is a small world, if the school has a good or bad reputation, most of the IT personnel in your city or town probably know about it.

The fifth question is a question to ask of HR representatives. Every technical school lists companies where they’ve placed their graduates on their promotional material. Pick up the phone, call these companies, and ask to speak to someone in HR. Ask that person about the reputation of the school. Five to eight phone calls will give you a good picture of where the school stands with local employers.

Making the decision to attend a technical school can be the best decision you’ve ever made; it certainly was for me. Make sure to ask the right questions before writing a check or taking a loan to attend; the answers to those questions will indicate to you whether this school is truly the school that can help you achieve your dreams.

About The Author

Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage. The Bryant Advantageกs website offers FREE ebooks and tutorials for the CCNA and CCNP exams, FREE subscriptions to กCisco Certification Centralก, and sells the best CCNA and CCNP prep courses and books on the market today. Visit his site at www.thebryantadvantage.com today !

[email protected]

This article was posted on February 15

by Chris Bryant, CCIE #12933

Technical Writing for the Terrified

Technical Writing for the Terrified

by: Mike Kemp

Introduction

Sometimes it may be beyond a companies or individuals budget to hire a professional writer to address their technical documentation. Although in an ideal world all technical documentation should be produced by a highly trained expert, unfortunately we do not live in an ideal. In the same way that many people will attempt to repair their own home appliances, many people will attempt to write quality technical documents. Just as fiddling with a toaster can result in electrocution, attempting to write technical documents from scratch without prior advice will ultimately result in failure. As a rough rule of thumb you should always seek to employ a specialist, but if for whatever reason you can’t and you are the poor unfortunate that has had documentation duties foisted on them, don’t despair. This brief guide outlines some of the core skills you will need to bring to your writing, technical conventions to be aware of, software packages you can consider, and definite things to avoid. Hopefully even if you have never written a sentence in your life about anything vaguely technical you will have at the very least, a broader picture of what technical writing entails.

What is Technical Writing?

Technical writing unsurprisingly enough, refers to writing that is technical. Although this may seem like a fallacious definition, itกs an important one to remember. Too many technical authors make the mistake of creating documentation that is either too technical, or too กliteraryก. A good technical author should be able to adjust the balance between the two to suit the end user of the documentation. Technical writing is a lot like fresh air, pervasive and yet pretty much invisible. In the weird wired world in which we find ourselves, technical writing is everywhere. Software manuals, user guides for home appliances, instructional leaflets, emails, letters, reports, technical news reports, statistics and biographies on television sports shows all are examples of technical writing to which people are exposed to on a daily basis. If you have ever tried to program the time settings on a home video recorder and flung the manual across the room in disgust, you threw a piece of technical writing (although obviously not a very good one!). Too many times technical literature is produced by writers with not a large enough grasp of technology, or technologists that lack an ability to write. As a prospective technical author you must tread the very delicate line of being technically knowledgeable in your specialist field(s) as well as being a กgoodก writer (as opposed to กbadก writers who can usually be found mugging sweet old ladies or something). Technical documentation is usually produced for two distinct user groups, namely expert level users, and naive users. As a technical author one of your first tasks is to sort out what audience you are writing for, which brings me deftly to:

Know thy foe

As the old cliché goes, everyoneกs a critic. This is particularly true of most sane peopleกs reaction when faced with technical writing. As was highlighted in the example of the video recorder above, technical writing can be impenetrable to the end user. If this is the case, it is because whoever wrote the documentation, didn’t bother to identify their audience and write to their level. It seems an obvious point to make, but one that is often overlooked, that the user of the documents your are creating, may not actually be an expert. Obviously if you are creating a document on a particular specialist product for a particular advanced user group (a good example could be auditing software for computer system administrators) then you will need to compose this is an entirely different way than if you are creating for example, a technical manual for mass market computer software aimed at the inexperienced home user. One of the first tasks you must accomplish before you even put pen to paper, of finger to keyboard, is to identify who the user of your documents will be and construct documents aimed at that particular target group(s). If you get this stage correct, it should avoid your documents being thrown across rooms in annoyance!

Planning for perfection

Once you have identified the target market for the documents you will be creating, you will need to start to plan how the documents will be organised. This process is largely dependent on what documentation is being produced, but you can follow a few rough rules of thumb. Firstly, if the documents are to support a particularly detailed product (such as a computer application) get your grubby hands on it as quickly as you can. By examining the product in detail you can formulate a plan of attack and begin to compose an organisational structure. Whilst you are exploring the product in detail, take copious notes, as doing this during the initial exploratory stages can save you time which can be absolutely vital if you are working to deadline. Even at the planning stage you must ensure there is a consistency to layout, and organisational structure for the document. Select numbering conventions, paragraph styles, and generate rough ideas for layout purposes now, and save vital time later.

Let a Draft in

Before diving headfirst into creating the documentation, draft out each section first. This will allow to reorder if the documents being created do not have a logical กflowก without seriously having impact on the project. Many technical documents (especially for more detailed products) are made up of numerous (and in some cases practically countless) iterations. This is because the product shifts and changes over time, and one of the principal duties of a technical author is to keep abreast of these changes, and to ensure that they are all well documented. Good technical authors will always push their documents through as many drafts as humanly possible, refining on each draft, until they reach a position whereby they (and their employer) is satisfied that the documentation is timely, accurate and a true reflection of the product or process it documents.

The devil is in the detail

As already identified, technical writing is called that because it is technical in nature. Part of being technical is to be precise, and part of precision is to be as detailed as humanly possible. Even if the documents you are creating are for an advanced and technologically sophisticated user group, your documentation must focus on the details of a process, or in using a product. This can be a difficult feat to accomplish, but not if you write to your audience. Never assume that the reader knows anything about the product or process be documented, but in the case of advanced / expert users at least have the common sense to recognise the fact that they probably do not need to be told how to use the equipment they operate on a daily basis. When describing how to carry out a particular activity or task, identify each stage involved (number them if this fits the conventions of the document type you are creating) and to ensure the accuracy of what you have written test it yourself, or even better, rope in a volunteer of the same skills level as the end user.

Choose the right tool for the job

Although it is possible to create technical documents using parchment and blood, itกs not advisable. Many specialist software applications exist to help you create powerful documentation, and part of your duties as a technical author, include selecting the right tool for the job. Largely this depends on the nature of the documents being produced, and the nature of their eventual distribution. If the documents can be delivered using the Internet, this is certainly an avenue to consider. To that end make use of packages such as Flash MX and Dreamweaver to achieve this goal. For integrated online help, you may wish to create raw HTML documents, or alternatively select a specialist package such as RoboHelp or similar. In the case of print based documents, you will need to select a software package powerful enough to handle what you will throw at it. Many inexperienced technical authors instantly turn towards Microsoft Word (as it is ubiquitous in may commercial and private environments). Unless your documentation is going to be beneath 150 pages, and you know how to create templates and make macros, avoid MS Word. As any technical author will tell you it has nasty habits all itกs own, and can often be an unstable package to work with. If you are creating graphics heavy documentation, you may wish to consider Quark Xpress, or choose potentially the industry leader in the field, Adobe Framemaker. Whatever software you select, you must ensure you become incredibly proficient with it, either by investing in training, or by using it day after day after day!

Communicate – thatกs what you are paid to do!

Many people will tell you that creating technical documentation is tedious and repetitive. These people, are wrong, and possibly morons too. Although you may find the process of creating technical documentation กboringก (if you do you are in the wrong job!) it isn’t. Creating quality technical documents is a vital stage in allowing people to adequately and correctly use technology. Although no user will approach the documentation you create in the same way as they approach a novel, you can ultimately help them achieve what they want to achieve using technology. No matter how กdullก the process may appear to be, allowing users to achieve their goals by reading your documents should give you a rush of pride and indeed, happiness. As long as you remember the positive effects that technology can have on peopleกs lives, when you create your documents you can communicate more effectively, as you will be happier in the communicative process. Throughout the documentation life cycle, you should seek to liaise with colleagues as often as possible (if applicable). Let them read your documents, listen to their criticisms, and adjust your documents (if you can’t argue your corner!). A technical author is paid to communicate, make sure that you do, and never forget why your are communicating, and to whom, in the documents themselves.

Common Mistakes to avoid making

When creating technical documents there are a number of fatal flaws you can make. Although by no means exhaustive, this section details some of the more common mistakes new authors make, in the hopes that you will avoid making them too:

Being Patronising – Although technical documentation should be clear, it should never be patronising. You are not creating documents to be read by morons but consumers and clients. You should always write to the skills level of your audience, but no matter what technical level people are on, they are not morons. Even children get offended when patronised, don’t make that mistake with someone who is paying your salary, child or otherwise.

Overuse of humour – People do not read technical documents to be entertained, they read them in the hopes of successfully completing a process, or extracting information. Unless it is relevant to the end user, avoid humour wherever possible. If you are writing a book, fine and good. If you are writing a manual, avoid humour like the plague, as more often than not users will miss the joke and just end up loathing the patronising idiot that wrote the documentation.

Inconsistency – Even at the drafting stage, you should ensure that all the elements used in your document are consistent. This applies as much to the ‘toneก of the document as to the layout of it. Ensure you use consistent senses (first person, etc.) as well as page layout, pagination elements, headers and footers, and all other textual elements.

Proof read – By the end of creating a piece of technical documentation, you will probably be sick of the sight of it. That doesn’t matter. What matters is what leaves your office or home, is accurate. To that end proof read the document throughout all itกs drafts, and before it is distributed proof read it again, and again, and again. Never rely on spell checkers (they never work) and if you can avoid it, never rely solely on your own judgement. Get your document read by as many pairs of eyes as possible prior to distribution, after all, they could spot the one thing you have been missing throughout the creation process.

Conclusion / Shameless self promotion

Technical writing is not regardless of what you may think, an easy job. It requires expertise, patience and a very odd mixture of skills. Just like any other job, you can learn how to do it, but even that tuition will not necessarily make you any good at it. To be a good technical author, you have to be anal yet creative, focussed yet communicative, and a flexible expert. This, as you can probably imagine, is no simple task. Although you may think creating technical documents is easy, creating accurate, consistent and timely documentation to a high commercial standard is a highly challenging role. Regardless of your budget, in the long run it will provide significant ROI if you hire a specialist. After all, they will be able to do in days, what you tear your hair our attempting to accomplish in weeks if not months.

About The Author

Over the years Mike Kemp has been employed as a freelance IT journalist (working for publications such as The Register, Namesfacesplaces, Security Focus and Packetstorm), a copywriter, videogames designer, security auditor, web designer, graphic designer and IT trainer. He has worked in a variety of freelance and permanent positions for both small (e.g. two men and a dog) companies to multinational organisations throughout both the UK and Europe. When not working on various articles, books, manuals, and assorted other copy for clients, Mike can usually be found toiling on a variety of unpublished novels. He has had several of his short screenplays produced by independent production companies, and is currently working on several feature length scripts.

Mike lives mostly happily in a dreadfully un-bohemian London suburb with his long-term (and long-suffering) partner, and two addled cats. To learn more about Mike, the range of projects he has been involved in, and other assorted stuff and nonsense, please visit his personal homepage at www.clappymonkey.com.

This article was posted on November 26, 2003

by Mike Kemp

Humanize the Sales Process

Humanize the Sales Process

by: Amy Fox

Q & A

Amy Fox, Accelerated Business Results

ขHumanize the Sales Experienceข

Q. Sometimes when I’m presenting to clients, I sense that the customer tunes out. Is there a better way to communicate with a customer or engage them?

A. Salespeople get caught up in the hype of their own product and lose touch with their client’s reality sometimes. You may be an expert in your field, but you have to assume the client is not. Most clients do not speak techese, so you have to couch the conversation in language that is familiar.

Q. In high tech sales situations, what are some ways of obtaining better results on sales calls?

A. Start by shifting the focus from you to your client. Instead of presenting information to a client on your first sales call, try asking the client what expectations they have for the meeting. You can build a list of desired results from their answer. Try using questions that put the client in the driver’s seat. For example, ขWhat would you like to learn more about?ข or ขHow can I help resolve these issues?ข

Q. Are clients actually put off by technical language?

A. It depends, because there are instances when it is appropriate. If you’re speaking to a technical person who expects you to inform them about these aspects, go ahead. In many cases, the decision maker is not technical, so speaking in terms the client does not understand wastes their time. Even worse, they feel uncomfortable. Do you know anyone who would buy under these circumstances? There is no easier way to lose a sale then alienating a client.

Q. What’s the best way to speak about a technical product to a nontechnical person?

A. Refrain from using acronyms and technical jargon. Some common words that are not generally understood are IPSEC, T1s, WIFI, Routers. Concentrate on the problem they need to fix or the result they want to achieve. If the client needs a technical description, they’ll ask for it. Otherwise, avoid using these words.

Q. What are some other key ways I can improve the sales experience for my clients?

A. You need to humanize the sales experience. Once you learn to communicate in ways that relate to and reach they client, you regain your most distinguishing feature – yourself. Shorten your presentations by focusing on the capabilities and solutions you can provide in the client’s unique business environment. Learn to listen closely, catch key phrases, and hone in on their needs, not your own sales agenda. Incorporate business terms that are meaningful to the client in your dialogue.

Q. Do you think the first meeting with a prospective client should be a factfinding interview?

A. That is one way of thinking about it. Keep in mind clients don’t consider your products and services just for the heck of it. They either have a problem they need to fix or a result that must be achieved. The salesperson’s job is to use questions to uncover their business challenges and concerns. The goal in the first meeting is to set the foundation to build a relationship.

Q. When I’m presenting my high tech solution, how do I position it to come across persuasively so that the customer wants to purchase it?

A. Don’t simply explain what your product does and how it works. Present the value it brings to their business. For example, most salespeople would sell a highspeed internet connection that claims to be x times faster, rather than selling a solution that allows the client to process orders at a higher rate resulting in increased revenues. Demonstrate the benefits by linking back to how it will solve problems and achieve results.

About The Author

Amy Fox has designed and delivered sales training for Fortune 500 telecommunications and technology firms for companies such as Global Crossing Telecommunications, Cincinnati Bell, and Trivantis. Ms. Fox has taught M.B. A. courses at Xavier University on creating a coaching culture. Amy Fox founded Accelerated Business Results in 2003.

[email protected]

This article was posted on December 12, 2003

by Amy Fox