Job interviewing is one of the most important parts a manager’s or team lead’s job, but too often managers go into the process without a clear vision of what they're looking for, and therefore they don't know what to ask about.

Job interviews can be rough under the best of circumstances. They're not helped any when bad interviewers ask questions that take away from the real point of the interview, which is to assess your skills and how well you fit with the rest of the team. The categories that follow are some of the most commonly asked bad interview questions, which might help to prepare you, so you're not caught off guard.

Most open source developers like to think about the quality of the software they build, but the quality of the documentation is often forgotten. Nobody talks about how great a project’s docs are, and yet documentation has a direct impact on your project’s success. Without good documentation, people either do not use your project, or they do not enjoy using it. Happy users are the ones who spread the news about your project – which they do only after they understand how it works, which they learn from the software’s documentation.

It always happens. Our websites get to be too slow. We keep adding features and graphics, and JavaScript doodads on our sites, and the website performance slows to a crawl. That’s an embarrassment for any web developer, especially one that is proud of creating responsive sites. Before you can speed up the website, you have to figure out exactly what’s causing the bottleneck.

Working in open source brings many kinds of rewards. Open source participation helps get the software created that you need, and it brings a sense of accomplishment to help others with the work you do. If you’ve been involved in an open source community, you probably also have discovered that it’s a way to gain new technical skills.

In which a Web developer and graphic designer do their best to achieve world peace.

As long as there have been visual programs, programmers and designers have butted heads. The differences between the two sides of program development seem to often be at odds, even though we all know both team members are important to creating effective applications. Designers fume at seeing their designs implemented different from how they were originally laid out. Programmers gripe that designers nitpick over silly design issues.

Many conflicts are based on a lack of understanding of the other party, and we felt that this was the case with the designer/programmer schism. In the name of peace between the right- and left-brained, we (a programmer and a designer) present this list of lessons.

• "I'm not a very good programmer."
• "I don't have much time to put into it."
• "I don't know what project to work on.”

There are three core principles to remember as you look for opportunities to contribute:

• Projects need contributions from everyone of all skills and levels of expertise.
• The smallest of contributions is still more than none.
• The best project to start working on is one that you use already.

Start listening

Work with tickets

Code is the heart of any open source project, but don't think that writing code is the only way to contribute. Maintenance of code and the systems surrounding the code often are neglected in the rush to create new features and to fix bugs. Look to these areas as an easy way to get your foot into a project.

Most projects have a publicly visible trouble ticket system, linked from the front page of the project's website and included in the documentation. It's the primary conduit of communication between the users and the developers. Keeping it current is a great way to help the project. You may need to get special permissions in the ticketing system, which most project leaders will be glad to give you when you say you want to help clean up the tickets.

Diagnose a bug: Bugs are often poorly reported. Diagnosing and triaging a bug can help save the developers save time with the legwork of figuring out the specifics of the problem. If a user reported, "The software doesn't work when I do X," spend some time to figure out the specifics of what goes into that problem. Is it repeatable? Can you create a set of steps to cause the problem repeatedly? Can you narrow down the problem, such as only happening on one browser but not another, or one distro but not another?

Even if you don't know what causes the problem, the effort you put into narrowing down the circumstances makes it easier for someone else to fix it. Whatever you discover, add it to the ticket in the bug system for all to see.

Close fixed bugs: Often bugs are fixed in the codebase but tickets reported about them don’t get updated in the ticketing system. Cleaning up this cruft can be time-consuming, but it's valuable to the whole project.

Start by querying the ticket system for tickets older than a year and see if the bug still exists. Check the project's release change log to see if the bug was fixed and can be closed. If it's known to be fixed, note the version number in the ticket and close it.

Try to recreate the bug with the latest version of the software. If it can't be recreated with the latest version, note that in the ticket and close it. If it still exists, note that in the ticket as well and leave it open.

If you speak at any programming conference, from a BarCamp to a huge, well-orchestrated conference like OSCON, you have only a short time to do a data transfer from your brain to the attendees. Use it wisely.