Category Archives: Philosophy

My own thoughts on how a project should be run.

Interviewing and Being Interviewed

For the past 2 months, I have been interviewing candidates for 3 different positions: Business Analyst, Test Engineer, and Software Developer. The candidates that I interview are first vetted by headhunters, then their resumes are reviewed by me for specific job skills. If they pass those two checks, I act as gatekeeper and perform an initial interview to determine whether they will be considered for the job. This process means I’m not interviewing the candidates who have no matching skills.  But there is still a great difference between the candidates.

My questions tend to focus on 3 areas for each interview: what experience can you show me that matches the qualifications I’m trying to meet, how do you handle difficult and/or complex situations on the job and what job specific knowledge do you possess.

Headhunters have seen the same job listing that I’m working from when I interview a candidate. So I’m always surprised when that candidate has no experience in one of those job areas. Mind you, I will hopefully catch that when I review the resume, if the headhunter hasn’t. But I will sometimes give the candidate the benefit of the doubt if I see similar items listed on their resume. But, if I then talk to the candidate and they have no experience in that area, I see this as a waste of time, both for me and for the candidate, since they are not someone I can consider hiring.

The knowledge I’m looking for is more the book learning – type of information; the type of things you learn in school and let you communicate with like-minded professionals. We all hate the tech-speak of others. But we have all learned that the tech-speak helps us communicate effectively with like-minded individuals. If you don’t know what a tool is that is common to your profession, or you don’t understand a term I use that is in wide application within your profession, I will not look favorably upon your candidacy.

I do have a pet peeve for this one. I am a technical person. I am frustrated when the person I’m interviewing talks to me as if I do not have that background, but rather as they would talk to an ‘outsider’, someone with no technical skills. Sometimes I thinks it’s because they don’t understand the concept well enough to explain it. Sometimes I think it’s because they’re not used to ‘talking tech’. Frankly, they need to get over that.

Lastly, I will as ‘what if’ type scenarios. If the person has experience with those, I want to hear how they were handled. If they don’t, I want to hear the logical thought process they would go through to come up with a solution.  If they have been through the given scenario before, I will often try to come up with others so I can see how they’ll handle a ‘new’ situation. If they have been through the situation before, I want details. This is their place to shine because they are showing how they overcame a difficult situation. I was using checkmarks for the job skills. I will be looking for how much you understand a situation and can relay the solution for this question.

Many times, an answer may be good for several questions. For example, a ‘what if’ may also help me see that the person has the technical vocabulary I’m looking for, or that they have had the experience that the job requirements asks for. Hopefully I won’t then ask a question that requires a person to repeat themselves.

It’s interesting that I have seen, after many, many interviews, that there are certain personality types that make a good interviewee for each position. For the analyst, I want a people person, for the tester, I want a very detailed person and for the developer, I want someone who can get ‘into the weeds’ when it comes to technical matters.

The analyst needs to have both technical knowledge and people skills. They are primarily involved in helping to articulate the requirements from the stakeholders and convert those into a technical solution. For this, they need to be able to talk to people. The candidate that I find that does best then is the one that I can hold a conversation with. They will easily elaborate on any answer. They will be perceptive enough to see the point of my question and be sure to hit that point with their answer. They will understand the ‘big picture’ and their questions to me at the end will show that.

The tester better be detail oriented. Their job is to find problems with a project before the stakeholder, or the end user, does. If something slips through, they are often the ones that are blamed. When I talk to this person, I expect steps 1 to 3 of their explanation will have several subparts. I will not need to ask them to elaborate because they have probably given me more information that I expected.

The developer may be the person with less people skills than the others. Often they are the person who I need to ask many follow up questions to get answers. But, when I ask those follow-up questions, it is often of a technical nature and I expect a technical response. I want you to explain to me how your thought processes worked. I want you to help me understand where the difficulty lay and how you resolved it. I want to know that you can do better than the monkey in front of the keyboard writing Shakespeare. I want you to show me you understand why a certain technology you use is the better choice for the problem given.

Many of the candidates I interview do not speak English as their first language. Practically speaking, that means I’m dealing with an accent. For this reason, I try to conduct video interviews whenever possible. That way, I can read lips to help me understand what they are saying. Video interviews also help me see the person’s body language as they speak. Are they confident? Are they struggling to answer my questions? Are they expressing a passion for their chosen profession?

The down side of any remote interview – video or voice only – is the person with the lousy connection or the poor equipment. Please people! This is a technical job that I’m interviewing you for. If you can’t figure out how to connect, or how to be heard, I will think less of your problem solving abilities. The current positions are remote, which means you’ll spend a lot of time in video or voice conferences. The others on the call with you will not put up with this nonsense!

The best interviews? When I interview someone with ‘that spark’. They are passionate about what they do. They are perceptive in their answers. They are engaging.

The frustrating interviews? When I interview a great person, who is not great for the position for which I’m seeking candidates. I wish I could put you in my pocket to pull out at a later date. But I know that you’re good enough that you’ll have had several great offers before I can talk with you again.


Google+ Evolves in Real Time?

I just had the strangest experience….

I help with the social media campaign for a group to which I belong. I just got a list of all the email addresses of our members so that I could invite them to join our Facebook and/or Google+ group. I started with the Google+ group, figuring the invitee list would be smaller: I’d start by just inviting the folks with gmail accounts. Since there are 900 members, that was a way to thin down my task a bit.

So, I turned on a movie and started inviting people to the list.

At the top of the list, each time I tried adding the email address of someone who wasn’t a member of Google+, I saw a pop-up message stating that I could only invite members of Google+ to join the group.

But, about 20 or 30 names into this, all of the sudden, the system started accepting all of the names. Was I getting lucky? Were all these people members of Google+? I don’t think so. Because initially, when I’d add a name that would be accepted, that nice little blue box would pop into the spot where I’d put the email address, and it would show the person’s name with their email address. Now, if there was no name, the blue box was just showing the person’s email address.

So I tried an experiment. I started throwing in some of the non-gmail addresses. Now I know that you don’t have to be a gmail address holder to be a member of Google+, but the chances are more likely. And it could be that the stars were aligned correctly and the non-gmail addresses I picked at random just happened to belong to Google+ members. But I doubt it. Hm…. but maybe….. I should buy a lottery ticket tonight?? 🙂

So what happened? Did some algorithm change in the middle of my process? Was there someone actually watching what I was doing and change the behavior of the application as I was using it. I think the former is much more likely than the latter.

But how do I research this? What sorts of terms would I put in the search bar?

One wonders……

On Time Projects

I find myself oftentimes trying to get developers to understand why it’s important to give a client a realistic date upon which to expect a release. I have heard the words that make me cringe: “But it will be ready when it’s ready. This is new stuff and we can’t predict what might happen along the way.” Try telling that to your client for whom your software is a necessary piece for their own software.

I think I’ve finally figured out a way to explain it……

I think every area of the country has the ‘backyard’ auto mechanic. The guy with several cars sitting around that haven’t been repaired since before you were born. But often those folks know more about cars than you can shake a stick at. In my area of the country, we have some of those that are actual businesses. And a few have been recommended to me as the best place to take my not-so-new cars.

When you take your car to a mechanic, it doesn’t halt your need for a vehicle. Especially in areas with poor public transportation. That means either having to rely on someone else to drive you places, or drive with you places, or it means renting a car.

Now the dilemma with the ‘backyard’ mechanic. They may be good. They may be less expensive than the other guy. But many times you don’t know when your car will be finished.

So you take the car in for what you hope is a straightforward repair. You ask the mechanic when it’ll be done and you get a general handwaving. So you make arrangements to hitch a ride, or, worse, you rent a car, to tide you over until your car is ready.

A week passes. Your car isn’t ready yet. Your told the parts have finally arrived, and you’ve moved up the priority list, so they should be working on your car again soon.

Another week passes. Your car isn’t ready yet. Something else came it that was more important than getting your car done.

Another week passes. You finally get your car back. Mind you, when you get it, it runs better than when you left it, because they’ve tweaked a few other things that had been annoying you that you hadn’t even mentioned.

But the fact remains that you were 3 weeks without your car, you were inconvenienced much longer than you expected to be, and you may, if you did end up renting a car, be out more than if you’d taken it to the ‘other guy’.

Now think about a software project. The developers tell you that, with design, development, code review, and testing, the project will take 8 weeks. 6 weeks rolls around and the coding isn’t done. They say it’ll be at least another week added on. 8 weeks passes and the coding is finally done and reviewed. But it’s not tested yet. Add another two weeks. 11 weeks passes. The software is finally delivered. It works great. But in the meantime, you’ve had your team sitting on their thumbs waiting for that functionality so they could get their part done. And your clients, to whom you’ve promised an end product, will now have to be told that it needs to come a month later. So your clients go somewhere else.

Kinda makes sense, huh?