Category: Feedback

We all get rejected. Don’t take it personally

You’ve been let go from your job. Or maybe you were passed over for the promotion. Or you applied to a position you very much wanted, and didn’t get so much as an acknowledgement of your application. Or you were turned down by the school or program that you had your heart set on attending. Or maybe your “great idea” got shot down. The list is nearly endless. Whatever the situation, or whatever the reason, we will all inevitably be rejected.

A couple of things made me think about this: a very recent situation where I was rejected for something (I won’t get into the details of it here), and the job hunt presentation that I just gave this past weekend at WE Local Hartford. In my presentation, I include a slide that talks about what to do when you’re rejected. I figured I should expand upon that. It occurred to me that, when it comes to professional development, we talk a lot about improving yourself and things to do to improve your chances. But we rarely talk about what happens when — not if — we get rejected.

Let’s face it. Getting rejected sucks. It’s a blow to your ego. You start thinking about what you did wrong. You start wondering if you’re really qualified to be doing what you’re doing. It’s often a major contributor, if not the root cause, of imposter syndrome. I can tell you that I’ve suffered my share of it, and it’s shaped my professional career in a number of ways. I would be lying to you if I said that I’m immune to rejection and it doesn’t get me down, because I’m not, and it does.

That said, when it comes to professional development, getting rejected is rarely personal. Now, I’m not going to lie and say that getting rejected for personal reasons doesn’t exist, because it does. But think of this: if you’re applying for a job or a school, what are the chances that someone making the decision knows who you are and is rejecting you because of a personal issue? I’d think that those odds are almost zero.

(It’s possible that maybe you were rejected because of some form of discrimination, such as racism, sexism, or ageism. However, this goes outside the scope of this article, and is another topic for another time.)

So how do you deal with rejection? I don’t know about the psychology behind dealing with rejection (that’s a conversation that goes beyond my education and expertise), but here’s what I think.

Remember that you are human. We are not machines. You are not expected to be perfect. You are going to make mistakes. In most cases, one or two slip-ups shouldn’t be enough to sink you. Don’t spend your time dwelling on what you did wrong. It’s often not worth the stress.

That said, make sure that you…

Fix whatever is broken. Each mistake we make is a learning experience. Find out what the mistake is and take steps to fix it so you’ll know better the next time it comes up.

So how do you find out what’s broken? For one thing…

Get feedback. It is perfectly okay to ask why you were rejected. Maybe you didn’t have the right skill set, or a skill was lacking. Maybe you didn’t communicate well. Whatever the reason, asking why you were rejected helps you to identify any issues that you need to fix.

It might also simply be that you just weren’t the right fit. I keep thinking of a scene at the beginning of Tootsie where Dustin Hoffman’s character was auditioning for a show. After arguing with the director as to why he should be picked, he was finally told, “we’re looking for somebody else, okay?” It takes two to tango, and not every match is a perfect fit, whether it’s different cultures, mindsets, skill sets, or whatever. Think of it this way: if it’s not the right fit, do you really want to be there, anyway?

Consider the competition. Maybe someone else has a better skill set, or is more experienced. Maybe there were 200 applicants for only one position, which means that 199 people were going to get rejected… and you just happened to be one of them. Only one person can be the best, so chances are that no matter how good you are, there will likely be someone who is better than you.

Always take the high road. Whatever you do, keep a positive mindset (yes, I realize that this is easier said than done). As I said earlier, it is okay to ask why you were rejected, and if you can get an honest answer, you can fix it and move on. You also don’t want to burn bridges; you never know whether or not you’ll need to deal with that person or company again. Even for jobs for which I’ve been rejected, I’ve asked if it was okay for me to connect with them on LinkedIn, and most of them have obliged.

Have a short memory. It’s human nature to dwell on what went wrong, so the ability to forget about it and move on can often be an asset. Even Mariano Rivera, the Hall of Fame relief pitcher who seemed nearly untouchable, gave up an occasional home run or walkoff hit. He often mentioned that one of his assets was to forget about it and move on to the next game.

Distract yourself. Something to get your mind off your experience might not be a bad thing. Forget about your issue for a while and go do something you enjoy. Go to a movie, work on your hobbies, play golf, hang out with friends, whatever it takes for you to get your mind off of it for a while.

Talk to someone. Don’t keep your emotions bottled up. Get it out of your system. Talk to a friend and say what’s on your mind. Not only will it feel good to unload your feelings, it’s also an opportunity to network.

When I gave my presentation in Hartford this past weekend, I asked if anyone had lost their job and was looking. One lady raised her hand. I didn’t get a chance to talk to her, but I did get a sense that she was frustrated by her situation. If she is reading this, I want to you know that it happens to the best of us. We’ve been there and done that. Don’t let the rejections define you.

Keep plowing through, and eventually, you’ll get accepted.

Advertisement

User testing is important — for documentation

Any application developer will (and should) tell you how important end user testing is for their product development. It’s an important part of the development lifecycle. Developers need to know if their applications actually work, if they work the way they’re intended, and if their interfaces can actually be used. Without user testing, developers put blind faith in what they produce, and they have to assume that their applications are perfect every time, all the time — which, as we all know, always happens. User testing is critical in ensuring that you create a quality product.

So how often does your documentation go through user testing?

I’ve said many times that document development needs to go through the same steps as application development, and this is one of those steps. It is (sadly) common for documentation to be released without being checked for accuracy or usability. This is another way in which document development gets absolutely no respect, whatsoever.

If you’ve written, say, a set of instructions, one of the best things you can do is to give it to someone to make sure (s)he can follow it. How (s)he follows it readily tells you how well it was (or wasn’t) written, what does and doesn’t work, what adjustments need to be made, and so on.

It may not even entirely be the wording that needs adjustment. How easily did the person find information within the document? Was it there but not easily found? Was it overlooked? User testing not only can determine content accuracy, it can also serve the same purpose as UX/UI in that it can determine how effective object placement and document layout is.

And like application development, user testing your documentation determines what adjustments need to be made before it’s released. Additionally, user testing isn’t just critical for development; it’s important for document maintenance as well. Documentation that hasn’t been adjusted for changed environments makes for inaccurate information. Much of that can be caught through user testing.

I’ve said time and again that document development needs to be treated the same way as application development. User testing is an important step in that life cycle. It determines that your document quality is improved when it is released. Without it, you run the risk of releasing bad, poor quality, or inaccurate documentation.

It’s not them, it’s you #Documentation #ClearCommunication

A friend of mine (you know who you are) posted this to his Facebook this morning. Ostensibly, it’s in response to the growing controversy about the New York State governor (I won’t go there; that’s not what this is about, and I still despise politics), but my friend’s post was so compelling that I thought it was worth sharing.

As a professional communicator, I can’t tell you how many times someone either delivered a talk or a document and became frustrated when (s)he didn’t understand why his or her message did not get conveyed. Granted, in some cases, it might be that the sender is not a native speaker of the language and doesn’t know it well enough to convey his or her message. For those people, I’ll cut them some slack.

However, I am continually frustrated by people who insist that (s)he wrote a great document, only to find that what (s)he wrote was so obfuscated by detail, technical jargon, lack of organization, an avalanche of information, poor command of language, lack of understanding about design, or other reasons. This is the kind of thing that keeps me employed as a technical writer.

I’ve written many times before that it’s often the sender’s responsibility to ensure the message is clear. For example, I’ve come across too many instances (and I still continue to) in which a technician, writing a document, keeps insisting on including every little piece of detail in his or her document. And I continue to pound into people’s heads that reading is work!!!

So to my friend who posted this this morning, all I’ll say is, thank you for supporting my passion and my mission. This is exactly what drives me to do SQL Saturday and Data Saturday talks. And I’ll continue doing so until people get the message.

Improvement through rewriting

If you’re an application developer (or at least you used to be one, like me), how many times have you come across an old piece of code that you wrote and said to yourself, “what the f*%k was I thinking?!?” You say to yourself, I can write that much better now than I did back then, and your instinct is go back and change everything that you’d previously written.

The same holds true for documentation. I recently had an experience that reminded me of that.

I was updating my slide deck for my upcoming SQL Saturday talk this Saturday. I thought my slides were in pretty good shape, but I wanted to go through them to ensure that everything was still fresh and up-to-date. Besides, the organizers at SQL/Data Saturday LA sent me a link to their PowerPoint template, and I figured that I should use it for my slide deck for Saturday.

Indeed, when I went through my slide deck, I was hit with a case of “what the hell was I thinking?” Many of my statements and references were outdated. I found that I could rewrite much of what I’d originally written, making them more efficient and readable. Some items were unnecessary, and I eliminated them altogether.

I spent a couple of days rewriting my slides. When I was finished, I discovered that I liked the new slides much better than my old ones. I took the new slides and made some minor modifications (mainly removing the SQL Saturday LA branding so that it was more generic). If you’d like to see them, you can download them from my Presentations page.

So the moral of the story is, no matter how good you think something is, it can always be better. Don’t be afraid to review and edit something you’ve created. You might find that you like your new version even better.

(P.S. check out my presentation this Saturday!)

What are you proud of? Tooting your own horn on your #resume — #JobHunt

Yesterday, a good friend of mine texted me, asking me to send him my resume. This particular friend works for a major nationwide consulting firm. I won’t say which firm, but I will say that it’s a household name. In his position, he is often in a position to hire, and he is well-connected.

After reviewing my resume, he texted me back again, saying “let’s talk. I have some ideas that might make your resume even better, and I want to make sure those changes are implemented before I pass your resume along. Do you have time to talk tomorrow?”

I got off the phone with him a little while ago, and what he had to say was eye-opening — and in our conversation, I managed to improve my resume even more.

His advice (and I’m paraphrasing here): “what projects are you the most proud of? As a hiring manager, that’s something that stands out to me. Your work experience looks good, but everything you mention is general day-to-day activities. You don’t really list much in terms of a specific project you worked on. For example, something like ‘I designed such-and-such app that helped people do their work more efficiently by whatever-it-did-to-help-them, saving the company millions of dollars’ is something that would stand out to me. What are you the most proud of? Make sure you highlight that in your resume.”

I did raise a concern. I told him, yes, there is a project that immediately pops into my head, but it goes back many years; in fact, it’s a project I worked on for a company that goes outside of the past ten years. He told me, “that doesn’t matter” (he also relayed to me a project that he was proud of that took place over twenty years ago). “I’m proud of that, and I still include that in my profile.”

I had my resume file open in front of me during our conversation. While we were talking, editing ideas started forming in the back of my head.

His suggestion was to include these projects in my work experience, but I decided to leave that section alone. Instead, I decided to rewrite the Career Summary section of my resume. I wanted to do it this way for a couple of reasons: one, this appears at the top of my resume and would be the first thing that prospective employers read, and two, rewriting the Work Experience listings would have been a lot of work, and could have potentially resulted in document restructuring issues.

In terms of projects in which I take pride, I immediately wanted to mention a server inventory database that I built years ago; whenever anyone asks me about a professional project of which I am the most proud, this is the one that I always think of immediately. I also wanted to mention my involvement with recovery efforts after 9/11 (my Disaster Documents presentation is based on this experience), so I included that on the list as well. I also wanted to include a project that was much more recent, so I included a user guide that I wrote from scratch, including developing the Word template for it (additionally, I wanted to highlight that it was for a SaaS application). Finally, I also wanted to make mention of a project in which I learned about MVC concepts (unlike the other projects, this one does appear in my Work Experience section).

There were also a few other things I wanted to do with my Career Summary section. A while back, I came up with my own personal tagline, but it did not appear in my resume. I wanted to make sure it was included. Additionally, whenever I submitted my resume, I was finding that I was experiencing confusion on the part of prospective employers. I was (and still am) targeting primarily technical writer positions, and I was often questioned, “with all this technical experience, why are you targeting tech writing jobs?” I wanted to restructure it in such a way to explain that I was drawing upon tech writing as a strength, without sacrificing the fact that I had a technical background.

Before I made my edits, the Career Summary section of my resume looked like this.

(The Career Summary section of my resume — before)

When all was said and done, this is how it came out.

(The Career Summary section of my resume — after)

Additionally, I had to make changes to other sections of my resume, entirely for formatting purposes. I wanted to ensure that it would fit on two pages. I consolidated a few sections of information that, while helpful, I didn’t think would be as important.

I made the changes, updated my resume files (Word and PDF), and resent it to my friend. As of this article, I’m still waiting to get his feedback (he texted me to say he was busy, but would look when he had the chance), but personally, I like the way these changes came out.

(Edit: I heard back from my friend; his advice was to keep the accomplishments to one line each. In his words, “make it punchier.”)

You don’t necessarily have to do this within your Career Summary section; this was how I decided to approach it. If you can incorporate these highlights into your work experience listings, then by all means, do so.

I want to mention one thing when adding “proud accomplishments” to your resume. There is a fine line between talking about accomplishments you’re proud of and bragging about things to stroke your ego. Keep in mind that the purpose of a resume is to get you a job interview. Talking about projects you did that made a difference can help with that effort. Bragging about things you did (or didn’t do) will not. Nobody cares about your ego; they care about what value you can bring to their organization.

So what are your thoughts on these changes? Feel free to comment on them, especially if you’re a recruiter or a hiring manager.

Reinventing the #resume (again) #JobHunt

I had a conversation today with a recruiter — technically, it was an interview, but the way we spoke, it was more of a conversation between an agent (her) and a client (me) — who gave me some advice regarding my resume. I came away from the conversation with a few insights, and I’d like to share those insights here. This is not the first time I’ve written about resumes. I continually learn something new about them.

We left the conversation with her giving me a homework assignment: revamp my resume to incorporate what we had discussed.

Probably the biggest takeaway was to rethink how I was presenting my resume. I shouldn’t have the mindset of a job seeker telling prospective employers to hire me. Rather, I needed to approach it as a marketer. I’m marketing a product. The product I’m marketing is me.

This mindset is important. When you’re trying to present yourself to an employer, you feel a need to impress them with your extensive experience, everything you’ve done, and the many reasons why the employer should hire you. But if you’re marketing yourself, the thought process shifts. Instead, you’re advertising yourself and your skills. “Hire me! Here’s why!” She told me that it’s okay to not put everything on your resume — not lie, mind you, but rather, not throw in the kitchen sink when putting your resume together. Just highlight the important selling points. If they want to know more, they can refer to your LinkedIn profile — and maybe even call you in for an interview (which, of course, is the purpose of a resume).

I found this to be profound, because this is a point that I espouse as a technical writer, and yet I don’t practice what I preach when it comes to my resume. I am a believer in not necessarily including everything on a document. And yet it never occurred to me to apply my own technical writing skills to my own resume. Don’t try to provide every little detail. If they’re interested, they’ll ask for more (and if they want more, they can look at my LinkedIn profile).

I mentioned ageism as a concern, and a possible reason as to why I haven’t had a job nibble in seven months. (I believe ageism exists in the job hunt; it is illegal, but is nearly impossible to prove.) In the same vein of not needing to include everything, one of the takeaways was to only list positions for the past ten or so years. One of my concerns was that my experience before 2009 would likely reveal my age, but at the same time, it was all professionally relevant, and I didn’t want to leave it off. She suggested an idea that had never occurred to me: list the jobs (employer and title), but leave off the dates. Just say “here’s where I worked before 2009.” Again, if an employer wants to know more about those positions, check out my LinkedIn.

As an afterthought, after I’d removed the dates from the older positions, I still had a potential age identifier on my resume: my educational experience included my dates of graduation. Sure enough, in my latest resume revamp, my graduation dates will be removed. Employers just need to know I have a Masters degree; they don’t have to know when I got it.

The recruiter also asked me another question: what accomplishment at each position are you proudest of? I have to admit that that was a good question. She said that it was a question that should be asked for every listed position, and the answer for each was something that should be included on the resume.

I was told, be your own client. Market yourself. When it comes to marketing yourself, you’re your own blind spot. Only when it was pointed out to me did I know that the blind spot was even there.

You didn’t ask questions at your interview? You just blew the interview #JobHunt

This afternoon, I saw a tweet from James Phillips, who posted this:

It reminded me of what I think is an important point when you’re interviewing for a position. I responded with this:

This is a point that I emphasize in my job hunt presentation; in fact, I made mention of this in an earlier article, and I think it’s important enough that it’s worth emphasizing again. When you’re preparing for a job interview, make sure you have at least two or three questions prepared for the interviewer (I’d even prepare more that that; note that you don’t have to ask all of them). I’ve also mentioned this during Thomas Grohser’s interview presentation. I’ve sat in on his presentation a number of times (sometimes at his request), and I make sure that I bring this up as a talking point.

If you’re interviewing for a job, one of the worst things you can do is NOT ask any questions at an interview. I’ve heard several stories of people who blew their interview because they did not ask any questions — and for good reason.

When you’re interviewing for a position, keep in mind that you’re interviewing the company just as much as they’re interviewing you. You want to ensure that the position is the right fit for you — that it’s something that interests you, something you think you can fulfill, and the company culture is the right fit.

Asking questions is also a signal to the interviewer. It demonstrates that you are interested in the job and the organization. Not asking questions not only shows that you’re not interested, it also shows that you aren’t taking the interview seriously. This could prove fatal to your job interview.

That being said, it’s also important to ask the right questions (I actually wrote about this a while back). The best questions are those that demonstrate that you’re willing to be a team player for your prospective employer. For example, one question that I always bring with me to every interview is, “what is your biggest issue, and what can I do to help?” It demonstrates that I’m interested in the company, and that I’m willing to help resolve any issues that arise. Try to avoid questions that are self-centered (e.g. “what’s in it for me,” “what’s the salary range,” etc.). (That said, you’re going to want to know about the company, so try to phrase your questions in such a way that it doesn’t sound like, “what’s in it for me?”)

Whenever I prepare for an interview, I’ll research the company, and I always prepare appropriate questions in advance, such as “how can I help you solve your problems” (shows that I’m a team player), “what challenges does your organization face” (shows I’m interested in the company), or “what does your team do for fun” (shows I’m interested in team dynamics).

A resource I’d suggest is a book or website about good interview questions. There are a number of them out there (here’s a link to a few books on Amazon). Go to your local library, buy your own copy, or search Google. All of these provide good suggestions for appropriate questions to bring to a job interview.

Asking good questions won’t necessarily guarantee that you’ll land the job, but not asking questions nearly guarantees that you won’t get the job. Prepare questions in advance, and be prepared to ask questions as things come up during your interview. Don’t blow your interview by not asking any questions.

Your job application was rejected by a human, not a computer.

Last Saturday, at Virtual SQL Saturday #1003 (Memphis), I sat in on Christine Assaf‘s presentation about Organizational Trauma: Mental Health in a Crisis (or something like that — I don’t remember the exact title). I found her presentation interesting and relevant to my own; so much so, in fact, that I invited her to sit in on my presentation and offer any of her insights.

After this weekend, Christine wrote this ‘blog article. I haven’t yet had a chance to fully process it (as I’m writing this, I haven’t had my coffee yet, and my brain is still in a fog), but what little I did process, I found interesting.

I intend to scrutinize this more when I’m a little more awake. And I suspect I’ll be making some adjustments to my presentation.

HRTact

INTRO:
Recently I attended a presentation where a commonly held belief was repeated and I feel the need de-bunk this. The speaker stated “75% of applications are rejected by an ATS (applicant tracking system) and a human never sees them…”

First, I want to point out that recruiters will tell you this is false. As the main users of ATSs, recruiters have extensive experience and years in talent acquisition, and will tell you they hear this all the time and they cringe upon it’s utterance. But if you want to know my opinion on why this “myth” has infiltrated the job seeking world, scroll past all the research and jump to the end.

MY RESEARCH:
Secondly, let’s track down the origin of this false statistic. The speaker I heard it from cited topresume.com. So I did some digging:

From topresume.com

That topresume.com article (which includes the same false stat…

View original post 1,019 more words

Bad web forms — how to drive people away from your site

I’ve come across my share of bad design, and I’m sure you have as well. I’ve especially come across some egregious examples as a job applicant.

I came across one that particularly set me off. While poking around Indeed, I found a technical writer position for GitLab that interested me. Of course, most people who work in IT are familiar with GitLab, so they have a reputation. I read through the description, and it sounded interesting, so I clicked the button to “apply on company site.”

The subsequent link took me to this page.

The page talks about the technical writer roles and responsibilities. It talks about the hiring process, it includes a salary calculator, and it even talks about benefits, including stock options.

Nowhere on the page was there any link to actually apply for the position!!!

If you don’t believe me, check out the link and see for yourself. No wonder why they need technical writers. I understand and appreciate GitHub’s reputation in the IT community, but this page is seriously making me question whether or not I really want to work for them.

GitHub is far from being the only offender. I came across another page that, even after they asked me to upload my resume, it still asked me to manually input my work experience. (Even worse, these were required fields; there was no way around this. What if you’re a student with no work experience?) After I hit Submit, it came back and told me there were errors. It had cleared out all the dates I’d entered (I had entered months and years), and it insisted that I entered days. Seriously, raise your hand if you actually remember what day you started or ended a job from years ago. I have enough trouble just remembering the month or year. It made me question how well their automated formatting really worked (if it worked at all). Once I filled those in (with the best guesses for days), it told me there was another error. I clicked the message, expecting it to show me where the error was. Nope. It just told me there was an error. I had to search the entire page to figure out what it was complaining about.

I’ve come across too many forms like this during my job hunt. I also remember coming across some very badly designed forms years ago from previous job hunts — some that were so badly designed that they discouraged me from applying for the jobs.

I’ve talked about making documentation easier for the end user, and this is far from the only article I’ve written about how bad design is a detriment to anyone who needs to follow instructions. UX/UI needs to be as painless as possible for the end user. If you’re a vendor, bad design can drive away customers. If you’re an employer, you run the risk of discouraging qualified applicants.

Like good documentation, good form design needs to be well-thought-out and well-designed. Don’t be the organization that lost customers because your forms were too arduous to use.

“Your opinion matters…” Helping people by sharing your experiences

My wife and I have an anniversary coming up, so I started planning a getaway trip to celebrate. (Because of the pandemic, we decided to keep the trip short — only one night, and we’re not venturing very far — only about an hour’s drive from our home.) While I was making my travel plans, I started poking around my own TripAdvisor profile. I had posted a few reviews, and I thought I’d post a few more. I figured my experiences and opinions could help other people looking for travel information, and it’s entirely possible that, by the time you’re finished reading this article, I’ll have written a few more reviews.

One of the biggest reasons why I started my ‘blog was so that I could write about my own experiences for the purpose of helping people. Helping other people is one of my great passions, and while I can’t always help physically or financially, I can help by providing information. It’s what I do professionally, and it’s what drives me as a professional technical communicator.

However, you don’t have to be a professional technical communicator to help provide information. There are countless forums out there, covering nearly an endless number of topics, in which you are able to provide your feedback. You’re probably tired of hearing automated support lines that say “your feedback is important to us.” But feedback is important. Feedback is data. Whatever feedback you provide helps to make products and services better.

How often had you looked something up (e.g. an answer to a technical problem, a hotel review, suggested driving directions, etc.) and became frustrated because you weren’t able to find any information? If you’re an application (or any type of IT) developer, have you ever been frustrated because you asked for feedback about your product, and no one would give it to you? That feedback would’ve been valuable in debugging and improving your product. This is why QA testing is a big deal, and is usually a critical step in development life cycles.

This isn’t limited to just IT professionals. It applies to just about anything in which information is involved. If, for example, you were making travel plans and wanted information about a destination, have you ever been interested in, say, a bed and breakfast, but you couldn’t find much information about it, and no one had written any reviews about it? Those reviews would have gone a long way in providing information about that place.

A lot of us brush off the messages that say “your opinion matters.” The thing is, it really does. Don’t be afraid to express your opinion or to provide feedback. What you say can help someone make a better decision, help improve a product, or possibly change the course of someone’s business for the better.

Now, if you’ll excuse me, I’m going to go and write a few more TripAdvisor reviews…