Dynamic Drive has a great tool for converting images to "favicon" icon files that appear in the tab/address bar of browsers. Simply upload the desired image (such as a PNG with alpha channel), and you can see the results in a simulated address bar and download a Windows-compliant .ico file.  Nice!

You can find it here: http://tools.dynamicdrive.com/favicon/.

Here's a preview of the interface with an icon I've created for use with collabormate.com:

Here are a few simple CSS rules to "reset" various browsers' settings to a common baseline.  I've adapted this from what I spotted on Kyle Neath's blog here: http://warpspire.com/posts/css-frameworks/, who did a nice job at concise definitions (compared with what I've seen from the YUI toolkit and elsewhere).

* { padding:0; margin:0; }

h1, h2, h3, h4, h5, h6, p, pre, blockquote, label, ul, ol, dl, fieldset, address { margin:1em 0; }

li, dd { margin-left:5%; }

fieldset { padding: .5em; }

select option{ padding:0 5px; }

.hide { display:none; }

.left { float:left; }

.right { float:right; }

.clear { clear:both; height:1px; font-size:1px; line-height:1px; }

a img { border:none; }

My past colleagues and I have found that a 30 minute (or less!) phone screen is a great way to make the interview process more efficient.  While it cannot necessarily assess cultural fit, it can certainly weed out applicants who do not meet a minimum level of technical proficiency, saving everyone time.  From the candidate's perspective, a day is not lost in travel and in-person interviews.  From the firm's perspective, 3-6 people do not have to take time out of their day to quiz the person -- avoiding hours of lost productivity.

I've had to conduct plenty of phone screens over the last several years, and I've found the following practices most effective:

1. Follow a 5-20-5 rule -- that is, spend 5 minutes talking about the company and the job opportunity background, 20 minutes asking questions, and 5 minutes answering the candidate's questions.  That first 5 minutes is a nice way to relax the candidate and get him or her excited about the job.  Part of the process is "selling" the candidate on the job, of course!
   
   
2. Do not exceed 30 minutes.  In other words, stick to that 5-20-5 rule.  Yes, this is redundant, but it's important!  The phone screen exists to make the process more efficient, not less; so if you're spending more than 30 minutes, you need to speak more concisely and choose your questions more carefully.
   
   
3. Be prepared to pass.  If you are indecisive and would feel uncomfortable with terminating a candidacy unilaterally, you should not be conducting phone screens; instead, ask a coworker to do it or have a coworker on the call with you to "train" you.  By the end of the 30 minutes, you should have a clear idea in your head about whether or not to proceed.
   
   
4. Standardize the questions.  This is especially important for cases where several people on a team may be dividing phone screen responsibilities.  To ensure the bar is set consistently, come up with a stock of questions to ask during the phone screen -- and organize them by level of difficulty.  The questions should be specific to the job, of course.  This doesn't mean you have to ask all the questions or cannot deviate from the questions during the call, but for an appropriate baseline at least some of the standardized questions should be asked.
   
   
5. Test the questions.  Ask coworkers holding the targeted job -- or a similar one -- the questions.  You may be surprised to learn that the questions are too hard, or better left to an on-site setting with a whiteboard nearby.  Vetting the questions before a phone screen will give you confidence.  If the candidate falters, you'll know whether it's because the question is difficult or because the candidate is lacking a critical skill.
   
   
6. Go in prepared -- know the candidate.  Take the time to look over the candidate's resume (and portfolio, if applicable) before the interview.  A quick Google or social network search may add some color.  Use this prep to focus the discussion.  Make sure you ask the subset of standardized questions that will verify some of the claims on the resume.
   
   
7. Start with a simple question.  This is not just to put the candidate at ease, it's also to cut through any B.S.  Sometimes difficult questions can be easy to answer, especially if a candidate is a smooth talker.  A simple question has a nice advantage:  it demands a simple answer.  For example, when hiring for a web UI developer role, here's a simple question:  "Which HTML tag would you use to represent a button?"  Someone applying for this position would certainly need to know meatier things, like design patterns and programming language constructs.  But start with the simple.  In this example, valid answers would include "BUTTON," "INPUT" with a type attribute of "submit" or "button" or "image", or even "A" if styled properly.  If a candidate says, "Well, I don't know.  I leave that to the designers," then you may not need to ask any more questions!
    
   
8. Write down your thoughts during (or immediately after) the call.  The paper trail is important so you can communicate the results with others, especially the recruiter/HR rep suggesting candidates.  The feedback will (ideally) help them improve the candidate pool over time.  Don't wait until later when your memory of the conversation will not be as vivid. Come up with a standard form that you and others can use to quickly record your thoughts on areas such as technical competence (score of 1-5, with optional comments), communication skils (1-5), engagement (1-5), and perhaps experience (1-5).
   
   
9. Do not end on a negative note.  If you are excited about the candidate and would like them to move forward in the process, feel free to say so.  But do not do the opposite when you are not excited about them.  Leave that task to the recruiter/HR -- it's their job.  Otherwise you may find yourself spending extra time trying to justify your decision to the candidate.  Instead, end with a thank you and indicate the recruiter/HR will follow up with them on next steps shortly.
   
   
10. Never share your interview questions with recruiters/HR sourcing the position.  While often well-intentioned, I've found recruiters tend to tip off the candidates if given the chance.  Their incentives, after all, are based on these people getting hired!  This also means keeping the feedback generic.  Do not tell a recruitier that a candidate couldn't name an HTML tag to represent a button, for example; just indicate that the candidate did not meet the minimum level of technical proficiency.  The corallary here is:  don't let recuiters/HR listen in on the call.

While I think the intent of the phone screen is to assess technical competence, sometimes you can glean some insight into professionalism or cultural fit.  Some examples:

1. Engagement and the drive-by interviewee:  If the candidate is talking to you while driving, the message here is that they are not seriously interested in the job. 
    
   
2. Professionalism and the tardy interviewee:  If the candidate is more than a couple minutes late dialing in to the conference call number, or doesn't pick up when you call him/her, it demonstrates a lack of professionalism -- especially if the candidate does not apologize.
3. Ethics and the Googling interviewee:  If the candidate is dumbfounded by a question, only to miraculously arrive at the right answer a minute (or 20) later, question whether this candidate can be trusted to stay on  moral high ground.

The phone screen may be stressful for the candidate, so try to keep it casual and not be too serious.  Have fun!

(Photo credit: graphiteBP)

Sphinx-4 is a speech recognizer developed at Carnegie Mellon University.  Out of the box, it offers two modes of operation: batch ("frontend") and continuous ("epFrontEnd").  In contiuous mode, it performs decoding live based on, say, microphone input.

Unfortunately for me, epFrontEnd turns the Recognizer.recognize() method into a blocking call, and Sphinx-4's API provides no way of interrupting this method. I find this problematic in various scenarios, such as automated tests.  In such a test, I want to determine whether the recognizer recognizes the command correctly, incorrectly, or misses it entirely.  The "miss" case is the tricky one, as in this case the recognize() method just hangs indefinitely, waiting for more audio input.  

I found a way to work around this problem.  It involves inserting a custom data processor into Sphinx-4's data processing stack.

Here's how to do it in three steps:

Step 1:  Implement a custom data processor 

Step 2:  Add this data processor to the processing stack

In the Sphinx-4 XML configuration file, place the processor right after the microphone processor in the stack.  

    <component name="epFrontEnd" type="edu.cmu.sphinx.frontend.FrontEnd">
        <propertylist name="pipeline">
            <item>microphone </item>
            <item>insertableDataBlocker </item> 
            <item>dataBlocker </item>
            <item>speechClassifier </item>
            <item>speechMarker </item>
            <item>nonSpeechDataFilter </item>
            <item>preemphasizer </item>
            <item>windower </item>
            <item>fft </item>
            <item>melFilterBank </item>
            <item>dct </item>
            <item>liveCMN </item>
            <item>featureExtraction </item>
        </propertylist>
    </component>  

Step 3:  Interrupt the recognize() method when desired