| MIT : | CMU: | Stanford: |
UCB
Berkeley Artificial Intelligence Research (BAIR) |
University of Oxford / Robotics Institute |
ETH Zurich / ASL |
|
Harvard / REACT Lab |
EPFL / Robotics Lab [LIS] |
University of Tokyo / DRAGON Lab |
University of Pennsylvania / GRASP Lab | University of Edinburgh | Imperial College London |
| Max Planck Society |
TU Munich / Smart Robotics Lab | Cornell | University College London | NYU | Osaka University |
|
University of Leeds / Institute of Robotics, Autonomous Systems and Sensing |
University of Torronto |
University of Cambridge / MIL |
Princeton / IROM Lab | Caltech | Delft University of Technology |
| University of Bern |
University of Zurich / RPG |
Indian Institute of Science (IISC) / DREAM:Lab | Universität Basel |
IIIT-H / RRC | UCLA : |
here is [ list 1 and list2 ] of Computer Vision Research groups. Some good RL labs : Mila, vector-institute.
Some of the companies involved in cutting edge Robotics and Machine Learning research work:
| NVIDIA | Microsoft | Deepmind | OpenAI | Boston Dynamics | |
| Apple | Amazon | Intel | Graphcore | Anybotics | Festo |
Some of the YC - [robotics startups, AI startups], EU AI startups : ai-startups-europe.eu, generative-ai-starups.
| ETH-Z: | MIT: | Stanford | Norwegian University of Science and Technology (NTNU) | Caltech | UC San Diego: | IIT Madras : |
| TUM: | CMU: | Oak Ridge National Laboratory | NASA | University of Pennsylvania: | University of Illinois: | Deutschen Zentrums für Luft- und Raumfahrt (DLR): |
Multiagent-systems [ labs ], FDL and AI residency programs.
🌸 Some of my notes from AlgoExpert's behavioural section classes.
Communication skills and asking questions is very important. Google's behavioural round is called "Googliness and leadership skills round". Skills like - humility, learning from mistakes, team leadership are assessed. Behavioural Interviews : Questions about your background and experiences. There's no right or wrong answer in these behavioural interviews. Questions like, Tell me about a challenging project you worked on? Doesn't matter about the project, it is about the story, the artist in you that paints the story having an elegant flow. Describe the story in such a way that hints the qualities. Highlight positive things.
-
General Tips: Do not want to be disrespectful, offensive, mean, arrogant or confrontational. Avoid being too vague in your answers, interviewer is looking for signals of qualities and deep information, into detail. Answer about things that you learned, or decided to do after the situation. Things you do wanna do: Strike a balance between highlighting positive qualities that your're smart, intellectually curious, can lead projects and helping others while being empathetic. You wanna answer behavioural questions with stories, past experiences that highlights the qualities. Don't put it in every answer. If you don't extract lessons from your past experiences, it is not worth sharing. Another example, describe a time when there was a low performer on your team? Make up stuff if you have to but don't devalue your other answers. Communication is important! -
Low Performer: Q: Imagine you had a low performer in your team, how would you handle the situation and what would you do to help them? Ans: Identify the issue. Did the low performer introduced a single bug in production. Did they perform poorly throughout an entire project? Did they consistently show poor performance across multiple projects. It is very important to identify the real issue. Ask them and offer help, it might be and might not be their fault (codebase might be too complicated for sde-1 etc). It is always important to document. -
Team Conflict: Q: Describe a time when there was a conflict within your team, how did you help resolve the conflict, did you do anything to prevent it in the future? Ans: When there's a conflict, I always try to assume good intent to the two parties involved. Always try to find common ground as both parties involved have a common good intent. (e.g Google codefreeze before Cloud Next) -
Interest in Company: Q: Why do you wanna work at this company ? Ans: I wanna work for X for 3 main reasons: from a technical point of view, I know that X works with lot of technologies that really excites me, technologies that I have worked a lot on personal projects but I never got the chance to work on a production grade engineering environment. I have worked on React, Flow, TypeScript and I'd love to work on GraphQL at X, I heard its amazing. Most of X's technology stack really excites me and interests me. Putting aside the technical details a bit, I am also really interested and excited about X's culture of moving fast. I have heard that X has a very unique culture of moving fast and that's somethnig that really excites me. I've worked with Y but one thing that frustrates me is the slowness of the engineering projects. I've known few peers who have moved to X and the change of culture and velocity at which you can ship out code and launch projects and features is very dramatic between the two comapanies. Finally, X's bootcamp experience really draws me towards it, as I don't have to commit to a particular team before experienceing them. I can experience most of the teams in the bootcamp and commmit to one. I haven't heard about any other company do that and it is really appealing to me. -
Strong Disagreement: Q: Describe a time when you strongly disagreed with a coworker about an engineering decision, how did you go about finding the final decision, what did you do after the decision was made? Ans: 1) Dig Deep - try to understand every person, their ideas and stances. They have to understand as well. You do not want to attack people, you attack ideas. When people are attacking your ideas, don't take it personally. 2) Take a step back and see things from a higher level. 3) Accept and commit to the decision that was made, move forward and no grudges. -
Sudden Onboarding: Q: Imagine you and your team are in between a major project at work, with many moving parts, complicated contexts and lot of work. A new software engineer joins your team and you are tasked with onboarding him, what do you do ? Ans: A good first onbaording is very very important. It will give bad first impression, team will be affected with time and company will be affected. 3 things to give someone a great onboarding experience: 1) proper documentation in place {dev env/access info} 2) make myself available for any question they have 3) Carefully pick the projects/ bugs they will work on. Give a very minor bug to manage at first to get accustomed to pushing code, code review etc. Then give them a starter project. You're a team now, go to lunch together and spend time together. -
Work Distribution: Q: How would you go about distributing work for a project across a team of software engineers, if you've led a project in the past, describe what you did? Ans: 1) Understand what you're building and have a very clear picture of the various logical chunks that the project/work can be divided so engineers in your team can take ownership. A work that is highly difficult and critical has to be prioritized. Often times, it has to be assigned to the most capable person/least risky person. Also make sure, your engineers are happy and if they prefer to work on something - think and decide (work is more important) - have good judgement. Understand logistical issues - timezones of different employees etc. -
Past Mistake: Q: Describe a time when you made a mistake, how did you deal with the repurcussions of the mistake, what lessons did you learn from the mistake? Ans: Impatient in work, without asking and letting cofounder know of changes and pushing code to production. -
Challenging Project: Q: Describe a challenging project that you worked on, why was it challenging and what was your role on the project. How did you deal with the various difficulties of the project? Ans : It was a large project, new api for the product and had very little time to complete the product. Distribute work accordingly, relevant work to team members with context. Communicate. -
Production Outage: Q: Describe a time when you had to deal with an outage at work. How did you handle the situation. What steps did you take after the issue was resolved? Ans: First I confirmed if it was actually a real bug in production. Spend 5-10 mins to see if I can debug the issue without alerting my manager, team mates. If I was unable to, I alerted rest of the team. Don't play the hero after 5 mins. Key thing is to face the issue. Stay Calm, not point fingers at anyone. It is a stressed situation and keep calm. After the situation: write a postmortem - a document explaining the issue, what steps were taken to resolve it. -
Tough Feedback: Q: How do you feel about receiving and giving feedback. Describe a time when you received tough feedback and or a time you gave tough feedback. How did you react to it; how did you give it? Ans : Giving constructive feedback by way of radical transparency. There is no better way to improve than by receiving quality constructive feedback. Give actionable steps to improve otherwise it doesn't really help. Learn to take criticism. -
Strengths and Improvements: Q: What aspects of Software Engineering, do you think you are very good at, what are the areas that you'd like to improve, how do you plan on improving? A: I am well versed in Front End technologies - React, Redux; frontend languages - JavaScript, TypeScript, HTML, CSS. I am also good at non technical aspects of Software Engineering, like taking initiative, exploring projects, setting meetings to disambiguate confusion on a project/feature. I am very good at diving deep, asking questions and making sure that people are on the same page. Every stokeholders are heard - UX designers, managers not just Software Engineers. Making sure that frontend and backends are aligned. One thing I wish to be good at is, getting to understand better on how backend decisions are made. I have started to do this lately - attending API design meetings with backend engineers. I can't be assuming things in the backend are easy, say this is an easy fix when they are not, I need to understand what I say. At my leisure, I have started to read backend engineer's design docs. -
Comfort Zone: Q: Describe a time when you went out of your comfort zone, why did you do it and what lessons did you learn from the experience? Ans: One of the best ways to grow is to push yourself out of the comfort zone. Challenge yourself with new things that you haven't done before. It is a great way to test yourself. Lessons - Management isn't easy, you can't bring your bad day energy into work and into meetings. There is no another adult to save you so you have to be attentive and very careful with what you do.
-
Coding Skills: Focus on fundamental coding skills. 6 things to do in a coding interview: 1) Descriptive variable naming - name a variable in such a way that viewers understands 2) Abstraction - seperating logically independent chunks of code into their own methods and making use of helper methods. 3) Documentation - document your code 4) Descriptive code 5) Idiomatic coding style - every coding language has a way of being written. -
Problem Solving Ability: Software Engineering at core is problem solving. Complex, Ambiguos Problems. Do these 5 things : 1) Eliminate Ambiguity - Do not jump to solve the problem without asking anything, shows you do not take time to understand the problem 2) Take time to discover the problem. Don't code immediately. Is this one problem or has many sub problems / hidden problems. 3) Discuss tradeoffs of using different methods / data structures to solve the same problem. 4) Implementing or tackling the problem in an organized manner. 5) Testing pro actively - test solution and explain before giving the interviewer the opportunity to ask. Test against edge cases. -
Communication: It can make or break you. Communication is pretty easy to assess in a coding interview. Important things to be quite clear of: 1) Eliminate Ambiguity (e.g if given some numbers to find a value - ask about whether the numbers are integer / 32/64 bit, floats) , Make it clear before diving deep, don't dive blindly. 2) Voicing your thought process. Never let interviewers guess things, that is the worst position you can put yourself in. 3) Discuss tradeoffs of your solution. Why did you choose a particular data structure and what would have been bad using a different data structure. The interviewer must know that you know the tradeoffs of different data structures. 4) Proactively asking for approval or help from your interviewer. Keep them in the loop. -
Culture Fit: Have some interest in the genre of your industry i.e, if you're applying to a crypto startup, understand crypto. Also why you're interested in that particular company? What do you bring to the table? Understand what the company is looking for! In an interview, show that you're passionate about software engineering, development, technology. Some good qualities - leadership capabilities, collaboration, independence. Be specific with what you love about the company, [do not] say that you just love Google Search [do] say that you love that particular technology of a particular team. Be flexible, do not say that you exactly want that and will only work on that. Anything that is in your resume, you should be able to describe very well - any project or experience. Prepare 2-3 questions about the company. e.g - What's been the biggest challenege on your job? technical challenege, team building challenge. What's in the day in the life of you in the company? Is this company going to be trying this in the future?
Resources : [ 10 DARK Psychology and Manipulation Tricks for POWER and INFLUENCE, 6 Dark Psychology Tricks To Beware Of, STUMPED by Behavioral Questions?, All You Need To Know About Behavioral Interviews (for software engineers) ]