How NOT to get a job offer as new grads

Disclaimer: This post represents my personal experience only, and has nothing to do with any organization or group. 

When I was a student, I read tons of articles on how to prepare for job hunting and how to get a job offer. Now, I am sitting on the other side of the table and start to participate in the talent acquisition process myself. This gives me a different perspective on the recruiting process. In particular, how I decide NOT to move forward with a candidate.  Here I am giving a few examples for new grads: how NOT to get a job offer. Follow this list, and you will likely NOT get an offer. So, try not to be a follower.

A lot of these are probably common sense, but I am shocked how many students (including me in the past) sometimes just forget common sense.

  1. Use the same generic resume for every company
    • A lot of tech companies do not ask for cover letters, so the only way you can showcase yourself is resume. Positions with the same title may have very different functions and job descriptions in different companies. For example, company A, B, and C all have the position Data Scientist. However, company A emphasizes big data application and machine learning, company B emphasizes analytics, data manipulation, and visualization, company C emphasizes natural language processing. While you may use the same project, say sentiment analysis for all 3 companies, you may want to highlight big data framework for company A, data wrangling and visualization for company B, and NLP model pipeline for company C. Although in practice, you may have several projects across different aspects of data science. Tailor your projects according to a specific job description. Even better, if you can have an informational interview with an employee from your target company to learn more about the job, you can better customize your resume.
    • I personally like it if you put your Github link, personal website link, LinkedIn link on the resume to show that you are an active coder with some projects. But let me be honest, most interviewers are just too busy with their own job to actually click on your links. In rare cases (mostly personal preference of the interviewers) when they click on your link and find nothing impressive, it would be a negative point. With this being said, I would still recommend students put some links if you really have good coding experience and well-maintained Github and LinkedIn.  If you really do not have extra energy to maintain any pages, just do not put any links. Poorly maintained links are worse than having no links at all. After all, links are just add-on items. What is more important is the projects themselves.
  2. Toss many buzzwords without understanding them well
    • A rule of thumb for anything you put in the resume or anything you mention in an interview is that only include things you know well. Deep learning is a good concept, but do not include it in your resume for the aforementioned company A and B if the only experience you have is using Keras to run some toy projects. Because first of all, A and B do not require you to know deep learning, so why waste your resume space on something not required rather than highlighting the skills they require? Second, interviewers are very good at spotting buzzworders. If you mention “sentiment analysis”, expect to be asked the nuts and bolts of the whole pipeline.
    • If you do not know something, just admit it. It is better to say “I don’t know” or “I only use that for a class project”, than try to answer something you do not understand well.
  3. Copy & paste other people’s projects
    • There are a lot of data science projects that people shared online. And if you just copy other people’s projects without adding your own creative thoughts and showing your initiatives, you will certainly not stand out. Worse even, using a generic project such as the classic Kaggle Titanic, it would be more difficult to come up with new ideas.
  4. Know close to nothing about the company/position
    • Interviewers are also human beings, and they have pride and would like to be acknowledged. If you know something either through browsing company’s website, talking with people on career fairs, checking current employees’ LinkedIn, or having informational interviews with current/past employees, it is certainly helpful for you to be more prepared, and to show the interviewers that you care. Coming to an interview with experience in robotics for company B which requires data visualization is certainly not the best fit. Speaking in a negative manner about the company you are interviewing such as discussing the lawsuit against the company is probably not the smartest idea.
  5. Answer phone/video interview somewhere noisy
    • This is really common sense. You simply cannot communicate clearly when the background is noisy. Here are a few quiet places to consider
      • home. Although you may still have some unexpected disruptions such as delivery and cat meowing, it is in general a quiet place.
      • library. If somehow your phone has no reception at home, if you are still a student at school, try to check if you can reserve some study room in the library.
      • quiet cafe. If you decide to use public space such as a cafe, make sure it is a quiet place, without loud music and conversation in the background, and make sure you have a table in front of you where you can place your laptop for coding or taking note.
    • If none of these options works, reschedule your interview until you can secure a quiet place.
  6. Do not ask for help when you are stuck
    • Most candidates do not solve an interview question in one shot, which is totally fine. In fact, this is an opportunity for candidates to demonstrate their ability to ask clarification questions, seek guidance and discussion. I would give a positive point for candidates who are initially stuck but are not afraid of asking hints and explaining their questions, and eventually get on the correct track.
    • Sometimes the reason why you are stuck is because you do not understand certain technical jargons, sometimes you are just so nervous that you do not realize you have a typo in your code, sometimes you simply forget a particular function. We all have such moments and it is totally okay. Think out loud. Interviews are there to collaborate with you to solve a question. If interviewers understand why you are stuck, it is easier for them to guide you.
  7. Code in silence without explaining your thoughts
    • If you are stuck and silently trying very hard to solve the question yourself without asking for help, the interview experience for both you and the interviewer is unlikely to be pleasant.
    • If you actually solve the question smoothly but does not bother to explain how you solve it in words: what you are thinking when you use that loop, and why you use a hashmap to store your results, you may think the interview experience is positive. But from the interviewer’s perspective, in particular, from a future co-worker’s perspective, you have not demonstrated yourself as a collaborative co-worker. At work, you will not be working and coding alone, and you will be expected to communicate your thoughts and solutions to others.
  8. Do not admit/acknowledge your mistake or ignorance
    • It is one thing to get stuck, but it is another to dismiss your mistake. Sometimes, a question can be tricky with multi-level complexity. You may solve the first part and totally ignore the second part. Most of the time, the interviewers may tell you there is another part you miss. Some candidates take the feedback/guidance well, and continue to brainstorm and modify their solutions. But sometimes, candidates may start to defend their solution, and are not willing to make changes. While defending your position can certainly demonstrate your confidence and self-assurance (therefore I would say being a little defensive is not bad), too much defending can be taken as a sign of being stubborn and uncollaborative.
    • Sometimes, you write something in your resume such as “sentiment analysis” but do not understand or totally forget the detail of your project. Although I already describe in the previous paragraph that it is a bad move to include things you do not well understand to begin with, if this indeed happens, just admit that you forget or explain that it is a school project and you were modifying the featurizer part only in the existing code framework so did not understand the whole pipeline. Admitting your ignorance or lack of experience honestly is much much better than trying to make something up and throw buzzwords.
  9. Monologue for over 2 minutes
    •  I know an end-to-end machine learning project can be quite complex and you have done everything from data extraction, data wrangling, model building, to visualization and reporting. And I am sure this project is worth a 30-minute PowerPoint presentation. However in a 30-60 minute long interview, how much time would you like to allocate on one single project? Furthermore, how much time do you want to allocate for questions from the interviewer?
    • “Can you tell me more about project X?” Questions like this are both for you to showcase your technical skills, and for the interviewer to have a sense of your presentation style. Interviewers may also take notes of some particular techniques you mentioned and have follow-up questions on those.
    • When you practice by yourself, if the time you spend describing a project is over 2 minutes, try to make it more concise and only highlight the techniques that interest the interviewer.
    • In general, it is a good idea to convert a monologue to a dialogue between you and the interviewer when you answer a question. For example, when asked “Can you tell me more about project X?”, and your project is about New York taxi waiting time prediction (I just make this up), you may start your answer with “I have lived in New York for 5 years and every time when I want to get a taxi, I feel that I have to wait forever. However when I do not need a taxi, I always see a lot of empty taxi passing by. I am sure you have similar experience…(this gives the interviewer time to reflect) I guess that’s why a lot of people start to use Uber which at least shows how much time they expect to wait …”
    • The idea is that try to make your project somewhat relatable and conversational, and leave room for open discussion and questions.
  10. Speak too fast for others to keep up
    • Similar to the previous one, in a conversation, if you speak too fast, it feels less authentic as if you are reciting some practiced answer. Also, it is more difficult for interviewers to think, reflect, and react.
    • My friend and I have tried the following approach to improve our presentation style. There is no need to write your answers in advance, just think for a second and start to chat with a friend. You can even record yourself and how natural and passionate you are when you talk about something you actually experienced and like to share with others.
      • Find something X you are passionate about. It could be movies, sports, cooking, manga, videogames, hiking. Whatever you like.
      • Now tell me more about your favorite X experience and why you like it. For example, your favorite movie, your favorite restaurant, your favorite game.
  11. Dismiss a question as too easy
    • If you get an interview question which you are certain that you know the answer, good for you. For example, you may get some binary tree search algorithm question that you have practiced tens of times at school. There is nothing wrong with good preparation.
    • But if you appear dismissive and say something like “Ah that’s JUST an easy depth first binary tree search, and you can JUST do this and that.”, you are basically setting the interviewer’s expectation very high since the interviewer already learns from your own words that you know the solution. So you’d better solve it correctly. Even more, because of your “JUST” sentences, the interviewers may be unwilling to offer guidance as they think you should’ve known everything.
    • Worse, after you express your general approach of “JUST do this and that”, you cannot structure a workable solution,  because you “did this in junior years, and it’s been so long and don’t quite remember”. So is this question too easy or too hard for you?
    • In workplace, you will not be solving “hard” (with LeetCode standard) algorithm questions all the time, and perhaps most of the time, you are working on some “easy” problem. The label “easy” is artificial, and should not be dismissed as not important.
  12. Go straight to crunching a solution and do not ask clarification questions
    • You may still get the answer half right without asking any follow-up questions, but it is unlikely you get it 100% right. When interviewers ask questions, they sometimes only give minimal information just to get you started, but they may withhold additional information such as the scope of the problem and corner cases. If you do not ask, you may not get such information at all, or only get them later.
    • Asking clarification questions is more critical when you are given an open-ended question, such as “how would you predict the number of users for our network in 2020?” Clearly it is a time-series prediction question, but before you dive deep on building some moving average models, start with high level business case analysis: what are the factors that affect the number of users for our network? Who are our current customers and competitors? What does the number look like in the past years and how has it changed? Building a consulting framework to structure your thoughts not only helps you organize your solution but also demonstrates your communication skills.
  13. Have no project experience outside academia
    • This may be a minor point and I expect others disagree with me. But for me, I would love to see a candidate takes initiatives in relevant projects outside academia. A lot of times, candidates (new grads) only list projects they have done at school for courseworks or their research projects at graduate school. These projects are of course very valuable and informative, but they are all supervised, either by the class lecturer or by the research advisor. You may still demonstrate creativity, critical thinking, and problem solving in these projects, but there is one thing not shown there: initiative in an unsupervised environment.
    • If you want to become a data scientist, you may take initiative to participate in data hackathon, contribute to open source projects, or simply download some open data that interests you and play with them. A side project does not have to be complex nor involve fancy algorithms. After all, algorithms and methods are only tools. The questions you are asking and the perspective you approach the dataset are more interesting.

4 comments:

  1. Great write up Ju! It’s nice seeing it from a more technical perspective as well. I hope you don’t mind me sharing on LinkedIn 🙂

  2. 想问下除了 data hackathon之外,还有别的什么方法可以做一些有亮点的项目吗?

    1. I personally like projects that are initiated by the candidate, aim at understanding or solving a real-world problem, and provide end-to-end technical solutions combined with business impact. It does not have to be hackathon or anything formal. The point is to demonstrate your own interest and motivation in data mining and exploration.

Leave a Reply

Your email address will not be published. Required fields are marked *