At last week’s Boston SPIN meeting (the hiring roundtable), a candidate said that he had trouble remembering which resume he’d sent to which company. The good news is that he’s customizing his cover letters and resumes. The bad news is he sounds disorganized when a hiring manager or (internal) recruiter calls for a phone screen.I […]
Meet Wendy, a new CTO. She was hired to make the company’s flagship product, BigProduct, releaseable more frequently. In fact, her predecessor was fired due to his “inability to release product quickly enough.” Wendy’s been able to deliver products in adverse circumstances, so she feels she’s ready for the challenge. Wendy meets with her senior
John Kador, who’s written a number of books about interviewing and a new one coming out, has an article about brainteaser and riddle interviews on Darwin. Kador gives pointers on how to answer the questions, and if you’re a candidate, you should read his suggestions. They will help you in the interview. I have a
Rick commented on my last post that some engineers think that status checking slows them down. Mark said that engineers push back on demos and pointless measurements and then said in another comment, “progress metrics can always be free.” Here’s how and what I look for, to determine status. If I’m managing a traditionally-planned
I was a reference for a senior manager yesterday. At first, the reference started to ask me, “What do you think are so-and-so’s weaknesses?” I hate that question, because it all depends on the context. And I’m smart enough to turn that question around so a weakness doesn’t sound like a weakness. Grr. But then,
At Boston SPIN last night, Tim Lister of “Waltzing with Bears” fame gave a talk about recognizing and managing risk. It was great. If you ever have a chance to see Tim speak in person, do so (Yes, Tom DeMarco is also an excellent speaker, but he wasn’t there last night :-). When I
In my last post, I argued that functional and non-functional requirements are unsuitable for the art of describing requirements. I prefer to discuss attributes of the system instead, and then talk about functionality. (Gause and Weinberg wrote Exploring Requirements, Quality Before Design describe how to do this.) But Laurent, in his Misfits, or there’s
David, a reader, recently asked for tips about reviewing resumes. Here they are: Read the resume from the top to the bottom. Don’t start somewhere else. Candidates try to grab you with the cover letter or resume. Let them. If there’s an objective, read it. But don’t believe it. Seriously, how many objectives say, “challenging
I read somewhere in the past week that candidates should be willing to work for a couple of weeks or up to a month as a contractor to show potential employers how great they are. (I thought this was in the Boston Globe, but I can no longer find the article, nor the pointer to
I’ve been thinking more about requirements. In the most recent two assessments I’ve done, both organizations have been stuck on thinking they could define their requirements before design and implementation. IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months)