Resume and Linked-in Profile Optimization

Do you ever find that submitting your resume to an online application is like dropping it into a black hole?  Maybe your resume isn't getting the attention it should. Your odds of getting an interview go way up when a recruiter or hiring manager can find your resume easily online.  Especially if they can find what they are looking for in it quickly and easily.

Coffee and CreamSkill keywords are crucial for getting your resume noticed.  Where they are placed is equally important.  You must explain properly what you have done and for whom.

At the top of your resume in the summary area, you should list the required skills for the job for which you are applying.  Next to each of these, you should list the number of years experience you have with that skill.  If you have no experience with that skill, just say so, or say "knowledge of" or "training in."  Also list any core skill that you possess that may be relevant to that job with the years experience next to it. Ditch the generic summary at the top of your resume.

Make sure each skill that you have listed at the top is also shown in the body of the resume in each job where you used that skill so that the reader can see where and how you used each of these skills.  Under each job description, have a summary of skills used.  List the skills again, along with any other skills that were used during that job.

After the title and company name for each job description in the body of your resume, write a short paragraph with details about what the company is and does, and what your main job duty was there.  Although you may think it's obvious, not every reader of your resume will understand what that company is and what your role was unless you spell it out specifically.

Don't make the reader do any extra work (like having to click a link to find out more about a company you worked for) to understand exactly what you did and for whom.

In your bullet points under that short paragraph do not just list what you were responsible for.  List accomplishments.  Use numbers and descriptive words to show what your impact was.  "Increased sales" is not enough.  "Increased sales by 15% over 6 months" is better.

Repeat everything you have now done on your resume in your LinkedIn profile.  Use the information that you might include in a cover letter in the top summary portion of your LinkedIn profile.  Include your keywords there, too.  Start the "skills used" section under each job description with your name, like this:

Craig Fisher: Talent Acquisition Manager, Talent Attraction Strategist, Recruiting/Sales Manager, Sales, Business Development, Recruiter, Headhunter, Executive Search, Staff Augmentation, Information Technology Consulting Services; Contract, Temp-to-Perm / Contract-to-Hire, & Full-Time Staffing Recruiting; Executive Search. CIO, CFO, CEO, ERP, Oracle, SAP, Peoplesoft, .Net Application Developers, Project Managers, Business Analysts, DBAs, Software Package Installation/Configuration, Social Media Recruiting/Branding/Twitter Strategy Training

You need keywords that will be specific to what you do in order to help separate your resume from the thousands of resumes that are less specific.  A good recruiter will narrow their search with less generic keywords.  Having these listed multiple times in your resume will help it come up at the top of the search results in Google, Linkedin, Job Boards, and company databases.

Related posts:

The Best Format for Your Resume (Hint: It's not .PDF)

Top 10 Things to Leave OFF of Your Resume

About the Author: 

Craig Fisher is a founding partner of A-List solutions, blogger at http://blog.fishdogs.com/, and host of the TalentNet Live #TNL recruiter forum. As a 15-year recruiting industry veteran, Craig is a social recruiting new media branding strategist for job seekers and employers. Follow Craig on Twitter @Fishdogs.

Posted in: 
Job Seeker
Bookmark and Share

Hiring Great Agile Teams (Part 4)

In my last post we explored aspects of situational or behavioral interviewing when it came to agile teams. I tried to emphasize the importance of this segment of your interview as being at least as important as the technical parts. My hope is that you create a balance in your interviewing.

An extension to the situational interview, at least in my thinking, is the notion of auditioning. I recommended a book by Johanna Rothman in my last post and she has some good background information on preparing for and how to conduct auditions that you ought to read.

Basically, auditions are interview situations that are staged to allow the candidate to demonstrate their skills by participating in simulated, real-world situation with you and your team.  

Start thinking about auditions!

While they can clearly take many forms, I’ve been using three core types of auditions lately—

1. Pairing with the Team

In this case, I’ll invite a candidate to sit down for several hours and pair with one of our more experienced team members. They work on “real work” and not something contrived, however, it’s usually more simple work. For example, in the case of developers they might explore fixing a bug. In the case of testers, testing the repairs to one or a set of bugs that might be going out in a “hot fix”.

We’re looking for how they handle the environment & tools. Are they adaptive and are they asking the right questions? Are they inquisitive, energetic, and engaging or do they just sit there and want to be “fed” information? Do they ask for the keyboard and drive some of the discussion themselves? Can they say “I don’t know” and effectively ask for help? Simply put—does the team want to work with them?

2. Design Collaboration

In this case, we’re looking for someone to bring in one of their more “interesting” historical designs that somewhat maps to our technical space. We’ll then schedule a group design review where we try to fully understand, critique, and then extend their design.  The session is a mirror of how we run our own internal design reviews—so the candidate gets a solid feeling for our creative processes.

We’re looking for how open-minded and non-defensive they are. Do they articulate their design choices well and do they have a more pragmatic view towards design? Do they “get” the need for simplicity of design and not lean towards complexity for it’s own sake? Do they form a quick “partnership” with the review team—exploring options and getting excited as we narrow towards a team based solution? Often, one of our litmus tests is how animated they become and how much “whiteboard work” they jump up and participate in. Simply put—can the candidate share a coherent design and constructively digest and adapt to feedback?

3. Manager or Leader (Project Managers, Scrum Masters, Technical Leads)

In this case, we’re looking to see how potential managers and leaders handle themselves in whole team situations. One way to do this is to invite a potential manager in for a team meet and greet. Where the team can fire open-ended, questions at them on any topic. An extension to this is to challenge the candidate to talk for 10-15 minutes about why they should be leading the team—convince them that they’re “it”.

Here we’re honestly looking for how quickly someone thinks on their feet and handles some potentially tough questions. Do they answer questions clearly—can you follow their line of reasoning? Can they articulate their positions to the team and present a convincing argument? Are they good listeners? Do they engage the entire audience and are they respectful? Can they admit that they might have been wrong in the past or that they don’t know an answer? Simply put—do they demonstrate leadership seasoning in a group setting?  

Some Disclaimers Around Auditions

It probably doesn’t need to be said, but auditions should not result in too much “real work” being performed by the candidate. I’ve heard of folks who actually use their auditioning process as an adjunct to getting design and coding tasks completed for their projects. I’d hope that you stay clear of this sort of thing.

The feedback in the audition goes “both ways”. In wrapping things up, I usually ask the candidate to critique our team. Sometimes I’ll hear things that aren’t what I want to hear, but that are relevant and truthful. So be prepared to ask for feedback and to handle the truth as it comes.

I’ve had a tendency to limit my auditions to somewhere between 2-4+ hours. Anything more than that seems to be overkill from my perspective. To be honest though, I’ve heard of folks within the agile community that conduct 1-3 day auditions so that get a true picture of a candidates strengths and ability to integrate within their teams. I suppose I have a bias to the shorter interval, but do understand their point.


While we don’t always do auditions at iContact, I’ve also historically used the technique and I find myself appreciating the insights it provides more and more. There are many ways to audition your agile candidates. For example, I can envision us inviting Scrum Master candidates in to lead or facilitate our team Sprint Planning meetings. This would give us invaluable feedback on their real world experience.

I’m going to wrap-up this series in my next blog post with some examples of effective job descriptions/advertising for Agile developers and testers. To be honest, I don’t know where we’ll be going after that—so I’m open to your ideas and suggestions!

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
Bookmark and Share

Hiring Great Agile Teams (Part 3)

In my previous posts (Part 1 and Part 2) we explored some of the technical differences between Developers, Testers, and Business Analysts when they move from more traditional to agile teams. Here I’ll continue the discussion focusing on more of the soft skills that are relevant, not required, when you move to agile self-directed development teams.

Believe it or not, I think the soft skills are more important than the technical ones when trying to form high-performance agile teams. Lets dig in and see how we can assess them…

A Focus on Soft Skill & Behavioral Interviewing!

First, if you’re not doing behavioral or situational interviewing, then you need to as you move towards agile.  What do I mean by that? Well, instead of asking questions that are based on generic background experiences, place the questions within the context of looking for how the candidate handled a very specific situation in a specific job or role.

For example, here’s a non-situational question: Tell me how you generally handle conflict in teams?

In response to this, you might get a crisp answer with an example, or you might get a more rambling response. The quality of the answer is actually mostly based on how you phrased the question, and not the candidates’ fault if you don’t hear what you wanted to hear.

Here’s a more situational question:  

You mentioned that you left XYZ Company because your boss overworked you and you felt that your interests were not supported. Can you give me a specific project example of where your boss didn’t support you?

After the candidate gives you an answer, the following follow-up question opportunities might expose themselves:

What part did you play in the lack of support? Did you suggest improvement ideas to your team? Project Manager?  Or to your boss? Did you ever “confront” your boss about your frustrations and explore “options”?

As you can clearly see, these sorts of questions start drilling into the specific behaviors that the candidate exhibited in very specific situations. I also like to drill in with follow-up questions. Sometimes, I’ll say something or interpret and answer quite extremely—just to see how they react to the question.

It sounds like you really didn’t make much of an effort to challenge the status quo in that example. Instead you sort of acquiesced into complaining. Why was that?

One important note in this style is the effective use of silence. You have to realize that these questions are hard, and that candidates need to “search their database” for a context-based answer. So patience is required. As is silence, as the candidate thinks of an answer. Don’t try and fill the void of silence. Instead simply wait for the candidate to formulate and deliver their answers.

Given the focus of this blog series, you’ll want to explore their views towards agile methods and some of the discreet areas that are important therein. Just to get you thinking of examples, I like to explore some of the following topic areas in our agile interviews—

  • Teamwork:  How do they feel sitting closely together—in co-located spaces? Or about working in pairs? Do they see themselves as good teammates and what are the attributes of a good teammate? Explore their feelings around servant leadership, the golden rule, etc.; Are they good followers and leaders—why?
  • Ideation:  Do they exhibit high initiative and high creativity? How do they engage the team in exploring their own ideas? In listening to others? Have them give an example of when they followed a direction that wasn’t theirs—how did that work for them?
  • Courage:  Explore their ability and willingness to challenge team members on their approaches? About how they’ve kept the bar high within their teams? Explore their willingness to engage me and other leaders—to tell me when they think I’m wrong? Do they accept responsibility for their own mistakes? Have they ever “apologized” to their team for something?
  • Work Ethic:  Do they work hard (not in hours only) but in effort/focus? Do they expect the same from their teammates? What do they do if they don’t get it? What if one of their teammates needs help and they’re behind schedule on their own deliverables—do they help out?
  • Quality:  Do they actively engage in quality and testing? Do they serve as a model or champion within their team? Have a whole-team view to quality? Explore how many bugs are acceptable in a project and/or release?  How many sprint escapes are ok? Finally, have them explain agile done-ness and what it means to them?
  • Business:  Do they partner with the business in driving a focus on high-value features first? Do they actively engage the business? Do they listen to the business priority and make value based trade-offs? Do they know how to write good User Stories—and have they? Get a few examples. How have they made the “business case” for a story they wanted to get done?
  • Personal:  Are they pragmatic or a purist? How do they handle conflict? Do they gold-plate their work? And do they understand the notions of good enough and just-in-time? Do they have a sense of humor and don’t take themselves too seriously? Would they be fun to work with?

So in this post, I emphasized the situational side of interviewing. Please don’t think this is simply FLUFF. As I said in the beginning, I truly believe this is the most important part of your selecting and building high performance agile teams. Do not short shrift or underestimate the value of your conversations with potential team members. It makes all the difference!

In my next post, we’ll explore an interviewing technique called Auditioning that extends much of what I’ve said here…

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
Bookmark and Share

Hiring Great Agile Teams (Part 2)

In my last post I tried to set the stage surrounding some of the differences that Agile teams have when compared to traditional teams. It was important to establish a bit of a baseline, because the differences truly matter.

The differences don’t only translate into technical skill differences, but they also fall into the area of “soft skills” and collaborative behaviors. We’ll examine each in turn.

So, how does Agile change your Technical Interviewing? You still need to technically evaluate each candidate. In this case, if you have an already formed team, then the team would be mostly responsible for interviewing their potential teammates. If you are forming a new team, you’ll need to devise a way for quality technical skill interviews to occur.  

Hard Technical – Developer Skills

There are a few key skill differences to look for. First, you want to ensure that your candidates are comfortable developing code that is well designed and easily maintained. This follows the Agile principles of Incremental & Simple Design. Quite a few software architects and developers say they can build incrementally, but it’s truly hard to do it and demonstrate working code at the end of, let’s say, a 2-week iteration.

Also critical are the Agile practices of Refactoring and Reduction of Technical Debt. You’ll want to explore design patterns with candidates and explore how well they understand incremental design. Explore their courage when it comes to dealing with “business pressure” on schedule vs. proper design. How effectively do they negotiate that pressure and still maintain design integrity OR reserve time for later refactoring of trade-offs?

Finally, Agile developers need to “get” testing in their very core—you’ll hear the term “Test Infected” used to represent this Quality First Mentality. Ask them how, where, and how many unit tests they usually write. Ask if they understand the principle of Test-Driven-Development where unit tests are used as a design aid and as a testing artifact. Finally, ensure that they keep their tests, all of their tests, continuously working as they develop more code.  

Hard Technical – Business Analyst Skills

One of the key stretch points for traditional Business Analysts, when they move towards Agile methods, is the fact that requirements are no longer solely completed in the beginning of the project. Nor are they intended to be complete.

Now if you happen to have a BA background you’re head just exploded. What do you mean intentionally incomplete requirements!?!

Agile BA’s need to understand the incremental nature of Agile requirements. Also, how systems are built and clarified by examining running and working software along the path as requirements get continuously refined. They also need to have familiarity with Product Backlog management techniques (from Scrum) and understand User Stories (from XP) as the primary mechanisms for creating Agile artifacts.

One Prime Directive that the BA needs to understand is that writing about requirements is not the goal. Communicating and collaborating around requirements IS the goal. Check this point thoroughly in your interview…or at least whether the candidate has the capacity to change focus!

Another key difference in Agile requirements is determining business value and bundling Customer Acceptance Tests in the requirements. These two key aspects, more than anything else, try to connect the customer to each of the requirements so that the team can better understand the impact and importance of what they’re implementing. Candidates should be able to articulate this clearly.  

Hard Technical – Tester Skills

Testers are challenged greatly in the shift towards Agile methods. Instead of being a “late in the pipeline” verification step, their responsibilities shift towards customer engagement, becoming a Voice of the Customer, and also a Quality Champion within their Agile teams.

Initially, they work with the customer to define and refine requirements early in the process (each iteration). Part of this is simply writing the requirements—so there is overlap in this responsibility with the BA. At the end of each iteration, they execute the User Story & Acceptance Tests to verify each met customer needs. It’s these early definition and late verification steps, on an iteration by iteration basis, that assures the team is delivering quantified value.

You’ll notice that I didn’t say testers—test continuously in the methods. This sort of test it in approach, while necessary to a degree, doesn’t achieve the overall project quality results we desire. The good news is that testers have understood this for years, but have been suppressed in focusing on up-front quality. So, they should be energized by this difference!

Testing in Agility also crosses the boundaries of manual vs. exploratory vs. automated testing. In fact, Agile testers are true generalists when it comes to their efforts. One minute they might be sitting with a developer writing some automated unit tests. Then next, writing automated smoke tests, and then running a few manual tests to gain early feedback. This flexibility and breadth of skill is crucial for their success.

In my next post I’ll focus on the soft skill areas that need attention as you begin to make changes in your recruiting screening and interview processes.


There are two great books I recommend to help improve your interviewing skills & techniques as your reframe towards Agility…

One is Johanna Rothman’s wonderful book – Hiring the Best Knowledge Workers, Techies & Nerds.

And the other is Joel Spolsky’s – Guerrilla Guide to Interviewing.

About the Author: 

Bob Galen is the Director, Agile Practices at iContact and founder of RGCG, LLC a technical consulting company focused towards increasing agility and pragmatism within software projects and teams. He has over 25 years of experience as a software developer, tester, project manager and leader. Bob regularly consults, writes and is a popular speaker on a wide variety of software topics. He is also the author of the book Scrum Product Ownership – Balancing Value from the Inside Out. He can be reached at bob@rgalen.com

Posted in: 
Bookmark and Share

Preparing for an interview is kind of like getting ready for a date.

Has it been a while since you’ve interviewed? Not much time to prepare? Don’t panic. The rules of dating can also be applied to interviewing. 

Asher Date Kept on TalkingDo not arrive too early.

Human resources professionals and hiring managers have busy schedules and work by appointment. By arriving more than ten minutes before the meeting is scheduled you show disrespect for their time. If you must, wait in the lobby or your car before going to the interview location.

Do not show your desperation!

Telling the interviewer that you haven’t had an interview in months, you don’t have health insurance, or that you really need this job, is not going to improve your chances. Quite the contrary! If you told someone on a first date that you’re broke, about to lose your house - and car, and you really need to marry them, what do you think are the chances that you’d see that person again?

A proper thank you is always appreciated.

Send a note and thank the interviewer for their time. Have the envelope addressed and stamped before you even leave for the interview, and the moment you get home, write the note. (At the very least, send an email!) This is important because the discussion will be fresh in your mind, and you should reference one or two key points from your conversation. Use this opportunity to reinforce why you are a good fit for the position and how you can benefit the company.

Whatever you do for God’s sake do not stalk the interviewer.

This includes calling and hanging up. Yes, they have Caller ID, and they know it’s you! Nobody likes to be stalked or harassed. When they have news about next steps they’ll reach out to you. If they don’t, you may need to prepare for the fact that they just might not be that in to you. Ask at the end of your interview when and how you should follow up, and do it. If at that time they don’t have any news for you, ask when and how you should follow up next.

About the Author: 

Stephanie A. Lloyd is Strategist-in-Chief, Calibre Search Group, located in Atlanta, Georgia at the intersection of Talent Strategies + Social Media. With more than 15 years of experience in corporate recruiting and executive search, Stephanie works with hiring managers, HR executives, business owners, and recruiting firms on recruitment and retention strategy including how to better utilize social media for talent acquisition and employee communication. Stephanie is a regular contributor to Talent Net Live and The Matrix Wall, and she partners with Todd Schnick to produce the video blogging series He Said, She Said.

Posted in: 
Job Seeker
Bookmark and Share