Before the Interview of CTCI
Before the Interview
What Resume Screeners Look For
Resume screeners look for the same things that interviewers do:
- Are you smart?
- Can you code?
That means that you should present your resume to show those two things. Your love of tennis, traveling, or magic cards won’t do much to show that, so it’s likely just wasting space.
Keep in mind that recruiters only spend a fixed amount of time (about 20 seconds) looking at your resume. If you limit the content to the best, most impressive, most relevant items, they’ll jump out at the recruiter. Weak items only dilute your resume and distract the recruiter from what you’d like them to see.
Relevant Jobs: Your resume does not - and should not - include a full history of every role you’ve ever had. Your job serving ice cream, for example, will not show that you’re smart or that you can code Include only the relevant things.
Writing Strong Bullets: For each role, try to discuss your accomplishments with the following approach: Accomplished X by implementing Y which led to Z.
- “Reduced object rendering time by 75% by applying Floyd’s algorithm, leading to a 10% reduction in system boot time”.
- “Increased average match accuracy from 1.2 to 1.5 by implementing a new comparison algorithm based on windiff ”.
Not everything you did will fit into this approach, but the principle is the same: show what you did, how you did it, and what the results were. Ideally, you should try to make the results “measurable” somehow.
Almost every candidate has some projects, even if they’re just academic projects. List them on your resume! I recommend putting a section called “Projects” on your resume and list your 2 - 4 most significant projects. State what the project was, which languages or technologies it employed, and whether it was an individual or a team project. If your project was not for a course, that’s even better! It shows passion, initiative, and work ethic. You can state the type of project by listing course projects as “Course Project” and your independent projects as “Independent Projects” (or some other wording).
Programming Languages and Software
Software: Generally speaking, I do not recommend listing that you’re familiar with Microsoft Office. Everyone is, and it just dilutes the “real” information . Familiarity with developer-specific or highly technical software (e g , Visual Studio, Eclipse, Linux) can be useful, but it often doesn’t make much of a difference.
Languages: Knowing which languages to list on your resume is always a tricky thing. Do you list everything you’ve ever worked with? Or only the ones that you’re more comfortable with (even though that might only be one or two languages)? I recommend the following compromise: list most languages you’ve used, but add your experience level.
This approach is shown below:
Advice for Non-Native English Speakers and Internationals
Proofreading: Some companies will throw out your resume just because of a typo. Please get at least one native English speaker to proofread your resume.
Personal Information: For US positions, do not include age, marital status, or nationality. This sort of personal information is not appreciated by companies, as it creates a legal liability for them. However, you may want to include your current work authorization/visa status, particularly when applying to smaller companies who may be unable to sponsor candidates.
Behavioral questions are asked for a variety of reasons. They can be asked either to get to know your personality, to more deeply understand your resume, or just to ease you into an interview. Either way, these questions are important and can be prepared for.
How To Prepare
Behavioral questions are usually of the form “tell me about a time when you”, and may ask for an example from a specific project or position. I recommend filling in the following “preparation grid” as shown below:
Along the top, as columns, you should list all the major aspects of your resume – eg , your projects, jobs, or activities. Along the side, as rows, you should list the common questions – e g , what you enjoyed most, what you enjoyed least, what you considered most challenging, what you learned, what the hardest bug was, etc. In each cell, put the corresponding story. We recommend reducing each story to just a couple keywords that you can write in each cell. This will make the grid easier to study.
In your interview, when you’re asked about a project, you’ll be able to come up with an appropriate story effortlessly. Study this grid before your interview.
Some additional advice:
When asked about your weaknesses, give a real weakness! Answers like “My great- est weakness is that I work too hard / am a perfectionist / etc” tell your interviewer that you’re arrogant and/or won’t admit to your faults. No one wants to work with someone like that. A better answer conveys a real, legitimate weakness but emphasizes how you work to overcome it. For example: “Sometimes, I don’t have a very good attention to detail. While that’s good because it lets me execute quickly, it also means that I sometimes make careless mistakes. Because of that, I make sure to always have someone else double check my work ”
When asked what the most challenging part was, don’t say “I had to learn a lot of new languages and technologies ” This is the “cop out” answer (e g , you don’t know what else to say) It tells the interviewer that nothing was really that hard.
Remember: you’re not just answering their questions, you’re telling them about yourself! Many people try to just answer the questions. Think more deeply about what each story communicates about you.
If you think you’ll be asked behavioral questions (e g , “tell me about a challenging interaction with a team member”), you should create a Behavioral Preparation Grid. This is the same as the one above, but the left side contains things like “challenging interaction”, “failure”, “success”, and “influencing people ”.
What questions should you ask the interviewer?
Most interviewers will give you a chance to ask them questions. The quality of your questions will be a factor, whether subconsciously or consciously, in their decisions. Some questions may come to you during the interview, but you can - and should - prepare questions in advance. Doing research on the company or team may help you with preparing questions.
Questions can be divided into three different categories:
Genuine Questions: These are the questions you actually want to know. Here are a few ideas of questions that are valuable to many candidates:
- “How much of your day do you spend coding?”
- “How many meetings do you have every week?”
- “What is the ratio of testers to developers to product managers? What is the interaction like? How does project planning happen on the team?”
Insightful Questions: These questions are designed to demonstrate your deep knowledge of programming or technologies:
- “I noticed that you use technology X. How do you handle problem Y?”
- “Why did the product choose to use the X protocol over the Y protocol? I know it has benefits like A, B, C, but many companies choose not to use it because of issue D ”
Passion Questions: These questions are designed to demonstrate your passion for technology:
- “I’m very interested in scalability. Did you come in with a background in this, or what opportunities are there to learn about it?”
- “I’m not familiar with technology X, but it sounds like a very interesting solution. Could you tell me a bit more about how it works?”
How to Prepare for Technical Questions
That said, there are better and worse ways to prepare Many candidates just read through problems and solutions. Don’t do that! Memorizing or trying to learn specific questions won’t help you! Rather, do this:
- Try to solve the problem on your own. I mean, really try to solve it. Many questions are designed to be tough - that’s ok! When you’re solving a problem, make sure to think about the space and time efficiency. Ask yourself if you could improve the time efficiency by reducing the space efficiency, or vice versa.
- Write the code for the algorithm on paper. You’ve been coding all your life on a computer, and you’ve gotten used to the many nice things about it. But, in your interview, you won’t have the luxury of syntax highlighting, code completion, or compiling. Mimic this situation by coding on paper.
- Type your paper code as-is into a computer. You’ll probably have made a bunch of mistakes. Start a list of all the mistakes you made, so that you can keep these in mind in the real interview.
- Do a mock interview. CareerCup offers a mock interview service, or you can grab a friend to ask you questions. Though your friend may not be an expert interviewer, he or she may still be able to walk you through a coding or algorithm question.
What You Need To Know
Most interviewers won’t ask about specific algorithms for binary tree balancing or other complex algorithms. Frankly, they probably don’t remember these algorithms either.
You’re usually only expected to know the basics. Here’s a list of the absolute must-have knowledge:
This is not, of course, an all-inclusive list. Questions may be asked on areas outside of these topics. This is merely a “must know” list.
For each of the topics, make sure you understand how to implement /use them, and (where applicable) the space and time complexity.
Practicing implementing the data structures and algorithms. You might be asked to implement them in your interview, or you might be asked to implement a modification of them. Either way, the more comfortable you are with implementations the better.
Do you need to know details of C++, Java, etc?
While I personally never liked asking these sorts of questions (e g , “what is a vtable?”), many interviewers regretfully do ask them. For big companies like Microsoft, Google, Amazon, etc, I wouldn’t stress too much about these questions. Look up the most common questions and make sure you have answers to them, but I would focus on data structures and algorithms preparation.
At smaller companies, or non-software companies, these questions can be more important. Look up your company on CareerCup com to decide for yourself. If your company isn’t listed, look up a similar company as a reference.
blog comments powered by Disqus