Skip to main content

Kimberly Blessing

The Web (Browser) We Forgot

1 min read

Earlier this month I spoke at the O'Reilly Fluent Conference about the browser that truly popularized the Web in its infancy -- the line mode browser. The video of my keynote is online, as well as an interview where I talk about everything from the line mode browser to the problems of modern-day developers.

Kimberly Blessing

Q&A with Technically Philly

1 min read

Some insights on how I built a 10-person tech team at Think Brownstone that's nearly half women, and other thoughts on diversity in the web/tech field. Read the interview.

Kimberly Blessing

Shop Talk Show #85

1 min read

Chris Coyier and Dave Rupert invited me to join them on Shop Talk Show to -- what else? -- talk shop. We chatted about my trip to CERN, employer size, portfolios, and code-related stuff. Check it out!

Kimberly Blessing

Interview during LMB Hack Days

1 min read

I am so fortunate to have had the opportunity to participate in the Line-Mode Browser Hack Days at CERN. In this interview, I speak about why I think experiencing the line-mode browser is important today.

Kimberly Blessing

Geek Talk Interview

1 min read

I recently did a short interview with The Geek Talk about how I got started with programming, my work day, and other geeky things. Check it out!

Kimberly Blessing

Web Developer Job Search: Your Resume

6 min read

I estimate that I have spent a full work-week, over the course of my career, reviewing web developer resumes. That's enough time to produce some strong opinions on the topic. Allow me to finally continue the Job Search thread by sharing my advice for creating a top-notch web developer resume.

Resume Format and Structure

Your resume format should work to highlight your strengths. The chronological resume, perhaps the most traditional format, fails in this regard. A functional resume does a much better job of highlighting your experience in a specific role, but most web developers are good at more than one thing. I suggest mixing aspects of the two formats, organizing them in a way that makes sense for you and your strengths -- then you'll have a resume that stands out.

Here are the general sections found in a great web developer resume. With the exception of the first two, the rest can be ordered and/or further broken out according to your needs.

  • Objective: If you're searching for a job, you ought to know what you're seeking! Customize your objective, as needed, when replying to job postings. (Note: If you're not actively seeking a job, but still want to have a resume posted online, it's okay to omit this section.)
  • Summary of Qualifications: It's a cheesy headline, perhaps, and all too often the summary is filled with buzzwords -- but I have read really compelling summaries that made me want to know more about a candidate. Focus on describing your strengths and what you contribute to an organization.
  • Skills: This is where the keywords and buzzwords will start showing up. That's okay: you'll back them up with evidence in the other sections. You can subdivide this section in any number of ways: Technical vs. Soft Skills, Front-End vs. Back-End Skills, Design vs. Development Skills, etc.
  • Professional Accomplishments: Here you can include project accomplishments, awards, public speaking engagements, publishing credits, or descriptions of really awesome things you've accomplished. Like the Skills section, you can also break these out separately.
  • Work Experience: If you've done any combination of full-time work, freelancing, and volunteering, this is the most generic title you can use for your work history. Some people like to break out their professional experience from other work, but I think that can undermine the importance of having taken on freelance or volunteer work. If you list accomplishments for each job in this section, don't repeat them elsewhere, and vice versa.
  • Education: I don't like to see this section missing from a resume. Haven't gone to college? That's okay. Be proud of what schooling you have made it through and list it here. Oh, and that includes training programs, conferences -- anything you've forked out money for that you've learned something from!

Required Information

If your resume were to consist of only two things, it should be these:

  • Contact Information: You'd think this would be a no-brainer, but I have seen resumes where developers didn't list a phone number, email address, or personal web site (more on that below). In my opinion, it's a waste of space to display your full home address, especially if you are looking to relocate. No one's going to snail-mail you an invitation to interview, so city and state will suffice. HR will collect the rest of your contact information later.
  • URLs: I wish I could tell you exactly how many of those ~500 resumes didn't include a single URL... but my gut says that at least half didn't feature even a personal web site URL. Seriously? If you're a web developer, you should have some URLs to share. If you're brand-new to the field, put some of your school projects online. If you've only ever done intranet-type work, get permission to copy parts of the code and make it available, or create other projects of your own to demonstrate your skills. If you're serious about getting a web development job, you need this.

On the flip side, don't waste space on these bits of information: references (or the phrase, "References available upon request"), GPA, salary requirements, or personal information (except if you have hobbies that would be of interest to another geek and would increase the likelihood of getting invited in for an interview).

Frequently Asked Questions

Does my resume have to fit on to one or two pages? No, I don't think that it does. However, I think it's nice if a resume is so well edited and structured that, when printed, it fits to exactly one or two pages (one page if you're young, recently out of school, or switching careers; otherwise two pages). However, if you truly have so much awesomeness to report, then, by all means, go on! If you're really that super-duper, I'm sure I'll want to know all about it.

Does one resume fit all jobs? NO! Don't be afraid to tweak your resume format or content to the job you're applying for. In fact, if you have diverse enough skills and interests (design vs. development) you should probably have completely separate resumes for these purposes.

I am graduating soon and don't have much web development experience. What can I do to beef-up my resume? Use the "Objective" area to make it clear that you're looking for an entry-level position. Highlight your strengths in the "Summary of Qualifications" area and place the "Education" section next, so it's clear you're just coming out of school. List your technical skills, as well as any soft skills that you can support with extra-curricular or volunteer work. If you have been active in a tech community or have attended technical or web conferences, list those.

I'm switching careers. I've taken some web design and development courses and done some small projects. How do I reflect all of this in my resume? First, don't hide the fact that you're switching careers! Your prior experience, even if in a completely different industry, has (hopefully) taught you how to deal with people and has helped you understand your strengths. Start your resume with an "Objective" statement that spells out your desire to move into web development. Then list your skills, training and experience with the web so far before providing your employment history and other educational details. Highlight any experience that translates across industries, but otherwise keep the non-web details short.


I hope the above helps you create an awesome resume. Remember, your resume (supported with at least one awesome URL) helps get you in the door for an interview, so take some time to craft one that truly reflects you!

If you have questions I haven't addressed above, I'm happy to accept them in the comments below.

Kimberly Blessing

Web Developer Job Search: Interviewing Tips

4 min read

Obi-Wan Kimberly Blessing That's me conducting a speed interview during my Speed Interviews session at WebVisions 2010

I've interviewed a fair number of web developer candidates recently, and many have followed up with me afterwards for feedback. The number one question I get? What else should I have known or said during the interview to land the job?

This is a pretty easy question for me to answer, so let me give all of you some insight into what I'm looking for, as a hiring manager and interviewer:

  • Have an opinion. This doesn't sound too tricky, right? But in order to have an opinion, you have to have some knowledge and/or experience. For example, if I ask someone what their favorite browser is and why, it's going to be easy for the person to come back with a response -- likely based on what they use everyday. So why is it so difficult to tell me what doctype you prefer to code against, or whether you like or dislike reset CSS? To me, not having an answer means that you either don't know what these things are or don't have experience with them. Oh wait, you do have experience, but you don't want to voice an opinion that would be contrary to my own? Your interview is not a time to be timid! State your case and let me at least know that you know what you're talking about. I certainly won't judge you negatively for that.
  • Know some HTML5 and CSS3. There are lots of HTML5 jobs opening up, and even those employers that don't presently advertise the need will want these skills in the future. What, you haven't learned any HTML5 or CSS3? You're a professional, right? The excuse that your current job doesn't support you trying these things doesn't fly. There are plenty of websites and new publications out now to help you get up to speed in your own time. Plenty of shops are currently looking at switching to HTML5 and adding CSS3 features, and they want people who are able to contribute to these efforts from day one. Believe me, you don't need a lot of time to pick up some knowledge -- in just a few hours you can learn quite a lot!
  • Admit that you don't know. Sometimes interviewers will throw you curveball questions designed just to get you to say one thing -- "I don't know." Yes, it can be mean, but it does have a purpose: are you someone who will bullshit your way through an interview, and then possibly a job? Or are you willing to admit that you don't know something -- and in that case, are you the kind of person who shuts down, the kind who asks for help understanding, the kind who says "I'll go learn about that and follow up"? It should come as no surprise that I like the latter kind of person. But there's an even more practical reason for this: you may misunderstand a question, or the interviewer may not ask the question in a clear manner, or you may not be able to give a direct answer to a question but you could speak about something related. Saying you don't know, but that you're going to try to answer the question in the way you understand it, shows patience and diligence -- and may just expose some additional skills or knowledge. Don't hesitate to say it.

Want some more interviewing tips? Back in May, I ran a session at WebVisions called Speed Interviews. In it, I gave some tips to help the audience have a great interview experience, and then I conducted a number of 2-3 minute interviews on stage. It was a fun but challenging experience for me! My slides are online and I welcome your questions about interviewing. Good luck!

Looking to learn more about HTML5?

Kimberly Blessing

Celebrating Ada Lovelace Day 2010

8 min read

My Ada Lovelace Day post is a two-parter: the first part, recognizing two women who inspired me in math and computing; the second, recognizing Milly Koss, an inspirational and accomplished female computer scientist.

Ada Lovelace Day is an international day of blogging to celebrate the achievements of women in technology and science. Learn more

Mrs. Smarkola, Miss Herrick, and the Dawn Patrol

Article about The Dawn Patrol From the Grace Park Mini News, an article about Dawn Patrol by yours truly, circa 1985.

I am so fortunate to have been raised in the 80s, during the emergence of the personal computer. My school, Grace Park Elementary, and my teachers were excited about the TRS-80s and Apple IIes in the classroom, and many kids had Commodore 64s at home. Our teachers saw us get excited about learning; we were having fun playing with new toys our parents never had.

Our librarian, Mrs. Smarkola, was one of my most favorite people at school. When I think of her, I always imagine her with a large book in hand, head down, adjusting her glasses, focused on her reading. But I also remember her running the classroom full of typewriters and computers which was across the hall from the library. She'd walk from computer to computer, typing commands, turning them on or off, inserting tapes or disks, making sure each computer had an instruction sheet or book for the next activity. Around the time of fourth grade, a few of those computers moved into the library itself, and the whole school used them to check out and return books -- under Mrs. Smarkola's watchful eye, of course.

My fourth grade teacher, Miss Herrick, was one of those teachers that all of the kids in school were afraid of. Kids talked about her being "hard" and "mean" -- but when I got in to her classroom, I was in heaven. You see, Miss Herrick loved math. I loved math. We were a perfect match! She frequently gave us math quizzes with long division problems, which I always aimed to complete first -- because the first to finish got to "play" on the computer we had in the classroom. I'd guess that I spent more time on that computer than anyone else, and I think I was also the classroom "computer aide," to help other students with it. (BTW, to this day, I love doing long division in my head when I'm bored.)

So many of us kids at Grace Park were interested in computers and learning, that our awesome principal, Dr. Joseph Fleischut, authorized a program called "Dawn Patrol" which was run by Mrs. Smarkola and Miss Herrick. For kids who signed up and got to school about 30 minutes before the opening bell, it was a time to use the computers, typewriters, and library. As you may have guessed, I signed up nearly every day. It may have been during Dawn Patrol that I programmed a TRS-80 CoCo 2 to play the harmony to "Yesterday" by The Beatles, so that it could accompany me as I played the melody on the flute. (When I got to perform at the district concert with the computer, it choked under the hot lights of the stage, sadly.) It also may have been there that I first attempted to program a Joshua-like AI from WarGames. I definitely spent time playing the Oregon Trail and Carmen Sandiego games there, as well as being questioned by Eliza. But what I remember with the greatest certainty (and the utmost thanks!) were the ways in which Mrs. Smarkola and Miss Herrick (and Dr. Fly, too) encouraged me, nurtured my passion for math, computers, reading, and learning, and always praised me for my accomplishments -- key factors which recent studies say are crucial to getting more women in to STEM.

Adele Mildred (Milly) Koss

Milly Koss and Me I was introduced to Milly Koss in September 2006 when a historical marker was placed at the site of the Eckert-Mauchly Computer Corporation.

Milly Koss "had a distinguished career of more than 47 years in all phases of computer technology, implementation and management, including applications design and development, software/hardware selection, database technologies and computer security." Her name is known to some -- but not enough, in my opinion.

Milly was raised in Philadelphia and attended the selective Philadelphia High School for Girls. She earned a scholarship to attend the University of Pennsylvania in 1946, at a time when schools were primarily giving spots to veterans. She graduated in 1950 with a degree in mathematics. In the early days of computing, women were seen as ideal computer programmers due to their "patience, persistence, and a capacity for detail." Of course, in order for a woman to get one of these jobs, she had to have a degree in math and not be married. Milly Koss qualified on the first point, but not on the second: she was engaged. The first company she interviewed with rejected her for this reason.

Fortunately, she was in the right place -- Philadelphia was home to the Eckert-Mauchly Computer Corporation and, from the way Milly describes it, I imagine it to be a workplace much like any modern internet company -- except that 40% of their programmers were women. Milly interviewed with Dr. John Mauchly, who she described as being very nice, flexible, and open. He gave her a wonderful, exciting, creative job -- working with the UNIVAC.

Milly worked with Grace Hopper and was responsible for developing Editing Generator, a problem-oriented language for computer-generated reports, in 1952. Milly was interested in what "computers could do for programmers... how it could help programmers program." She also worked on sort routines for years, which she calls "the quintessential program for machines." She reminds us that today we should be grateful for that early work in automated programming, interpreters, assemblers, and compilers.

By the way, much of this she did while working part-time and remotely! According to Milly, when informed about her pregnancy, Grace Hopper told her to "take it home" -- meaning, the work. Milly would go in to the office one or two days a week, otherwise working from her dining room table. In an interview with Kathy Kleiman (who is the driving force behind the ENIAC Programmers Project), Milly said:

"What’s funny about that period, I’m not sure who my boss was. This was such an unstructured environment… Once I had a child they let me continue to work the way I wanted to. I inferred from that I was of value to them. Nobody lets you work that way unless they are getting value. I got increases. I got paid fairly well. Eckert & Mauchly was pretty good that way… There were no models, they didn’t care how you worked. There were no preconceived notions as to the way you could contribute. You did not have to be in the office…. We did not have huge management teams. We did incredibly new and exciting things and nobody had a problem.”

Milly later went to work for Burroughs Corporation, Philco, and Control Data Corporation, and Raytheon. At Burroughs and Philco she continued her flexible work schedule and would send her work in by mail! At CDC, she worked with early graphics algorithms and interfaces including light pens. Then Milly moved to Harvard University, where says she finally started feeling the hierarchy and loss of flexibility. She spent 27 years at Harvard, in multiple roles. She applied data management expertise to applications for the school and led an R&D effort to develop one of the first data warehouses, the Information Utility. She served as Associate Director of the Office for Information Technology and as the Information Security Officer for the university.

Milly retired in 1994. In 1997, she received a Pioneer Award at the Grace Hopper Celebration of Women in Computing. In 2000, she received the Ada August Lovelace Award from the Association for Women in Computing. With her many years of contributions to the field, I'm sure she also inspired many people -- women and men alike.

Additional Resources

Kimberly Blessing

Epic Management Fails

6 min read

"who's able here to honestly say 'I have a great boss'?" two hands raised... 320 persons in the room... Via Daniel Glazman on Twitter

Although I always identify myself as a technologist, I've been managing people for a while and that is the primary focus of my full-time work. Managing people is an art, not a science. It's very hard work, and I didn't completely understand this before becoming a manager. Honestly, I don't think most people -- even managers -- understand how hard of a job this can be.

I think that I've become a pretty good manager -- with time and experience, with feedback and mentoring. There were times when I wasn't so great, though. In an attempt at radical honesty (hat tip to Erica O'Grady), here is a list of my epic management fails and what I've learned from them.

  • I tried to keep my hands in the code. Somewhere I once heard that coders who become managers and still try to write code only do so because they're arrogant and they end up sucking at both. While I don't agree 100% with that statement, I can agree that diverting focus from management responsibilities can have a negative impact on people and projects. As a manager I've gotten so deep into code that I've trampled on the responsibilities and goals of my direct reports. I've also made commitments to deliver production-ready code but then been so distracted by management responsibilities that I caused project deadlines to be missed. While attempting to code for production work isn't a good idea for managers, I think that coding for practice -- to keep one's skills in shape or to have experience with what the team is working on -- is definitely a good thing. A technical manager who can coach a team on both a personal and a technical level is a huge asset.
  • I didn't prepare for one-on-one meetings. One of the top priorities of a manager is meeting with direct reports on a regular basis to review expectations, set and track progress of goals, provide feedback, and coach for achievement. If you ignore this responsibility as a manager, you're not doing your job, period.* Over time, I've realized that some managers avoid these meetings because they're not prepared. I've certainly made the mistake of meeting with an individual without having an agenda, or without having deliverables ready. Ever had an awkward review with your boss? Chances are, it was awkward because they weren't prepared. I find that I have to practice difficult conversations before I walk in to a meeting, and I even like to rehearse giving feedback. When I'm nervous about a meeting, I know I'm not prepared. When I realize this, I'll try to reschedule the meeting or, worst case scenario, I'll admit to being unprepared and beg forgiveness.

    However, even if you conduct regular one-on-ones, you can do it very poorly. For example, I've had managers who've spent most of my one-on-one time talking to or emailing other people, just talking the entire time without listening, and even zoning out (staring at the ceiling, a piece of furniture). Other faux-pas include glaring at the person (or eye-rolling, laughing at inappropriate times), only giving negative feedback, never offering assistance, and never asking for feedback.

  • I wanted more (or less or something different) for someone. I'm an overachiever and I've always had a vision for what I could and should be doing in any job. I know that not everyone is this way, yet somehow this fact escaped me early in my management career. Some of my earliest supervisees were just doing a job, with no vision for themselves in the future, so I adopted a style of pushing my own vision for a person's career. I could pat myself on the back for the times in which this worked out, but there were times where this approach certainly backfired -- such as the strong generalist who I thought should specialize in an area they didn't care for, or the developer who I saw moving up the tech ladder when they wanted to move into management. Having a dialog not just about about an individual's current role and goals but also about their future is crucial. I like to do this at least twice a year, now, to ensure that my direct reports and I are on the same page.
  • I hired someone despite having concerns about their ability to do the job. This is a tough one to address in generalities, but I'll try. Any hiring decision should be backed up with evidence gathered through a rigorous interview process. Every new hire presents some level of risk, but you want to have primarily positive feelings about a hiring decision, not concerns. I have, on occasion, made hiring decisions based less on evidence and more on what I thought could be possible, given training, coaching, and mentoring. Sometimes it has worked out wonderfully. Other times it's been a painful experience for both the individual who was hired and for me. I do believe in giving people a chance, though, so I can't totally knock taking these risks. These days I try to be open about expectations prior to hiring and I reinforce those expectations once the individual walks in the door in regular one-on-ones. I don't usually out-and-out express my concerns, though -- this can kill a person's confidence! But if I must, I'll also express my support for the person and assume responsibility for making sure the right things are in place for the person to be successful.
  • I let my own issues get in the way of my responsibilities. Anyone who's followed me on Twitter for the past year has seen this one first hand. I started a new job last January and spent almost the entire year unhappy with my role, the work, and number of other things. I focused on the frustration, vented publicly, and let public response further fuel my discontent. All of this distraction consumed me; meanwhile my team languished. I began planning an exit strategy and engaged an awesome career coach who ended up reminding me of my strengths and reignited my passion for creating positive change. I set to work on creating a plan to address not only what was making me unhappy but also what I felt was missing from making our organization a powerhouse. I'm now executing on that plan and seeing small successes, which I hope to grow into larger successes this year.

Do you recognize any of these epic fails, either personally or in a manager you've worked with? Does your organization have a strong culture of coaching and mentoring managers to prevent against these and other fails? Share your story below for others to learn from. I'll share my epic wins later!

Kimberly Blessing

Web Developer Job Interview Questions

1 min read

Every employer has a different recruiting and interviewing process, but at some point you're going to be asked technical questions. (Or, at least, one would hope that you'd be asked technical questions... if not, look out.)

If you've never interviewed for a web development job before, or if it's been a while, you might be wondering what to expect. Rather than list a whole slew of questions here, I'm going to give you access to a real screening questionnaire -- one that I've actually used as a hiring manager to help identify which applicants have a solid understanding of core web development knowledge. (Harder questions get asked over the phone, and the hardest ones in person.)

What are you waiting for? Check out the questions!

Interviewers and hiring managers, what other questions do you ask early-on in the recruiting process?