CSG's Top Five Interview Prep Tips

When getting yourself ready for an interview, whether it be a phone interview or an in-house interview, you need to make sure you are 100% prepared. Dot all the t's and cross all the i's. Er, wait, dot all the i's and cross all the t's. Anyway, preparation is key. You can't really be over prepared for an interview.

We have talked about interview preparation in previous blog posts so make sure you don't miss those, but anyway, here are Core Search Group's Top Five Interview tips. This information is directed at software engineers. However, it can be used by one and all:

1 - Be able to defend your resume like it is a Ph.D. thesis. Anything and everything on your resume is fair game. Many people crash and burn during the interview because they cant go into details about their projects. Make sure you can.

2 - Know how to say: "I don't know". You have to make some attempt at an answer. It is a number 1 pet peeve of hiring managers to hear a candidate say "I don't know" and be done with their answer. Make an assumption based on a similar tool you have used if they ask you about a tool you have never used. Then asked the interviewer if that was a safe assumption.

3 - This goes hand-in-hand with #2. Know how to get the interviewers help if necessary. Be able to ask the right return questions to get the interviewer to push you in the right direction. Part of the interview is knowing how to get help; collaborating with the interviewer to get to the right answer is key.

4 - Be able to start a dialogue with the interviewer. I have heard hiring managers say that they have a stock list of questions, but that if they ever get through that entire list, they know they don't want to hire that person. They want to be engaged and interested in conversation. They want to be taken out of the common question-answer, question-answer routine. That can be boring. Remember you are trying to make yourself come across as interesting to the person interviewing you. You are trying to make yourself standout from the pack. You have to make it so the interviewer leaves the interview setting remembering you more than other candidates.

5 - This goes hand-in-hand with #4. Have a list of solid questions to ask. If you are given the chance to ask questions and you don't, then you will sound disinterested. A great way to lose interest from the person interviewing you is to come across as disinterested in the position.

So next time you get that interview lined up. Get yourself PREPARED!!!

Look out for the next post about getting tons of interview advice online.

Peace out!

Gil

Work with World C++ Leaders in an Amazing Location: Lake Tahoe!

We have a job opening for a C++ expert in Lake Tahoe. We think it is so cool that we should blog about it. Why should you be reading this? Well if you are extremely passionate about C++, STL, Boost and a you love to not only develop software for a living but love working on open source or other side projects, then you should definitely fit this team. This company’s office is literally 5 minutes from one of the country’s most amazing ski resorts, Heavenly. Did I mention that this company will pay for half of your season pass to Heavenly? If you want to also go to some of the other amazing ski mountains in the area, I am sure those mountains sell season passes also.

If you don't ski or snowboard, there is a ton of other outdoor activities to do in and around Lake Tahoe. Here is a list.

Do you like to visit San Francisco but don’t want to live there? You can get to San Francisco in 3 hours from Lake Tahoe. The best of both worlds, right? Rock on!

So you are now saying, “well, I am not a C++ expert”. That is OK. What is your definition of ‘expert’? Everyone’s definition is different. Do you have extreme passion for C++? Do you love dissecting the advanced features of the language? Maybe you are a hardcore Boost developer. If you are in there somewhere and feel that you are at least on your way to becoming a C++ expert, then we at least have a conversation starter. Let’s talk. If you are a rising rock star who better to learn the rest of your C++ alongside than a few C++ Standards Committee members.

Do you love working in an atmosphere where entrepreneurship and creativity are encouraged? Do you love being able to work on open source and side projects and have strong people near you to discuss such matters? These aren’t the only things discussed around the water cooler.

Are you concerned about COL? Yes, it can be expensive in Lake Tahoe. But you won’t care. Our client makes sure you will be compensated in a way that will allow you to have a comfortable living in and around Tahoe.

Contact us for more information.

How to run an efficient and effective interview process.

We have several world class clients in the software industry and have worked with several other world-class firms over the years. We have worked with companies that run a very efficient and effective interview process and some that lose out on a lot of good people because they do not. What are the reasons a company should strive to run an efficient and effective process?

There are many:

- First is the most obvious. It saves the company time and money.

- It optimizes the chances that candidates will spread positive feedback about your company and your openings, whether they get hired or not.

- If you are working efficiently in your interview process, your recruiters are much more likely to respond and do the same and hence bring you more great candidates.

- Efficiency in one activity breeds efficiency in other activities.


Let's take a look at how to get the most out of your interview process.

- 1st, it is VERY important to give timely feedback to your recruiters or to direct candidates. You as a hiring manager must assume that each and every candidate is working on at least 2 or 3 opportunities other than yours. This makes timely feedback imporant in keeping the interest level high in both your candidates and the recruiters that are working with you. If they have to wait too long for feedback or to hear about the next step in the process, they are more likely to lose interest and focus on other opportunities more than yours. So quickly give feedback from the previous step in the process and quickly move to the next step. Technical people are very sensitive to process. If your recruiting process is opaque, slow, and unfocused, they very quickly assume the rest of your company works the same way.

- 2nd, know the timeframe importance level for each candidate. You may find the need to speed things up with certain candidates if they are getting close to the offer stage with other companies. This is especially important if this is a "rock star" candidate.

- 3rd, Make efficient use of everyone's time. Double up on phone interviews. If you know you need 2 phone interviews before you can bring a candidate onsite get 2 software engineers on the phone with a candidate at a time. Kill two birds with one stone. This can not only save man hours and money, but it speeds up the entire process which, again, is very important for candidates that are getting close to receiving offers from other companies.

- 4th, If you are scheduling a candidate for an onsite interview and you are flying them several thousand miles to bring them in to your office, make sure you optimize the use or your company's time and money. Make sure you have the entire thing scheduled hour by hour. Don't have the candidate sitting around waiting a long time before meeting with the next person. By leaving them alone in a conference room they will lose interest, confidence and hence your process loses effectiveness. If they will need to do a second day of onsite interviews, try to have that scheduled into the candidate's travel arrangements and schedule if possible. If you have to bring them back for a 2nd round make sure you aren't going to lose their interest and candidacy in doing so.

- 5th, Have a pragmatic approach to your interview. Tech trivia has its place in the software engineering interview, but should not be the end-all be-all. Make sure you are drilling down core computer science fundementals. If there is a famous problem that the founding members of your company had to solve once upon a time, ask the candidates how they might approach the problem. Also, in writing software you try not to "reinvent the wheel." Use the same approach in interviewing. Get them to go through some of their projects step-by-step. Get them to talk about architecture, show you the design and maybe some code of some of the implementation. Keep them on their toes.

One last thing. By keeping your interview process efficient and effective you will help your retention rate. Many people dread conducting interviews. By keeping your interviewers on their toes you will keep them excited and interested in their own job. Everyone wins! The next time you are in a position of hiring keep in mind how it directly and indirectly effects the rest of your organization.

Why Twitter?

Gil says-

One of the outstanding developers I have worked with in the past few weeks asked me about the advantages or benefits of using Twitter. He asked me this in response to my invitation to follow me on Twitter. That wasn't the first time someone had asked me a similar question and it wasn't and won't be the last. Now I will have a place to refer those questions.

I have seen Twitter in the news (mostly CNN) since the Saffron Revolution in Burma in 2007. Since that event I have seen Rick Sanchez and others on CNN use Twitter and I never paid attention much to those bits because I didn't really understand the technology..... So I always wondered what it was really used for? What was the craze? What were people doing on Twitter. Why was the application itself so special? This was when we at CSG decided to check it out.  There are many good primers on how and why to use twitter.  We've found it to be very useful in recruiting.  

Dave says:

I'm highly skeptical whenever I see hordes of people moving in a given direction. I'm not one of the people riding the bandwagon.  I'm the wolf loping alongside the bandwagon waiting to see what cliff it is going to go over.  However we have found tweeting brings a ton of benefit.  

Interacting on twitter is like moving through the biggest bar in the world.  You'll need to wade through a lot of people that don't offer much value to your line of business.  It's a constant stream of conversation of which maybe 1% at any given time is applicable to your business.  But that 1% is VERY interesting.  You walk past the dude with the bone in his nose to talk to the cerebral looking guy in the corner who is a software thought leader.  Many people link to their blog, website, or resume which is where you decide if they are who you are looking for.  We use Tweetdeck to manage twitter.  I run search strings relevant to searches I am running.  For example I'm working a search for C# talent in NYC.  Any tweet that mentions idisposable comes to me.  Odds are very strong that this person is going to be a potential candidate for my search.  I get a quick surface view of a person which helps me decide if I want to learn more about them.  Many people offer a link to their blog or website which is usually more than enough information for me to make a decision-do I want to talk with this person?

Since the whole point of twitter is the conversation we're able to post searches we're working on for folks to look at with less of a resistance level than more traditional forms of sourcing.  If you're one of the most highly sophisticated software engineers on the planet you're a lot more likely to respond positively to real information than some cold call at your work phone. 

Core Search Group, over and out. 

An interview is a blind date. Don't screw it up.

At left is Core Search Group's recommended interview attire.

Over 9 years of watching interviews go on patterns begin to emerge. Here is what we have learned. An interview is not an interview. It’s a blind date. If more people knew how to get through a blind date I would be fabulously wealthy and you’d have to figure all this out on your own.

Have you ever had a friend try to hook you up with a potential significant other? It can be really embarrassing for everyone involved. As third party recruiters we try our best to judge not just the technical match of the candidate and company, but also how the personalities will mesh. Sometimes we get it wrong. In one recent instance we had a management candidate tell the developers how she would “manipulate” them into getting the work done. Surpise, they didn't like that idea. She didn’t get hired. Sometimes we get it right. Among other fascinating interviews I have witnessed we had one guy show up for the interview in a giant squid costume. He got the job-programming for one of the top financial companies in NYC. It was the right audience. Since our recruiter knew the audience he knew they would react well. On a blind date you chat with someone for a few minutes and mutually decide, yes or no, “I think I might be able to spend a lot of time with this person without barfing.” On an interview you’re deciding, “I can deal with the cubes and fluorescent lighting and total lack of source control if I can work with these people.” So the key is not to act like a gold-chain wearing goon or a prima donna or any of the other limitless types of pains in the ass people can be. Go in with the idea that you’re a consultant there to figure out how you can help them succeed. Go on a blind date with the idea that you want to learn about the person you’re meeting, not prattle on about how freaking cool you are.

The best blind dates are set up by someone who knows you really well and cares for you. So consider that individual before you accept. They may know your history and how you seem to prefer freakishly intelligent and productive people. Or they may have a friend whose life is a shambles who they are hoping you can lift up from the pit of despair and anguish. Which date do you want to go on?

Most candidates I talk to have no idea how to qualify recruiters. They let any tool with a monster account and some blind ambition fling their resume haphazardly at a company and cross their fingers. This leads to some brilliant flameouts. If I had a nickel for every sob story I’ve heard I wouldn’t be asking you for your resume.

Here’s CSG’s simple checklist to qualifying recruiters:

1. How long have they worked with the company they want to send you in to? How many people have they placed there? If the answer is “Ummmm…” let them waste some other sucker’s time.
2. What are they going to do to HELP you get the job? Do they know more about the group and the requirements than is on the woefully vague “job description” they got from HR?
3. Have they met the people you’ll be interviewing with? Can they tell you why they think you'll mesh with these people?


Don’t go on blind dates set up by people you don’t know. Don’t go on interviews unless the recruiter can convince you it is an excellent investment of your time. Don’t forget to wear clean underwear when you leave the house.

Anatomy of a hiring decision

Our clients are looking for the top developers in the country. They look at their code and look for the best usage possible. Here's an unmodified example from a hiring team at one of our clients.

"Code Critique

In the following, I will go through the code and point out some thoughts along the way. Some of them are merely stylistic, but others can be considered bugs. The list of comments shouldn’t be considered exhaustive.

class SelectionStateController
{
protected:
typedef std::map States; // a collection pairs: a unique string of a manager's id and
// a boolean selection state (true if selected)
typedef States::const_iterator CIt;
typedef States::iterator It;
// the function object to set up the list of displayed managers
struct Value
{
States::value_type operator()(const std::string &id) { return States::value_type(id,false); }
};
protected:
Container &clients; // a collection of clients to notify about selection state changes

Holding the client list as a reference can be a problematic choice. It makes it impossible for the controller to enforce invariants on the client list and to control list management. Admittedly, neither of those requirements were specified in the problem that was presented.


// returns the selection state of the manager 'id', true if selected
CIt cit=states.find(id);
#ifdef _DEBUG
check(cit,id);
#endif

C++ has a shortcut for this: assert(check(cit, id)). Spelling it out just adds visual clutter.

return cit->second;
}
// setters
void set_state(const std::string &id, bool new_state)
{
// sets the selection state of the manager 'id', notifies clients if the selection state is changed
It it=states.find(id);
#ifdef _DEBUG
check(it,id);
#endif
bool &state=it->second;
if (state!=new_state)
{
// update state and notify clients about the selection state change
state=new_state;
for (Container::iterator cont_it=clients.begin(); cont_it!=clients.end(); ++cont_it)

Standard C++ requires the keyword typename in front of Container::iterator as Container is a dependent type. MSVC doesn’t catch/enforce this – yet.


{
SelectionStateChangedFunc selection_state_changed(*cont_it);
selection_state_changed(id,new_state);
}
}
}
template
void set_displayed_managers(InIt first, InIt last)
{
// sets the list displayed managers in a range from the 'first' to the 'last'
// note: this method should be redesigned if selection states must be preserved upon changing the list of managers
states.clear();
std::transform(first,last,std::inserter(states,states.begin()),Value());
}
protected:
void check(CIt cit, const std::string &id) const throw(std::logic_error)
{
// checks if the manager 'id', which is pointed by the iterator 'cit', exists in the list of displayed managers
// throws the exception std::logic_error if it does not exist
if (cit==states.end())
throw std::logic_error("Manager "+id+" does not exist");
}

If I understand correctly, check is used as a way to check preconditions on function arguments. Essentially, it is an assertion; as such, it should never throw an exception. Assertions are debugging tools. Throwing an exception will unwind the stack, thus destroying valuable state information when debugging the issue.

};


class Client
{
public:
// function object that is invoked to notify about changing a manager's selection state
struct SelectionStateChanged
{
Client &client;
SelectionStateChanged(Client &client) : client(client) { }

Single argument constructors should be explicit unless an implicit conversion is really needed. In this case, the implicit conversion hides a subtle bug in the code (discussed below).

void operator()(const std::string &id, bool new_state)
{
std::cout
<< "Client " << client.id
<< " was notifyed about changing selection state, manager=" << id
<< ", new state=" << new_state << std::endl;
}
};
private:
friend struct SelectionStateChanged;
const int id;

Having id be a const member makes Client non-assignable, as assignment would require changing id in the assigned-to object. All standard containers required their value_type to be assignable.

public:
// constructor
Client(int id) : id(id) { }
// type conversion operator that constructs a notification funcation object
operator SelectionStateChanged() const { return SelectionStateChanged(*this); }

Implicit conversions are frowned upon in C++, as they almost invariably lead to problems in all but simple code bases. In this case, the conversion operator is never called as SelectionStateChanged’s conversion constructor is preferred over this function. If it were to be called, the program would crash after running out of stack space because it is recursive. Since the conversion operator is a const member function, *this is a const lvalue. It thus cannot be used as the argument to SelectionStateChanged’s conversion constructor that was defined requiring a non-const lvalue. What gets called is SelectionStateChanged’s implicitly defined copy constructor after calling Client::operator SelectionStateChanged() const on *this. This recursion leads to the crash.

};

int main()
{
// define a collection of clients
typedef std::list Clients;

Client is not assignable so this is not guaranteed to compile on a standard compliant std library. It will fail in future concepts-enabled code.

Clients clients;
std::back_inserter(clients)=Client(1);
std::back_inserter(clients)=Client(2);

The use of std::back_inserter here is odd. I can’t come up with a reason why std::list::push_back is not the better solution. Apart from that, it’s not std compliant. The standard requires output iterators to be dereferenced upon assignment. The fact that it works is an implementation artifact of the std library used."

The power and value of serious software development search.

Here's a software development success story Core Search Group is immensely proud of.

Automated Trading Desk has entered into an agreement with Citi to be acquired for $680 million. While most people in SC still don't even know who this company is or what they do ATD is one of the biggest business success stories in the history of our state. ATD helped us become who we are in a big way and we think we had a hand in helping them get where they are.

In 2001 I had the incredible business foresight to purchase this company from the previous owners at precisely the same moment that the internet bubble imploded. I had worked for the firm for two years as a recruiter placing software developers, networking people, and anything else related to IT. We were a generalist IT staffing company and unfortunately so was everyone else. When the bubble burst every company we worked for suddenly was not hiring. We had no jobs to work on. A lot of recruiters were suddenly on the street with an old guitar and a tin cup and a surprised expression. So there I was at my desk, the only employee of the company, having taken on some debt, with no jobs to recruit for. I figured I better find a specialized niche where people were still hiring, pronto.

To make a long story short I became aware of this little and extremely impressive company on the coast of SC that was hiring software engineers. I began a dialogue with ATD but they were quick to point out what they were looking for was very difficult to find. At this point the degree of difficulty wasn't a big obstacle for me. I had to succeed. ATD hires very proficient software engineers. People who are exceptionally skilled and productive at what they do. People with a history of innovation that is driven by their passion for developing quality software that suits a given need. So I decided to become a specialist in finding those kinds of developers.

I met with the people driving the software development at ATD and interviewed them to find out what they were doing, why they needed this exceptional level of talent, and how I might be able to help. Around this time I hired Mr. Vander Voort who helped hone our approach to finding the people. We learned about ACE and TAO and a bunch of other new (to us) things. ATD was our first client that is the absolute leader in their software development space. We now hold to working only with companies that fit that criteria. It's a short list.

Over the following years we've placed around 10 highly capable folks with ATD, which is approximately 15% of their total development team. Most of those folks are still there because ATD is careful to give them a beautiful environment to work in, their own office, the best tools, and the best colleagues. The pay is also great and it's hard to complain about living in a place like Charleston, SC. Like us they are a small but entirely focused and driven company which has allowed them to grow to the point that 6% of all stock trades on the Nasdaq and NYSE are executed through ATD's systems.

ATD taught us to specialize in what matters to the top software development company in a given market. Not collecting and delivering resumes. Researching specialized areas of software development, approaching the leaders in that space, developing quality win-win relationships, and carefully finding the few people who really meet the bar the company has set AND are looking for the type of relationship, responsibilities, location, and compensation the company can offer.

Everytime we place someone we feel a surge of pride because we know when we follow our system the folks we place will have a huge impact on the client. We're immensely proud of our part in the success of ATD and hope to help them get to the next chapter of their story. We don't place people to get fees. We place people to grow companies, deepen our relationship, and broaden our responsiblity for their success.

Congratulations ATD, and thanks for helping Core Search Group become who we are. Forward!