The Art of Getting Interviewed

I was recently involved in interviewing many candidates – a mix of freshers, juniors and seniors for some positions at Virtual Instruments. Based on my limited view, I see some worrying trends at the freshers level. This blog is a result of some observations to help freshers (also applies to other candidate levels) prepare for industry.

Most of the freshers I interviewed had a Masters in CS/Electronics background – some already had an year of experience, mostly interns. It left me wondering what do they really teach at the Universities? College Ed in USA is not cheap, its a loan that haunts you most of your life. Yet, are the freshers who put a lot of money and effort ready for the real world? It appears that University CS courses still teach a lot of “outdated” stuff that hardly matters in silicon valley jobs. Are the professors aware of changes/challenges in the industry? Has the industry attempted to influence Universities to prepare students for future jobs? I honestly don’t know. Most candidates are familiar with a few algorithms, a few technologies but that alone is not enough to get hired.

Some of the common issues I see are:

lack of clarity: Agreed, that as a fresher you just want to get a break, but that should not yield an impression of “I will work on anything you give me”. Software Industry is extremely varied – engineers eventually specialize into some area based on their passion – web design, web development, server-side, networks, cloud etc are too varied to become a master of all. Ask yourself what technology motivates you most and bring out that passion. Interviewers are not expecting you to know everything or to know what they already know, but look for how quickly you can adapt, learn and positively work in a team.

too much technology on the resume: There are resumes that span from TCP/IP Socket programming to AWS Certification and myriad acronyms in between. It takes considerable amount of time to master any technology these days. Differentiate between what you know and what you have heard of. And its okay to not know. Interviewers will eventually figure that out anyway.

bad spelling and grammar: believe it or not, this is common. Imo, it just shows carelessness (not bothering to get it reviewed). Be thorough and get resumes reviewed by your friends. Inconsistent capitalization/acronyms etc. are on eye-sore on the resume.

inconsistent style: a resume should be easy on eyes, highlight the most important. Too many bolds, italics, underlines are jarring. Be consistent in content styling too. Eg: If you use italics for orgs you worked for, use italics every where. Many people assume styling is not as important as content. In reality, they exhibit at different levels. Styling plays a part in our psychology at a sub-conscious level.

resume too long: For some junior/seniors, I’ve seen resumes that run 6-10 pages long. Even if an interviewer manages to go through it all, he/she won’t remember your history. For all practicals, your last job is really the most important thing. And the one before is a useful incident.

lack of presentation skills: This is one of the biggest issues I see. Too much of “I did this” (taking credit for everything) or “We did this” (you did not contribute much) paints a wrong picture. Highlight how you worked as a team, with the right mixtures of I’s and We’s. All I had to ask is one question “Can you describe yourself briefly?” and many candidates go on a lecture of what they did technically in some project. Some don’t even pause to ask if I understood what they said (esp on phone-screens). Come with innovative ways of rephrasing most banal answers like “I want to solve customer’s problems” or “I like to learn new technology”. An interviewer is typically going thru 10s of candidates, think how you can stand out to contribute.

make your presence felt: Contribute to open source at least a bit, even if just documentation. Presence in open source communities rate higher score than just knowing how to code.

be humble but convincing: You have to be positive and attempt to convince the interviewer that you are up for the challenge, without being arrogant. For eg, if you change jobs frequently, thats usually a red flag, but you can convert that to positives. It may not be your fault that a company got sold or a project nixed due to external factors. But highlight the impact you have made on teams or groups or how you smoothened the transition without being acerbic about it. Self-confidence without arrogance gets noticed.

There is a beautiful anecdote of kAlidAsa. For those who are unfamiliar, kAlidAsa was one of the greatest Sanskrit poets. In the same court, there was yet another great poet bhavabhUti. (There were nine such). Once pArvatI (shivA’s wife) had a doubt who is greater between the two, and shivA promptly says her to test it out. So she descends to the king’s court as an ordinary woman with a (pretend) dead son and tells the king, “My son is dead. A sage predicted that a poet in the king’s court can revive him by solving a samasyA (word-puzzle)” (A samasyA is a type of word-puzzle in Sanskrit, where only half of a verse is given – usually nonsense, and the other half must be completed to make it meaningful). bhavabhUti comes and king asks him to complete the samasyA. bhavabhUti tries but the son is not revived. Then bhavabhUti says “I am sorry, this is the best I could do. Perhaps ask kAlidAsa”. After some time, kAlidAsa enters the court and is presented with the puzzle. kAlidAsa completes the puzzle with exactly the same words that bhavabhUti did. And the son is not revived either. Then kAlidAsa says to the woman “Your son is not dead because this is the only way a samasyA could be solved”. That’s the difference between the two great poets. Same content, but kAlidAsa had that self-confidence.

Finally, if you do not get selected, follow up with the interviewer what are the areas you could improve and do better next time. Most interviewers will oblige and point out positives and negatives.

The Manager Guru

In the IT industry (or any for that matter), its typical that an engineer after gaining a bit of experience (say 5y) is expected to take on a bigger role. Usually it starts with becoming a Team Lead, Module Lead, Architect etc. depending on the needs of the team or the org. Notwithstanding the title, it usually signifies the responsibility is not any more of an individual’s productivity, but ensuring that a group of people can stick to the same quality of productivity.

It is somewhat a gradual slope to slip into. All fine for a while. But a few years in the lead, then the industry also expects something drastically different – promote the individual engineer to a People Manager. There is a general tendency to question the capabilities of an individual with a wealth of experience not ending up in the management. Why aren’t you a Manager, Director or VP yet?

Its a cliche that employees leave managers, not jobs. A lot of best sellers have been written around management, lectures delivered, courses created and money made. But the fundamental problem of why employees don’t get along with their managers remains and will remain. Why? Because, humans. Understanding human psychology is a fundamental part of people management. Mere technical proficiency is not a ticket for that skill, they need to be able to debug people.

The greatest fear of any manager is that, on any given day his/her best engineer will leave. So the biggest tap dancing any manager has to do is to sustain the balance of happiness-quotient vs egoistic-importance¬†of the employee. You give too less importance to an employee, he/she will leave. You give too much importance to an employee, others will leave. While every resource is (or must be) replaceable, a manager cannot simply go around and say that to his/her employees. At the same time, the manager should not give too much importance to anyone at the cost of displeasure to others. True, in any company, everyone’s productivity is different and should be rewarded in proportion, but at the same time explicit indulgence isn’t a good management trait.

One of the first things I did after becoming a manager is, I stopped calling any one as “subordinates” and referred to them as “reports”, for a lack of better term. But now, I think even that is wrong. So I reflected a lot on “What should a manager be”?

The biggest asset of any company (project or team) is not the people, but the institutional knowledge. If the higher-ups tell you that the people are most important, its a lie. You are missing the flashing marquee of old style web page that says “you are replaceable”. So if a person leaves, he/she does not just take the knowledge, they take the crucial mental map and gap of that knowledge. That includes the nodes, links, qualities, relations, relevances and most importantly, the irrelevances. Thats almost impossible to reconstruct by someone else to the same degree. How do we protect that institutional knowledge? Documents? LOL. Knowing what won’t work is much more expensive than knowing what works.

For a different perspective, let’s look at the how some of the world’s greatest institutional knowledge were retained. In India, the guru-parampara (loosely translated as teacher-student-lineage) is the basis of its traditional-knowledge-system. Ancient knowledge has been transferred over hundreds of generations, pretty much intact. How was this possible? The Guru was once a student, gained technical proficiency, but at some point of time graduated to a senior, then eventually establishing his own lineage continuing to transfer that knowledge, by becoming a guru himself and taking care of his students. Now, why was this necessary? Because knowledge gained is considered a debt and not a business. That means the only way of getting of rid of the debt of learnt knowledge, is by teaching it to others. This way the guru is not a manager but a server to his students. The guru teaches his students, commands respect, course-corrects the errants, serves for their future, and all this by getting rid of his debt. And that makes the difference.

Most companies have an org chart that goes from top to bottom as CxO, xVP, xMgr etc. and trickles down to other staff employees. This gives a sense of people “managing” other people top down. In the guru-parampara system, the students would be at the top and who they learn from (are being served from) would be at the bottom. (Note that this is not to be confused with Top-Down management or Bottom-up management style of functioning). This is just the perspective of how one employee is seen in relation to another employee. Calling an employee a subordinate or report, pre-supposes a “superiority”, while calling a manager as one who serves his employees is a mark of humility, respect and above all – humanness – which is the original responsibility of “people” managers. It gives an opportunity for such a role to understand the human psychology, perform the role of enabling others in terms of repaying debt, rather than a sense of scaling up the hierarchy.

The roles and responsibilities are still same, but the frame of reference is now quite different. The top becomes the “root” yielding to a tree chart, where the layer below exists for the fruition of the layer above. Who knows, the tree chart could potentially allow to optimize the organization using tree-based algorithms! A binary tree org, anyone?