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…

The #Coronavirus chronicles, part 16: Getting a kick in the butt when I need it #COVID19

It’s been a while since I wrote a COVID-19 update, so I think this is Part 16.

This morning, I had a text conversation with a friend who gave me a badly-needed kick in the butt.

A little background information is in order here.

I’m not going to lie. I have been very discouraged by the job hunt (going on nearly three months, now). It seems like every place that I’ve applied has rejected me — to the point that my job hunt morale has taken a big hit. I can count on one hand the number of interviews I’ve had, out of the many dozens (and counting) of applications I’ve submitted. My job situation has been a major source of stress, along with a few other things (that I won’t get into here) that have added to it. The only thing that has kept me going is my LLC. I have a couple of clients that have been keeping me busy, but it’s still not yet enough for me to pay my mortgage. I address acknowledging your own emotions at the beginning of my job hunt presentation, and I, myself, fell into the same trap.

And, of course, I have not been helped by the COVID-19 situation.

My friend — a former co-worker at my previous job — told me, in a nutshell, to get off my duff and get busy again. He reminded me of a few things that, as it turned out, I badly needed to hear: I need to learn new things, I need to keep learning and stay on top of things, I need to keep plugging away, I need to keep working, and possibly the most important reminder: I have the smarts, the talent, and the wherewithal to do great things. Don’t throw that away.

Our conversation reminded me of the many good things I do have going on, and either want to continue doing, or want to restart. My LLC has been a source of professional and educational experience during a time when I badly need it. I’d started a few endeavors during this COVID-19 crisis, including starting my new business, starting a Couch-to-5K program (which has been on-hold lately because of health issues — not COVID-19 related) and teaching myself French. There are some other things that I either started a while ago or in which I’ve been active, but have also fallen by the wayside: teaching myself BI, teaching myself GitHub, and getting back into my music, including my songwriting endeavors. I also want to make sure that I brush up on my development skills that have become rusty over time.

Some people are able to stay strong throughout this crisis (which seems to have no end in sight), while others need an occasional boost. No matter who you are, it’s easy to lose sight of things, and it’s important to have support to keep that going — which includes friends who’ll give you the occasional kick in the butt when you need it. One of the casualties of the COVID-19 crisis is that we’ve been so isolated that we don’t see our friends (other than immediate family within your household) as much as we’d like or need. Your friends are your support system, and good friends will get you back on track when you need it.

So, to my friend with whom I spoke this morning, if you’re reading this, thank you again for that kick in the butt. You likely helped me more than you know.

Check in on your black friends #BlackLivesMatter

Just this once, I’m addressing a controversial topic. I usually don’t write about these things, but I am deeply troubled by the state of my country and the world, and if, by my words, I have the power to change it, then I’m going to do it. I’m not sure what kind of effect, if any, one ‘blog article will have, but I would regret it even more if I could’ve said or done something to make things better, and I sat by the sideline and did nothing.

In light of everything that has been going on (I won’t get into that here — but by reading this article, you should get a sense of where I stand), I wanted to check in on some of my friends. So this morning, I posted this — a simple question — to my Facebook and Twitter.

To my black friends:

I wanted to check in. How’re you doing?

I was asking this question seriously. I have a number of black and African-American friends. I was concerned about their welfare, and wanted to make sure they were okay. I wanted to know how they were holding up. And especially given the current political climate, I wanted to let them know that, if they needed anything — even if all it was was an ear to bend — I was here for them.

My post was a simple and small gesture, but I wanted to send a clear message to my friends: I’m here for you, and I’m listening. I have your back.

Granted, I’m not a white person (for those of you who haven’t paid attention, I’m Asian-American). Nevertheless, I grew up in a rural and mostly white neighborhood with mostly white friends; subsequently, I’ve adopted white attitudes and mindsets. Even when I was a kid growing up, my parents had to explain this to me; I remember, as a child, being puzzled about why my own skin tone wasn’t as pale as my friends.

I did have a couple of black friends when I was young, and they are still among my best friends to this day. I never thought of them as my black friends (and I still don’t). I thought of them as my friends. Period. End of story. There was never any “black” preceding the word “friends,” and there never will be. Okay, so they looked different. So did I. Big whoop. I never had any problem interacting with them, playing sports or music with them, going to school with them, and so on.

That said, our present society is forcing me to see them as black. And I’m worried about them. The last thing I want is to read their names in the newspapers, hearing that they died for the sole reason of the color of their skin.

I want my black friends to know I’m worried about them. So I asked a simple question: “how’re you doing?”

I think, ultimately, that is how we achieve racial peace. If you’re white, and you have black friends, drop them a line. Ask them: “how’s everything going? Are you okay?” And if something’s on their minds, lend them your ear, just as you would with any other friend. Listen to them. That is what the demonstrations, protests, and riots are about: they have something to say, but nobody is listening.

Let them know you’re listening. If you hear their concerns and are able to do something about it, great. But above all, listen. Let them know that you hear them. And let them know that you have their back.

What goes into organizing a #SQLSaturday? From the words of #SQLFamily

As my friends and regular ‘blog readers are likely aware, I am a frequent speaker at SQL Saturday. SQL Saturday has shaped my professional life in ways I couldn’t have imagined. I’ve traveled to many events, learned about data topics and professional development, gained public speaking experience, become more prolific with my writing (this very ‘blog you’re reading came about because of SQL Saturday!), and met lots of great people, many of whom have become my friends. #SQLFamily is a real thing!

SQL Saturday is put together by a lot of people, and it starts with an organizer. For this article, I asked some of my friends who have organized SQL Saturday events if they could share their experiences. This article is in an “interview” Q&A format. I came up with a list of fifteen questions, and they were gracious enough to answer! Their responses are below.

Let me introduce my friends who responded. Thank you all for taking part!

1. Everyone has a “first-time” experience with SQL Saturday.  Where and when was your first?

Thomas Grohser: I am originally from Austria in Europe and I did a lot of other PASS formats (mostly SQL Rally and Summit) before my first SQL Saturday in 2013 in New Haven, CT.

Back then I was “just” a speaker, but in 2020 I am one of the co-organizers of this event. I am guessing all is coming full circle.

I don’t know if I ever been at a SQL Saturday before that as an attendee.

Ed Pollack: My first SQL Saturday was Rochester in 2011.  I went to every session I could and had a blast meeting so many new people.

Steve Jones: I may be a bit of an outsider, but my first exposure was talking about the concept and then helping Andy Warren plan SQL Saturday #1 remotely. We talked through the things that he needed to do and then had a retrospective afterward.

Most speakers were local back then, and the first event I attended was SQL Saturday #8 in Orlando as a speaker. I was amazed so many people showed up to listen to us talk about SQL Server on a Saturday.

Andy Levy: My first SQL Saturday was as an attendee at the Rochester event in 2012. It was the second SQL Saturday Rochester had hosted and I had just been clued into the PASS community in the previous couple months. Walking into it, I had no idea what to expect. I just sort of absorbed everything I could in the sessions I attended, not realizing at the time that the real value was in meeting and talking to people.

2. How did you become a SQL Saturday organizer (if it isn’t already answered under Q1)?  When did you realize that you wanted to be involved?

Thomas Grohser: I started out as a speaker, and over time began to help on the actual day of the events before and after my sessions(s). Then I got one of the NYC SQL Server user groups thrown into my lap and the second group kind of stopped doing things so I kind of got stuck with organizing one (and I also kind of liked the challenge).

Ed Pollack: As I traveled to more and more SQL Saturdays, the 3+ hour drive to each began to wear on me.  I wanted a local event that offered tech training and none like this existed anywhere near Albany.  My hope was that proximity to other cities would help draw in both speakers and a crowd.

Steve Jones: I first decided to organize a SQL Saturday as a concept. After talking with many organizers and the PASS staff, I was a bit disconcerted with the one-upsmanship that was taking place and the struggles of many events to raise thousands of dollars. Instead, Carlos Bossy and I decided to run a minimal event. We worked to keep our event under $650, with a cap of about 80 people. It was a success, and I’d like to do it again.

Andy Levy: I didn’t really plan on it. Starting with my second Rochester SQL Saturday (2013), I started getting more and more involved with volunteering. After a few years, I was asked if I wanted to take point on the event, I accepted, and here we are.

3. What is your job title or role, and does your position influence how SQL Saturday is organized?  If so, how?

Thomas Grohser: Infrastructure Architect.

I consult mostly for large corporations on SQL Server infrastructure, security, availability, and deployment automation.

I am lucky that both my employer and my clients see the benefit of the SQL Server community and support my activity. But my day-to-day skills are not a lot of help in organizing a SQL Saturday.

Ed Pollack: I’m a senior DBA, but that has little bearing on organizing a SQL Saturday.  Coordinating a SQL Saturday is about collecting expertise from all other the place and getting them on board with and attending your event.

Steve Jones: Advocate for Redgate Software. I talk to customers and potential customers about the software we build. In terms of a SQL Saturday, I have some flexibility since my company exhibits at some events. In my case, this event wasn’t related to my company, and I met with others and ran the event on my own time.

Andy Levy: My title is Database Administrator, but I don’t think what I do day to day at work significantly influences how the event is organized. I just want to bring quality content for data professionals to Rochester.

4. As those of us familiar with SQL Saturday know, schedules are usually organized along tracks (analytics, DB development, BI, professional development, etc.).  How are those determined when you plan an event?

Thomas Grohser: I first made a list of what I was interested in (I know, selfish, but hey, I might get something out of it) and then looked at about a dozen other recent SQL Saturdays and what categories they selected. The final list was a combination of the both.

Ed Pollack: The tracks are loosely defined based on what attendees ask for and how sessions logically organize themselves.

Steve Jones: In our case, we had a limitation of 3 rooms. We decided to simplify things and we planned out two tracks before we picked speakers. Our goals were a beginner to intermediate growth track and then a more general track, all in the BI area as our event was a BI version of SQL Saturday. We did this partially to support University students and partially to provide a more structured approach to BI for some attendees that might be new to the field.

Andy Levy: The one constant in our track planning the past few years has been Professional Development. The others are more fluid, but we always aim for having a Professional Development available in every schedule block. (Ed. note: as someone who presents mainly professional development topics — woo-hoo!)

5. How do you select speakers?  What do you take into account when deciding who will present?

Thomas Grohser: I selected mostly sessions, not speakers (every speaker got at least one session).

I did three rounds of grading.

Round one: I just looked at the title (no speaker name, no abstract) and graded it  — / – / 0 / + / ++  which translates to NOOO / No / Maybe / Yes / YESSS

Round two: I just looked at the abstract (no speaker, no title) and did the same grading.

Elimination: I removed all sessions that had 3 or more from the list.

Round three: I took all sessions with 4 (+) and put them on the schedule.

From the remaining sessions, I took the highest graded session from each speaker that did not have at least one talk yet.

From the remaining sessions I filled all remaining slots with the sessions having the most (+) and fewest (-).

I keep filling with sessions from that order every time a speaker canceled.

(Ed. note: Thomas told me that this grading system was how I ended up with three sessions at SQL Saturday #912! 🙂 )

Ed Pollack: We select what we believe to be the best sessions, but also need to juggle topics to ensure that there is a wide variety and that there are not five sessions on the same topic.  This is a challenging decision-making process and we often are forced to turn away speakers and sessions because of the need to build a well-balanced schedule.

Steve Jones: We picked topics first and then choose speakers that we thought would do a good job. Our goal was to use mostly local speakers, and we did,  usually choosing those we had seen present. We took a chance on a few speakers, gambling they would do a good job based on some internet research. Jonathan Stewart was one that we didn’t know anything about, but we’d heard good things and liked his topic. He did a fantastic job.

Andy Levy: Selecting sessions is more difficult than selecting speakers. We want to make sure we’re bringing fresh content to our attendees each year, with a good variety. If we can find several sessions with a common thread, a natural progression where each session builds upon the one before it, we’ll often look at those as a single “block” and schedule accordingly.

6. Pre-con sessions — same question as Q5: how are they determined?  What is taken into account?

Thomas Grohser: I was not involved in that part.

Ed Pollack: This is a far more in-depth process as the stakes are much higher.  Precon speakers cannot cancel and there is no wiggle-room on quality.  We accept precon speakers that we know will show up, do an amazing precon, and draw in attendees to SQL Saturday.  Similar to SQL Saturday, we often get multiple precons for the same topic and will be forced to choose one over the other as we cannot run multiple precons that appeal to the same audience.

Steve Jones: None. We decided not to deal with this as it increases complexity and budget.

7. Venues are a major part of planning.  Among other things, location, size, costs, lodging, and availability are factors.  How do you choose your venue, and what do you take into account?

Thomas Grohser: I was in New York. I have only one choice: the MTC (Microsoft Technology Center) in Time Square. Everything else is too expensive. We asked for the first available date after May 1st  and got October 6th.  🙂

Ed Pollack: We chose a big venue.  It costs money, which is a downside, but it provides unlimited space for sessions, sponsors, and event logistics.  Lodging is nearby and it’s very easy to get to UAlbany.

Steve Jones: We wanted to find a free space to keep the cost down. We reached out to contacts at local universities, and ended up partnering with Denver University, in the continuing education department. We started this over six months before our event, having a quarterly meeting over lunch (we provided one, they the other) and discussing how we could work together to better educate people. I know Andy Warren in Orlando does this with his local university, usually meeting with them 2-3 times a year as a social event to maintain a connection.

Andy Levy: We’ve always hosted SQL Saturday Rochester at the Rochester Institute of Technology (RIT). How we landed there in the early years, I honestly don’t know (I wasn’t involved with planning the first two years). But they’ve been a terrific partner and sponsor for the event and without them, I think we’d have a very hard time running the event every year. Being a technology-focused institution of higher learning, and the particular building we’re hosted in being the home of Golisano College of Computing and Information Sciences, it’s a great setup for SQL Saturday. We use regular classrooms with good projectors, every modern A/V connection you can think of, and excellent internet connectivity.

With Rochester some very large businesses and research facilities in the area in addition to several colleges and universities, every major hotel chain is represented nearby.

8. Organizing a SQL Saturday undoubtedly takes up a lot of time!  How do you balance that with all your other commitments — work, family, extracurriculars, etc.?

Thomas Grohser: You need to do it as a group. We started as four, and three of us made it to the finish line. Each one does the assigned tasks and then you coordinate once a week.

We split it this way:

  • Sponsors / Attendees and PASS
  • Speakers / Schedule / Signs / Rooms
  • Precon / Food

We all did some “marketing”. This setup gave each one of us a reasonable amount of work (< ½ h per day) leading up to the event and full day of action the day before and the actual day.

Ed Pollack: I have recruited a group of amazing volunteers to help with sponsors, marketing, event logistics, and more!  Without them, this would be impossible to plan while maintaining my sanity!

Steve Jones: The smaller the event, the less time and effort. Removing items like the pre-con, shirts, etc. reduced all this effort. We had 4-5 long lunch meetings for planning where we worked out the schedule, discussed details and then kept notes. Across a few weeks, we communicated at night to ensure we were organized, sent emails to speakers and volunteers, and kept working on the event slowly. It helped that we had a minimal event and we were organized people. With two of us running things, that lowers the overhead of effort and communication as well. This wasn’t too hard to fit in around family/hobby/etc. time, but it was an effort. Since then, we haven’t been able to do this again as our schedules have been too busy at different times. I think we would need to be sure that we could dedicate spare time every week for 3 months to run this again. Finding that time has been difficult.

Andy Levy: If I’m being completely honest, I balance them pretty poorly in the final weeks before the event. Obsessing over weather impacting travel plans and attendance, ensuring sponsor packages have arrived, the registration counts, getting resources reserved at the venue, etc. I’ve been known to sit off in a corner at a Cub Scout/Boy Scout meeting working through SQL Saturday administrative stuff.

9. SQL Saturday doesn’t happen without vendor or sponsor support.  How do you go about getting that support?  How do you keep them engaged?

Thomas Grohser: Honestly, all we did is used the PASS-provided website to send out a communication to previous sponsors and they contacted us. The main work was adjusting the sponsorship levels to the needs (some wanted a sponsored session, some not, some wanted to provide material, some not…).

Ed Pollack: Local sponsors are key.  We maintain a set of local sponsors that know us and who have been supporting us for a long time.  These are local companies that see SQL Saturday as a great way to advertise, market, and recruit.  Without them, we would not be able to put on SQL Saturday!

Steve Jones: We avoided this with the PASS Global sponsorship. We received $500 from PASS/Microsoft and then accidentally got $150 because we didn’t close down the sponsorship pages when the event went live. As a result, we didn’t have to worry about vendors.

Finding vendor support is hard, and it can be a time sink for many larger vendors with 100 SQL Saturdays a year. PASS and other organizers can help you with larger vendors, but I always encourage people to work with local companies when they can. Talk to recruiting and consulting companies. Take some time to have lunch or short meetings with them. Reach out to colleges, especially those serving adults, and work with them for sponsorship. This is a personal part of the event and it takes time across time to keep them engaged. We did continue to meet with the college a few times before the event and once afterwards to talk about how things went. Ultimately, they have continued to support the larger Denver SQL Saturday each year.

Andy Levy: Sponsorship is the perennial challenge for smaller SQL Saturdays. We rarely get sponsorship from local companies. We just have not managed to solve the puzzle of how to reach them. So, we’re more dependent upon national-level sponsors, often ones that we have pre-existing relationships with through other channels. When we hear suggestions from sponsors for things that they’d like to see, we give them strong consideration.

10. Let’s talk about volunteers, who are also a big part of SQL Saturday (and often don’t get the credit they deserve).  Where do they come from, and what kinds of things do they do?

Thomas Grohser: I “volunteered” a few of my co-workers and they paid it forward by “volunteering” some of their family members (BTW a great way to teach your teenage kids what work is).

Again the PASS website’s opt-in as volunteer after a single call for help during the user group meeting before the event added more volunteers than we needed.

Ed Pollack: Volunteers come from all over!  Some are members of our local user group, others are students at a local university.  Others are attendees that check off the box to volunteer.  Some are speakers, sponsors, or members of PASS.  The diversity of the group is its greatest asset! They handle much of the on-the-ground work at SQL Saturday, from setting up food to staffing the registration table, and cleanup.  Their contributions are huge and I do everything I possibly can to thank them for their invaluable help!

Steve Jones: These are usually friends or acquaintances from the UG or other sources. In our case, we have a strong community in Denver and 4-5 friends that signed up to come and were happy to handle tasks on the day of the event (signs, carrying supplies, etc.).

I think the key is reaching out to people, giving them something specific you’d like them to do, thanking them, and ensuring that you aren’t overburdening any one person.

Andy Levy: We put out a call for volunteers both to our registered attendees and our user group. For day-of assistance (registration, room monitors, generally helping speakers and attendees), our volunteer wrangler Kim works with folks who have offered to help and always finds a few more.

11. Of course, attendees usually expect to be fed!  Most (if not all) SQL Saturdays I’ve attended charge a nominal fee for lunch.  How are food and beverage arrangements usually handled at your event?

Thomas Grohser: Since we are locked in with the MTC in Time Square, we are also locked in with the choice of one of the three “approved” catering companies. This, and an SUV full of soda cans and snacks from Costco kept all people well-fed, and the leftovers went to a nearby shelter.

Ed Pollack: We order our own breakfast (donuts/bagels) and lunch (subs & snacks).  Breakfast we pick up and manage ourselves whereas lunch is delivered to SQL Saturday.  All of the supplies we need are purchased ahead of time in bulk and transported to the event by volunteers, such as cups, napkins, drinks, and so on.  We also purchased large coffee urns for the user group to brew our own coffee.  This is far cheaper and easier than making runs to coffee shops and paying hefty prices for that much coffee on the day of SQL Saturday.  We always have a highly caffeinated volunteer that is happy to keep the coffee supply operational 🙂

Steve Jones: In our case, we decided to forego food. The venue was a block from the edge of campus with numerous restaurants, so we allowed 90 minutes for lunch and encouraged people to go in small groups. I tried this years ago at the PASS Summit, bundling people into groups of 4 and sending them to restaurants and it worked well. Here the cost and overhead of lunch was removed with this effort. We did purchase some breakfast food, snacks, and coffee for the morning and water for throughout the day.

I could actually encourage some smaller events to try this as well.

Andy Levy: Matt takes care of this piece of our event. He has a caterer he knows and they take care of lunch, the big coffee pots that fuel every event. He also makes sure that our speakers have food and drink in the ready room.

12. Each locale offers its unique culture or environment, and one of the things I love about SQL Saturday is that it often reflects that culture.  What are some of the things that make your event unique?

Thomas Grohser: I do not believe the NYC SQL Saturday was special. (Ed. note: I beg to differ! 🙂 )

Ed Pollack: Our venue is 100% unique and special to us.  UAlbany provides an amazing location in the summer, with lots of space and access to the fountain right outside of the conference area.  We also have the best volunteer team out there and they make our event both special and a joy to run!

Steve Jones: In our case we were on a college campus and aimed for a BI focused crowd. We had a variety of attendees, many of whom didn’t come to the local user group meeting and I hadn’t met before. Overall, the small size made this a more intimate setting.

Andy Levy: The looming spectre of a blizzard. 🙂

13. I, personally, work in an Oracle environment (yes, it’s true), and most of my coworkers think SQL Saturday doesn’t apply to them (believe me, I’ve tried).  As an organizer, what would you say to people (especially data professionals) who don’t think SQL Saturday is for them?

Thomas Grohser: From a community perspective:

It’s an event for the SQL Server community. The content should help newbies get started and old timers to deepen their knowledge. All the good SQL Saturdays also have professional development tracks and sessions just touching concepts and ideas. So even an Oracle DBA should be able to have a great day. If they don’t want to, it’s not my job to force them.

From an organizer perspective:

Instead of bringing your reluctant Oracle DBA, bring your manager, CIO, CTO.  The sponsors will love to talk to them.

Ed Pollack: While SQL Saturday is billed as a SQL Server/Microsoft event, most sessions are not technology-specific.  Many topics such as analytics, data science, database design, professional development, and hardware architecture are platform agnostic and can apply to anyone.  Since SQL Saturday is free, it’s an easy sell to anyone on the fence about attending: Free breakfast, lunch, training, and prizes…what more can you ask for?

Steve Jones: The world is expanding and there are always generic sessions on data topics. I would encourage people to look at the schedule and decide for themselves. I’d actually like to see more non-SQL specific topics presented and spread throughout the day.

Andy Levy: I encourage anyone who works in any tech-adjacent role, data or otherwise, to attend a SQL Saturday. The professional development sessions aren’t technology-specific at all. The networking opportunities are great. If you drop in on a random session, you just might learn something new. Better yet, it may spark an idea or some interest, something you never even knew existed previously.

14. Like any large-scale event, SQL Saturday almost never goes off without a hitch.  Are there any memorable mishaps that occurred, and how were they handled?

Thomas Grohser: Unfortunately there is a size limit on emails so I have to shorten the list:

Projector not working → No problem we have a spare room for exactly that case → Nobody can find the key → All attendees gathered around a 24” monitor till someone found the key

The venue was supposed to let us in at 7:30 am, The first session was scheduled for 8:30 am, they opened the doors at 8:45

Ed Pollack: We had lunch show up a half hour late one year.  The delivery person got lost and didn’t call for help.  After rushing to find us, they forgot the vegetarian food!  We had a few dozen angry attendees that were looking for veggie food and didn’t have it (yet).  We sent a few volunteers to the restaurant to pick up the remaining food and return with it as quickly as they could.  The end result was some attendees that were unhappy, but we did our best to talk to them and let them know the problem would be solved shortly.  Some good customer service goes a long way towards softening the blow of mistakes or mishaps at what is always a busy day.

Steve Jones: Nothing for us.

Andy Levy: In my experience, the best way to handle mishaps is to not talk about them to a wide audience unless you have to. Remain flexible and be prepared to improvise; if you can adjust to accommodate a mishap, people don’t have to know there was one in the first place.

Be accountable for what happens, admit your faults where applicable, don’t throw people under the bus, and do your best to make amends when necessary.

15. Finally, any other thoughts, ideas, issues, or comments that you think should be mentioned that I didn’t think to ask?

Thomas Grohser: The toughest part is at the very beginning: You need to find a date, a venue and get the date approved from PASS. This is not easy, with all the rules around when and where another SQL Saturday can be at the same time.

Ed Pollack: Attend SQL Saturday.  Consider speaking and volunteering.  It’s a great way to learn new things, problem-solve, meet new people, advance your career, and have fun!

Steve Jones: I think the idea of large events is nice, but they come with a large amount of overhead and effort. They take a toll on organizers and can be hard to maintain over time. I’d much prefer to get smaller events, and have more of them. I think a 100-150 person event is more sustainable and likely to be much easier and cheaper to run. I hope that more communities will think about focusing on easier/smaller events, fewer tracks, and try to do 2 a year rather than one large one. Focus each in a data related area, keep things simple, and remember most people are looking for some learning and inspiration, not necessarily a big party.


I thoroughly enjoyed putting this article together! Thanks, Thomas, Ed, Steve, and Andy for taking part!

For those of you reading this, I encourage you to check out their ‘blog or article links (at the top of this article).

Thanks again!

When you make it hard for your customers to respond

This morning, I had an issue with my LinkedIn account. I was trying to reply to a message, and I kept getting “Send failed.” That was all I got — there were no error codes, additional information, or symptoms. I poked around LinkedIn’s Help section, and came across this page for dealing with messaging problems. I didn’t go as far as to clear my cache, but I did log out and back in, and I tried it in a different browser, all to no avail. In the middle of contacting LinkedIn’s support, the problem mysteriously “fixed itself.” If you work in tech, I don’t have to tell you how frustrating it is for an issue to mysteriously “fix itself.”

However, the issue I had, in and of itself, is not why I’m writing this article. When I heard back from LinkedIn, I got a message saying “go to this page” (the one I’d already found) and use that to troubleshoot. In response, it displayed the interface you see above. As you can see, they only gave me two options: “yes, I’m good,” and “no, I still need help.” The problem was, my response was, neither. No, I didn’t need help at that point, but I also wasn’t completely good, either. I wanted to inform them what had happened in case they wanted to investigate it further. But they did not give me that option. Between those two options, I clicked “yes, I’m good,” which immediately closed the case; I had absolutely no recourse to add more to it. I looked around for ways to send feedback, but I did not find any good way to do it. Replying to the email resulted in a response saying “you responded to an unmonitored mailbox.” The more I looked for a feedback mechanism, the more frustrated I got. The issue quickly went from “I’m reporting a technical issue” to “you guys need to fix your UI/UX.”

I’ve written before about how critical it is to get feedback, and how design can be a big deal. As much as I like LinkedIn as a business networking tool, I felt that LinkedIn fell short on both of these facets.

Let me start with the UX/UI design. I strongly felt that only those two options, especially if answering “yes” automatically closed the case, was a very poor design. As many people will tell you, the answer often isn’t simply “yes” or “no.” (One of the long-standing jokes among DBAs is that the standard DBA answer is, “it depends.”) And even after I clicked one of those buttons (in this case, I clicked “yes”), the interface was confusing. I was brought to a page that said “click to enter more information” (or something like that). The problem was, click where? None of the “links” allowed me to enter anything else, and there was no clearly logical eye path for me to follow. I had no idea what I was supposed to do once I got to that page. I kept clicking different links, trying to leave feedback. By the time I found a link, I wasn’t even sure that I was replying to my original query. I had no idea to what — or even where — I was responding.

I’ve said time and again that if you’re a technical writer — or a UX/UI developer — you don’t want to make your reader or end user work. Reading is work. Making your end user work is a sign of poor design.

Second, this experience made me question just how seriously LinkedIn takes feedback. True, nobody wants to hear bad feedback. I know I sure don’t. But if you want to improve, you need to know what it is you need to improve. How am I supposed to improve something when I don’t know what it is that I’m doing wrong? Not including a channel for feedback — or making it difficult to do so, as I allude to above — is doing a disservice to your organization and to your clients.

Good communication between you and your client is important. Not only does it help your client, it helps you improve your organization, and it builds trust between you and your customers. Making it difficult for your customers to communicate alienates them — and ends up hurting your business in the long run.

The symbiotic relationship between documentation and application development

One of my current projects involves documenting processes for an application that are still under development. As such, much of what I write may change, depending on how processes are changed during the course of development.

At one point, I tested one of the processes so I could determine functionality and document it. In doing so, the process came back with an error message that I wasn’t expecting and didn’t have any user-friendly information, other than a cryptic error code. I contacted one of the developers working on the application and told him what I found. I gave him the error codes I experienced and steps I took to get them. He told me, “you’re coming across bugs that we didn’t even know we had.”

It occurred to me that I was doing more than just documenting the application. I was also acting as a beta tester.

One aspect about writing technical documentation is learning about what you’re writing. In order to write about a process, you need to understand how it works. If you’re documenting an application, the best thing you can do is run the application in a safe environment (such as development or a sandbox), learn how it works, and use it to document steps and capture screens. In doing so, you come across application bugs and even come up with ideas to make the application even better.

I’ve long argued as to the criticality of documentation. It records important information and serves as a reference. However, until this point, it didn’t occur to me that the document development process could have a symbiotic relationship with application development. To me, this adds further fuel to the argument that documentation is critical and required.

Testing is important for documentation, too

For those of you who produce documentation, how often have you sent your documents out into the real world, only to have it returned to say it’s all wrong? Or have you ever received feedback saying things like “this is difficult to read,” “I can’t follow this,” and so on?

One of my most frustrating aspects of technical writing is any time — every time — that I ask people to review what I write, my request goes ignored. As I’ve written before about the nature of documentation, requests for document review are often met with indifference and disrespect. A lot of people just don’t think it’s important. It is critically important. I don’t always know about the subject that I’m writing, and I’m often at the mercy of subject matter experts (SMEs) who know more about the subject than I do.

It’s not just the subject matter, either. I’m the first to admit that I’m a grammar snob, but I’m also not perfect, either (I was not an English major, after all). Many a time have I confused “who” and “whom,” ended a sentence with a preposition, used an apostrophe-S for a possessive, forgotten to put “I before E,” and so on. Likewise, I try my best to design documentation for better readability, but I also realize that there’s always room for improvement, and it often takes another set of eyes to provide a way to make something better than never occurred to me.

I’ve argued before that documentation needs to be treated like software. Like software, documentation has a life cycle. It needs to be maintained. And as such, it needs to be tested. Documentation, like software, will have bugs that need to be addressed.

It also isn’t just a matter of reading a document and saying “yeah, this looks good.” User testing should also be a part of it. If you’re writing step-by-step instructions, how will you know if they’re accurate? Back when I was a grad student at RPI, one of my writing projects included user testing as part of the project. I wrote a set of instructions for a procedure in my office (the document served a dual purpose for me — not only was I getting graded for it, I was also contributing to my workplace). To test it, I asked one of my co-workers to follow it as she went through the procedure I’d documented. She caught issues with my steps that I never would have caught on my own. From that user testing, I corrected the issues and made the document even better.

As a technical writer, I expect — and demand — people to review, test, and scrutinize what I produce. I demand excellence from myself. In order to achieve excellence, I need other people to review what I do. And I want to know that what I’m producing is of good quality and factually accurate. Without that critical feedback, I’ll likely not know whether or not I’m doing my job.