12 Tips To Interviewing For Identifying Good Talent

Photo by Steve Halama on Unsplash

Interviewing is a job that requires preparation and coordination among various stakeholders. Unfortunately, though in many places that I have been to as part of my Consulting gigs, I have witnessed first-hand on the very many things that go wrong in the preparation and conduct of interviews. In this post, we shall focus on the things to do before, during and after the conduct of an interview to aid better decision making in identifying talent.

1. Prepare. Know what you want. Do know the expectations of the role you are hiring for.
2. Prepare Again. A candidate's CV is a window to his world. Fish for things you want from the CV against the job expectation. You may or may not have clarity at this point in time. But you mind keeps working behind the scenes, and this is important.
3. Prepare Yet Again. Unless you are a recruiter yourself, you wouldn't be the first person to interview the candidate. So, see if you can collect the feedback from earlier interviewers. Why? So you don't overlap what was done in earlier rounds and may want to know the gaps that could or should be filled in. This way, you make the best use of your time with the potential hire, continuing where things were left off in the earlier rounds of candidate interview.
4. Prepare One Last Time. Once you know the gaps and the areas you may want to double-check, prepare on a set of questions to ask. Frequent and odd silences during an interview would be perceived as company's lack of competence and professionalism.
5. Start the interview by introducing yourself and the company you represent in a manner that eases the candidate's stress and making him want to join your team. Do not forget that you are an ambassador of your company and thus have the responsibility to present yourself well enough.
6. Stop examining the candidate. Start exploring the candidate for his strengths and weaknesses. As bonus, you would even encounter red-flags in the candidature. The secret to exploring is having a conversation.
7. Respect. It is not your choice but an obligation. Throughout the interview, irrespective of the candidate's race, ethnicity, background, or experience level, demonstrate your respect for him/her by being humble. You are duty bound to protect and build the brand of the company you represent.
8. Do not forget to noting down key observations. Every observation counts. Usually this aids in sharing meaningful feedback about the candidate post the interview to the Talent Acquisition team.
9. Be mindful of the interview time and try to complete it within time. If you had to extend it, don't drag it much and ensure that the candidate is okay with it.
10. Just before you end the interview, make sure give room to take questions from candidate.
11. End gracefully by being thankful to the candidate for his time spent exploring the open opportunity at your company.
12. Immediately after an interview, re-visit your notes and construct meaningful feedback about the candidate that you can share to the Talent Acquisition team for use by the next round of interview.

Whether or not you hire the candidate; whether or not the hired candidate joins your company; the interview experience should be a win-win. There can't be second thoughts about it.

Course Review : Coding for A/B testing: Run more AB tests, find more winners

 

Course : Coding for A/B testing: Run more AB tests, find more winners by Ruben De Boer

Source : Udemy 

My Rating : 3/5

My Review : 

First half is pure basics on HTML, CSS and Javascript, which is not the subject of this course title. The real subject of the course is in the 2nd half and it run's through examples fast, without any introduction of the AB Testing tool.

I would recommend the course be re-structured to explain AB Testing taking 1 or 2 tools as an example. It would be much better that way.

P.S: I took this course on the Udemy business account and have shared this feedback in there as well.

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here.

So very many decades ago, Gerald M. Weinberg authored The Psychology of Computer Programming. In it, he listed The Ten Commandments of Egoless Programming, which remains relevant even today for us as not just programmers but as team-members.

Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and even to life itself.

Here are the 10 important lessons developers, project managers, and stakeholders would do well to keep in mind during the project lifecycle.

1. Understand and accept that you will make mistakes.
   Mistakes are rarely fatal in our industry, so find them early, before they make it into production, learn from them, and move on.

2. You are not your code.
   The point of a review is to find problems. Don't take it personally when one is found. Remember my words, “To err is only human, repeating it is what makes you either evil or insane”.

3. No matter how much "karate" you know, someone else will always know more.
   Seek and accept input from others. You can learn new techniques if you just ask. Always remember, it is never too late to learn.

4. Don't rewrite code without consultation.
   It is always a good idea to pair-up and have conversations on the code that you are tempted to re-write because you think it is bad. Your risks are much lesser if the code is backed by Unit tests. The least you can do is get it code reviewed before pushing code to main-stream branch.

5. Treat people who know less than you with respect and patience.
   Don’t be a bully. Seriously, just don’t be one. Grow up!

6. The only constant in the world is change.
   Things change, sometime for better and sometimes for worse. There are some things in your control which you can leverage to change things for better. Be the change that you wish for good. Also be willing to accept change for the overall good of the team.

7. The only true authority stems from knowledge, not from position.
   Don't wield a title like a badge of "rightness." If you want to be loved and respected in an egoless environment, cultivate knowledge. It may or may not lead to authority, but sure leads to love and respect from others.

8. Fight for what you believe, but gracefully accept defeat.
   Open culture is not being polite in the front and back-bitching in the back. Rise up, voice your concerns, be heard, and make your point of view by doing your homework, all with an intent to help and learn otherwise. You can’t accept defeat, if you carry the burden of your ego.

9. Don't be "the guy in the room".
   There are so many beer buddies, movie mates, cigarette companions, and what not, who can come together or fight fiercely on any non-professional topics by respecting each other; but definitely not discuss and debate openly, work related matters for team’s betterment. Just don’t be that guy in the room.

10. Critique code instead of people – be kind to the coder, not to the code.
    Pour your frustration on lifeless things instead of on emotional beings. Corollary, if someone were to show his frustrations on you instead of your work, be a little polite to him, discounting it as emotional down syndrome. I have been on both sides, and so will you sometime. Let us support one another and grow together.

Just to re-iterate, these commandments are still incredibly relevant. Put it to deliberate practice and with time they will bring out a better developer and co-worker in you.

You can get this book from Amazon.

Tensegrity In Microservices Architecture

Tensegrity or Tensional Integrity is also known in layman words as Floating Compression. In engineering field, it is the science of building a structure of isolated "compressed components" like bars that connected by "pre-stressed tensioned loose components" like cables or tendons. Any disturbance to a component in the assembly not just alters but brings down the entire structure.

Below is a picture of one such engineering model. Take a deep breadth and try to identify the connectors that help maintain the beautiful engineering model that you are witnessing.

Think of a table engineered by applying Tensegrity principles, like the one above. You may love looking at those crafty products but when it comes to buying it for your daily use, you think of  durability, don't you?

Tensegrity in software product/services is taboo, for it is not a deliberate engineering but a result of neglect or poor engineering. It's manifestation crops up so often in today's buzz-word architecture -- microservices. Every company dreams of building and connecting together a loose set of services as one application overlooking the cons in distributed architecture. Some of the examples of its manifestation are:

• Consumer service go down when its Producer service is unreachable.

• Consumer service go down when its Producer service is times out.

• Consumer service go down when its Producer service returns unexpected response.

I have voiced openly against startups going micro-services first architecture during my consulting days. I still warn them. I am a big advocate for monolith first and then tearing it down into microservices, after you got your domain modelling right and have well defined bounded context. And when you do break it down into microservices, it gives you enough leeway to accommodate your learnings from your short-comings in building distributed architectures. Tensegrity is the very basic thing, that you should watch out for and solve in your engineering microservices architecture by not re-inventing the wheel but by making use of available libraries that resolve these kind of issues.

Remember this as you refactor your monolithic architecture to microservices one,

Moving from monolithic architecture to microservices architecture is shifting complexity from your application to orchestration. Know your strengths and find your balance. 

Book Review: Red Yellow Green: What Color is Your Money?

What color is your money? by Noah Gift @ Lean Pub

The book titled, "Red Yellow Green: What Color is Your Money? The survival manual for gig workers and consultants" by Noah Gift is a good and engaging read. I personally have experienced and was diligent enough to escape many a potential predators. Actually, I have come across those predators that are super sweet in talk, popular (don't know if this is a paid for PR thing that is so common these days) for his other works than what he is doing (for example if he is a founder of a tech consulting company, he would have been popular in authoring a book or two), etc. Consulting is definitely a high-risk, high-reward endeavor. It is the same with doing a co-founding venture in a start-up. I would say this is THE MOST  IMPORTANT thing to watch out for during the course of your engagement. The author is in fact polite but firm in pointing this one out, which is my favorite of all. I wish the author cites an example or two of the things on how one could be deceived, to make it more sticky in the minds of a reader. I do think that the author needs to add more content on the later chapters in similar lines with some examples to make it more motivating and interesting.

All said, I would recommend you give this one a read, for it is worth your time and who knows, it might save you from the possible predator. An experience with a predator can be so unnerving or at the very least bitterly frustrating experience. I have always managed to escape this making Legal as integral part of my ventures.  

Lastly, this review is based on the rough-cuts of this work-in-progress book that was made available in O'Reilly's SafariBooksOnline.