Wednesday, April 26, 2017

Soft Skills for Tech interviews



https://www.hiredintech.com/classrooms/interview-strategies
Make sure you understand them well.
They misunderstand what the interviewers are looking for and think that just solving the problems they’re given is enough. It isn’t - and for good reasons. 

Tip 1: Diligently follow a process

While solving an algorithmic problem at a tech interview, make sure to follow all the steps in the Algorithm Design Canvas. Same thing for the System Design Process on system design questions. Sometimes people get excited and forget to do one or more important things.

Tip 2: Ask clarifying questions

It is highly recommended that you never assume stuff at a tech interview. This could be things that are not clear in the problem statements, the programming language to use, or the functions that you have readily available. For example, it could be the case sometimes that the interviewer wants you to implement binary search and not use the one available in the standard library. Keep your mind open for such things and do not assume anything that is unclear. All this does not mean that you have to ask stupid questions all the time. Use your intuition and with some practice you will find your balance and will learn what is important to ask and what not.

Tip 3: Explain your thought process

Interviewers want to see how you think. One of their goals is to figure out if they would feel comfortable sitting next to you each day, working on various problems as a team. If they don't see that you can express your ideas this may have a negative effect on your interview.
While solving a problem, try to tell the interviewer what thoughts you are going through. Make sure they know where you are. Even when you are stuck, don't stay quiet for a long time. Tell the other person what is bugging you. This may have at least two positive effects. One is that the interviewer won't be staying on the side wondering what is going on in your head. The other is that they may actually give you a hint and help you move forward.

Tip 4: Follow the hints from the interviewer

Sometimes interviewers try to direct candidates in the right direction if they are stuck. We've seen many instances where the candidate would simply ignore the hints. Don't do that. Listen carefully to what your interviewer is saying and think well about it. This may help you reach the final goal. It is perfectly fine at an interview to solve a question with the help of the interviewer. This would not reduce your chances of getting the job.

Tip 5: Keep an eye on the clock

Follow the clock if possible and don't waste too much time on things that are not important. Sometimes candidates waste their time talking about things that are obvious. As we mentioned in a previous tip, you have to explain your thought process but this doesn't mean to mention every single detail.

Bonus tip: Keep calm and stay positive

Remember that the interviewer ultimately wants to hire you. An interview is an opportunity to meet a cool person, to have a thoughtful conversation about interesting problems, and it’s probably going to lead to your next job. Make sure you treat it like a positive experience.
Sometimes candidates say negative things about themselves or their ideas in case they turn out to be not working. Don't resort to that. Be positive, when you make a mistake point it out, but with no frustration and continue trying to solve the problem.
https://www.hiredintech.com/classrooms/interview-strategies/lesson/90
Mistake 1: Making assumptions
We've already said that in various forms but it deserves to be mentioned again. Don't assume things that are not explicitly stated. For example, you cannot assume on your own that numbers in a problem statement are integers. They could as well be floats, or have hundreds of digits. Ask questions to make any such details clear.

Mistake 2: Staying quiet for too long

Sometimes what we see is that an interviewee is given a problem and they shut up and say nothing for a while. You know they are thinking but there is no way to know exactly what is going on in their head. The interview is conducted in part because the interviewer wants to know how you think. Because of that you have to show them that. Talk about your ideas and the challenges you face. Have a conversation.

Mistake 3: Waste too much time with obvious things

This is the flip side of the previous point. Some people just talk too much going into every small detail. Find the balance, show your thought process but do not describe the obvious things. The interviewer definitely understands them.

Mistake 4: Start coding immediately

Even if you know how to solve a problem (or think that you know) don't rush into immediately writing the code. Before that you need to explain your idea to the interviewer and discuss the complexity. There may be several iterations before the solution design is cleared out. Make sure that you both have chosen a language to code in and then you may starting coding. Generally, use the Algorithm Design Canvas to have a structured sequence of steps.

Mistake 5: Copy-paste while you're coding

This is not easy to do if coding on a whiteboard or a sheet of paper. However, in remote interviews where a shared doc is used we've seen many candidates do stuff like that. You probably know that in real life this is a bad practice. So, find ways to avoid it. Structure your code better and reuse the common logic. If you find yourself in a situation where you would like to just copy and paste something in the editor think about how to restructure your current solution.

Bonus mistake: Assuming that the interviewer is always right

Sometimes the interviewer could be wrong - after all, all of us make mistakes. And sometimes they’d deliberately disagree with you to see how you respond to criticism. No matter what the situation is, make sure you calmly explain and defend your thought process. Don’t be a pushover, and on the flip side, don’t start insulting the interviewer that they’re stupid.
https://www.hiredintech.com/classrooms/interview-strategies/lesson/91

The big misunderstanding

Over time we've realized that many job candidates have a complete misunderstanding of what the interview is about. Many think of it as a war during which the interviewers will try to destroy them with hard questions. This is one of the reasons why people are stressed and fail to show the best they have.
In fact things look differently from the eyes of an interviewer. If they are looking for candidates this means that there is a job opening that they would like to fill. So, usually an engineer from the company sets in their calendar that there will be an interview. They will probably be working hard until 15-30 minutes before the interview a reminder pops up. Most likely this is the first time they will look at your resume, perhaps underline a few things and rush to the meeting room. Their hope usually is that they find a good fit for their company and the concrete position. Most interviewers find joy when they meet smart and pleasant candidates who manage to solve their problems. Their goal is not to humiliate someone and show them how stupid they are.

At the interview

Let's move to the actual interview. The goal of it is to check whether you are a good fit, of course. One way or another, smart interviewers look for several characteristics in a candidate to evaluate them. Here they are:
  1. Character
  2. Culture Fit
  3. Intelligence
  4. Skills
How you score on each of these is going to ultimately determine how well you do. Being great at any one of them (e.g. knowing the source of Java by heart) is usually insufficient to get hired. Many candidates assume that the highlight of their interview is to solve the given problems. It is essential to do that but is not enough, as we will see. Very often we hear people complain that they solved their problems but still didn't get hired. As we've already shown there are so many other things to consider in a candidate. They can also have a negative effect on the outcome of the interview.
Character refers to the way people behave in different cases. For example, in a difficult situation, do they become negative, cheat, or just be mean. Or do they handle problems well, showing integrity and support for their peers. This is hugely important as each software engineer is usually working in a team interacting with others. If you have a group of the smartest people who cannot communicate well among each other, you would still get bad results out of this group.
Culture fit is something specific to each company. For the more popular ones you can learn about their culture from their website and various publications. This is another common reason to reject smart people. It's all about whether you match the profile of the other people in the company. A simplified example is: if the company consists of geeky people who like all the new gadgets and read many blog posts about all the new technologies and you aren't such a person. Probably there won't be a good culture fit there.
Intelligence refers to the way you approach new problems. That's why it's very important for the interviewer to see your process for solving problems at the interview. If it turns out that you just memorized a number of algorithms and problems then it may become apparent that you cannot solve problems, which are new to you.
Skills are the last characteristic that is tested at an interview. It refers to your knowledge of various programming languages, technologies, etc. For example, how well do you know Django, Ruby on Rails, C++ and so on. Our opinion is that this is the least significant of the four characteristics. The reason is that someone who possesses the other three will be able to quickly pick up new skills. There are perhaps companies requiring highly specialized skills where this characteristic is more important, of course.
Finally, interviewing is not a zero-sum game: your interviewer wins and you lose, or vice versa. It’s also not a situation where your interviewer is trying to intimidate you by asking impossible questions you can never answer, just to show they’re smarter.
Instead, it’s a friendly conversation by two (or more) people who’re trying to form opinions of one another in a short period of time. It’s designed to be fast and efficient, hence the structure. But at the end of the day it’s nothing more than a conversation on an interesting topic: algorithm or system design, where often times the interviewer is just as anxious and nervous as you are.

https://www.fastcompany.com/919234/do-you-talk-think-or-think-talk
Just as some people move faster or slower, some react quicker while others speak up more slowly. If you talk to think, as you go along you talk about what you’re doing and learning. If you think to talk, you usually keep your thoughts under wraps until you have something specific to say, until you understand how to proceed, or possibly until the learning part of what you’re doing ends.
  • Make time to analyze: If you’re a think-to-talk learner who works with other people in a group, you might find it challenging to keep up with the pace of conversation. Focus your energy, instead, on making a list of the pros and cons of any decisions under consideration so that you can share what you’ve thought about with the group. By tracking your thoughts, you can help the group make progress and make a wise choice.

Labels

Review (572) System Design (334) System Design - Review (198) Java (189) Coding (75) Interview-System Design (65) Interview (63) Book Notes (59) Coding - Review (59) to-do (45) Linux (43) Knowledge (39) Interview-Java (35) Knowledge - Review (32) Database (31) Design Patterns (31) Big Data (29) Product Architecture (28) MultiThread (27) Soft Skills (27) Concurrency (26) Cracking Code Interview (26) Miscs (25) Distributed (24) OOD Design (24) Google (23) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Interview Q&A (20) System Design - Practice (20) Tips (19) Algorithm (17) Company - Facebook (17) Security (17) How to Ace Interview (16) Brain Teaser (14) Linux - Shell (14) Redis (14) Testing (14) Tools (14) Code Quality (13) Search (13) Spark (13) Spring (13) Company - LinkedIn (12) How to (12) Interview-Database (12) Interview-Operating System (12) Solr (12) Architecture Principles (11) Resource (10) Amazon (9) Cache (9) Git (9) Interview - MultiThread (9) Scalability (9) Trouble Shooting (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Cassandra (8) Company - Uber (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Design (7) Interview Corner (7) JVM (7) Java Basics (7) Kafka (7) Mac (7) Machine Learning (7) NoSQL (7) C++ (6) Chrome (6) File System (6) Highscalability (6) How to Better (6) Network (6) Restful (6) CareerCup (5) Code Review (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Python (5)

Popular Posts