Strategies For Setting Yourself Apart In...

Posted on May 15, 2011

Q: How do I respond to the question “Why are you the best for this position?”

-In all your responses, remember to provide examples and details.  Don’t just say, “I’m a diligent and responsible person.”  Follow up with an example such as, “ At my last job, I was given a critical project with a very tight deadline.  Given the time constraint, I reorganized other priorities and worked late for 3 weeks to ensure timely delivery of a quality product.”

- Success in a technical role requires much more than just technical knowledge. Don’t underestimate the importance of soft skills; your communication, interpersonal, facilitation, negotiation and conflict resolution skills, as well as diplomacy will all factor into the hiring decision.

- Be sure to discuss your strengths in these areas, provide examples and quantify your accomplishments, whenever possible.

-Convey enthusiasm for your job and everything you do.  One memorable candidate response I received to this question was the following:  “In all aspects of my life, I am curious and passionate about learning. As a teenager, I liked to take apart and reassemble computers to understand how they work.  Today, my technical skills remain sharp because the same degree of curiosity and attention to detail goes into my work, as I probe under the surface of all problems.”

-Discuss what you do to be more efficient and productive in all areas of your life, not just work.  This will send the message that you are result-oriented and give 100% all the time.

-A unique & memorable response will make you stand out.  Take the time to come up with a personal, poignant or humorous answer to this question that will resonate with the interviewer.

This article was posted by Chiron’s Director of Career Services, Julia Shamis. Stay tuned for more information on this subject coming from our Business Analysis, Quality Assurance and Project Management instructors.

Post a comment

How QA Teams Can Find and Remediate Secu...

Posted on Apr 6, 2011

QA teams have some interesting ideas when it comes to answering this question: “Are you doing any application security testing currently?”… and depending on who you ask it’s possible you will receive a variety of different answers. “Testing for security” can mean many things to many different people, and we wanted to take a moment to debunk some of the myths that spread over the last 2-3 years.

Myth 1. Security Testing is already being done – Just because you’re checking for the existence of the password requirement, or making sure pages aren’t accessible without authentication doesn’t actually mean you’re doing security testing. In reality, this is just a small part of the overall security testing that applications require, but it’s the things that QA teams have become accustomed to doing, readily and quickly. Most security testing that I’ve observed QA organizations performing is centered around session management, and account authentication (and in some rare cases authorization). Very few QA organizations actually check for the types of issues that come from manipulating application logic, sending in garbage or malicious inputs, or attempting to break in to the application with malicious intent.

Myth 2. Security Testing is too hard [complicated] – Security testing can be quite difficult, if there is no expressive and well-established framework or process utilizing tools and documented, repeatable methodology. It’s easy to say something is too hard and simply not do it, that’s one of the most common excuses in the world! The way out here is for the security knowledgeable (the InfoSec or AppSec team) to establish clearly defined testing protocols, with easy to follow processes utilizing template tools and “cheat sheets” where appropriate, and leveraging as much existing technology and process as possible. The reason many QA teams complain about security testing is that some security teams try to force a whole new suite of testing tools and methodologies on the QA analysts – that’s a sure-fire way to meet opposition. In order to be successful it’s critical to first understand the existing processes, tools and methodologies the QA teams use today and then adapt security testing protocols, tools and methods to fit within those existing processes and be minimally invasive or disruptive.

Myth 3. Security Testing is not QA’s job [that's security's job!] – Absolutely untrue. Security is everyone’s job, more explicitly – the QA organization is responsible for software quality – of which security is a component. We here at HP preach about the three pillars of software quality: Does it perform? Does it function? Is it secure? … is any one of those three questions is left unanswered the QA team is failing. The other big argument to be made here is that QA gets the application much earlier than security teams, for testing. and finding defects earlier is always a bonus. Speaking of bonuses… catching software security defects, assigning them to a developer as a bug, and tracking them through fix, re-test and ultimately closed-fixed states is a thing that QA teams own almost exclusively. I can’t name many security organizations that can produce the types of KPIs that QA organizations can – KPIs that are absolutely critical to proving conclusive success or failure of a software security assurance program. So yes, security testing is your job, QA analysts!

Myth 4. QA can’t be effective at security testing [they're not experts] – A valid argument… if you completely disregard the fact that the application security testing tools market is maturing faster than our national debt. The secret here is that QA analysts don’t have to be security “hacking” experts if they have the right tools in place. QA analysts don’t have to be expert hackers, in fact, we’d prefer them not to be. QA analysts just need to be able to use tools and follow process effectively to identify basic application security flaws. The name of the game here is leveraging the scale of the QA teams, which is typically 30:1 all the way to 50:1 when compared against application security analysts. If the testing and automation can be driven through QA analysts rather than taking up precious few cycles that the highly skilled application hackers have – this is a tremendous win because the security experts can spend their time validating and digging deeper into the applications, rather than doing simple testing. The security teams just need to make sure that the tools and processes they set up for their QA analyst counterparts are templated and uncomplicated – so that the QA resources can effectively focus on what they do best – testing.

Myth 5. QA analysts don’t understand Security Testing – Security testing is not altogether too different from functional testing, except in the details. Testing is basically set up, execution, and interpretation. If the set-up and interpretation is done by application security analysts the part that’s left can be templated such that the level of understanding is minimal. Let’s be clear here – we’re not expecting a QA analyst to be able to cobble together a complicated script to evade an anti-cross-site scripting library …but we should reasonably expect that the analyst can either effectively use a tool, or follow a well-documented process that has varying tests and permutations allowing the analyst to think for themselves and flag questionable results for review by the security experts. In reality, many QA analysts start to become very interested in hacking and security testing once they’ve been given the opportunity to learn and experience. It’s the lack of exposure that’s currently hindering adoption and fueling this final myth.

So there you have it, 5 of the most common myths behind why QA analysts haven’t been doing security testing in the QA cycle in most modern, mature enterprises. Which excuse, I mean myth, do you subscribe to or perpetuate? Isn’t it about time to start dispelling these myths and start leveraging the power of QA organizations to bring better software security to our enterprises? We think it is.

Sources: Article “5 QA Myths Debunked: Why QA Doesn’t Do Security Testing “ on HP Community => “Following the White Rabbit – A Practical Blog on Software Security Assurance” section

Post a comment

Mastering the Phone Interview

Posted on Mar 23, 2011

Q: How does a phone interview differ from a face-to-face interview?

A phone interview is often the first step in the candidate screening process.  The purpose is to weed out a large number of possible candidates, narrowing down the list of individuals selected for an on-site interview.

Specific distinctions between phone and on-site interviews:

  • The focus of the phone interview is on identifying red flags, such as gaps in employment, poor communication/interpersonal skills or personality traits inconsistent with the corporate culture, which would serve to disqualify the candidate from further consideration.
  • At home, there are numerous potential distractions that threaten to take your attention away from the conversation.
  • The atmosphere is more casual, often causing candidates to feel and act more laid back than is appropriate during an interview.

Q: What can I do to ensure a successful phone interview?

The key to any successful interview, whether on the phone or in-person, is preparation.  Practice answering interview questions with someone who will provide constructive criticism.  The mirror is also a great source of unbiased feedback and will give you a clear view of how you come across in an interview.

  • Put yourself in the right frame of mind by preparing for the call the same way you would for a face-to-face interview.  Beyond perfecting your interviewing skills, here are several additional suggestions that will boost your likelihood of success.
  • Take the call in a quiet room where you can sit behind a desk, as if speaking to the interviewer on the other side.
  • Ensure that there will be no distractions.
  • Eliminate sources of peripheral noise, such as cell phones, alarms, toys, kids, etc.
  • Dress and attend to your presentation with the same level of professionalism as you would if meeting with the hiring manager on-site.
  • Don’t risk getting disconnected during the call.  Use a landline, charge your phone in advance and disable call waiting.  Consider using a headset – you’ll feel less restricted and be free to use hand gestures, communicating as you would naturally.
  • Have your resume ready for reference and prepare a notepad and pen.
  • Have in front of you a list of relevant discussion points: strengths, reason for interest in the position, key facts about the company/industry.  Caution: do not read your answers, as this will be quite obvious.  Instead, practice answering these questions in advance; use the notes only as reminders.
  • Smile — although the interviewer can’t see you, your voice will convey enthusiasm and set a positive tone.
  • Be prepared for the most likely phone interview questions (e.g.: “Explain your reasons for leaving each job”; “Explain any gaps in employment”; “Name your 3 key strengths/weaknesses”; “Why are you interested in this job?”)
  • As you would during a regular interview, remember to ask a few well-chosen questions and express your interest in further discussing the opportunity in-person.
  • Follow up with a thank you note.

Although this last suggestion is not specific to phone interviews, please also consider the following:  your voice-mail message may be the first impression you make on a recruiter.  When conducting a job search, be sure to override the generic message with a personal greeting that sounds professional and positive.

Post a comment