Last week, the renowned Gayle Laakmann McDowell, author of Cracking the Coding Interview and CEO of CareerCup.com, live streamed a 1-hour Q&A session in honor of this weekend’s Women’s Cup, an all-female online hackathon. She offered a wide range of valuable insights on how to prepare for technical interviews. You can watch the full live stream on the HackerRank Live YouTube channel here.
Here are the top 12 highlights:

Q: Is it okay to use pseudocode in an interview?

Most interviewers are not okay with pseudocode–they really want to see real code. It’s a slippery slope. It’s one thing to say the candidate doesn’t have to write semicolons–but that’s not pseudocode. Candidates can start glossing over details that can be really important. Candidates can ignore what the datatype of the list is.

That said, when I say real code–I don’t necessarily care about every little detail. If you’re implementing a method on a binary search tree, you don’t need to write the whole node class. If you want to write pseudocode as an intermediate step before writing real code, that’s okay. Just be mindful of how long you’re taking to write that because it’s taking time away from your real interview.

Q: If you were to hire somebody, would you prefer someone who’s a fast-learner or someone with strong technical skills?

It depends on the role: How long am I hiring them for? How many resources do I have?

Personally, if I’m hiring at a larger company, my bias is almost always towards someone who’s very bright because that person will have good technical judgement even if they’re not as knowledgeable. If I’m hiring someone who’s going to be the first person to architect a system in a particular technology, I’m going to hire someone who is knowledgeable in that tech. Hopefully they’re also bright.

It’s why a lot of larger companies use algorithm interviews. They have the resources to train people, so they want to hire people who are bright.

Q: How can I be great at competitive programming? How can I improve?

There are two segments to competitive programming:

1. Problem-solving
2. Knowledge

Interviews usually focus on #1 and competitive programming focuses on #2. So, as far as knowledge goes, know your algorithms really well. Know more obscure things. Pick up algorithms book. Know your different data structures.

With problem-solving side, it overlaps with interviewing. Practice a lot. Get used to the habit of not knowing how to solve a problem and getting past it. One of my favorite techniques for solving a problem that you don’t know how to do is really rely on examples.

There’s a technique what I call is “do-it-yourself.”

Give yourself a large, complex example–something that your brain can’t immediately see the answer to–and solve it manually. You’ll find that your brain has great intuition on how to solve a problem rather than just solving it rather than guessing. Reverse-engineer your thought process and think about what you did to find these pairs or matrix, etc.

Q: What’s the best way to deal with interview pressure?

The more practice you get, the less likely you are to be nervous. Practice with mock interviews. Also, grab a buddy and take turns being on the other side of the interview. Practice interviewing and you’ll find that a lot of what you thought the interviewer was doing to intimidate you or throw you off is just how interviewers naturally act.

During the actual interview, the way that you think you’re doing has no correlation to actual performance. People think they did well but do poorly. Or vice versa. I’ve seen this all the time. The reason of this is because when I’m evaluating you, I’m not evaluating you on whether or not you got the question right. I’m evaluating you compared to other people.

So, you might struggle on a question, but others are struggling too. You can’t say that you’re doing poorly because you don’t know if someone else is doing worse than you.  

Q: Do you think algorithmic questions are effective?

Great question, it’s one I get a lot. They’re pretty good at determining intelligence. I’ve seen over and over again that when you throw a smart person a problem, they tend to show really good judgement. That assumes they have some baseline of knowledge, which algorithm interviews assess.

I do think they have their flaws, which is true about every interview process. Realize they all have their problems.

One of the most important factors in how successful someone will be is to work hard and focus on their work and working with other people. Work ethic is really hard to interview for regardless. We do the best we can but no interview process will be perfect.

Q: What’s your favorite interview question?

Great question. I usually rotate after I get bored of one. Currently my favorite question is:

You have 2 string, one smaller, one larger…write an algorithm to figure out how many permutations of the smaller string exist in the bigger string.

It has a lot of different steps to it. There’s a lot of ways to tackle it. Everyone can find a solution to it. If you can’t find any solution to it, I’m pretty sure I wouldn’t hire you.

Then, there are many other steps. There’s a brute force solution most people come up with off the bat. There’s major optimization you can make and then there are several other optimizations you can make down the road. I don’t like interview questions that rely on one key insight or have one hard part to the problem. You might have gotten lucky with that hard part of the problem, so it’s not consistent. I like things with a lot of other hurdles.

It also doesn’t rely on a whole lot of knowledge. No one I’ve interviewed lacked the knowledge to tackle the problem.

Q: What was the biggest turning point in your programming life?

There were two moments for me:

1. I got an internship at Microsoft as one of the youngest interns (I was 18 at the time). It was a huge moment for me. When you have a job at a prestigious company, it opens up a lot more opportunities down the road. That was really big.
2. The other side of that: Leaving Google. I spent about 3 years there. It took me a while to say ‘This isn’t what I want to do.” Part of it was that I had equity in the company, which in retrospect wasn’t much. But it seemed significant at the time. It took me a while to say no. This was in 2008. So, not many people had left Google and it was still the company to join. It was hard for me to turn my back on that.

I didn’t want to be a programmer all day everyday, I wanted to do something more. I love programming, it was a good company and all but I wanted to pursue my entrepreneurial passion.

Q: How should I prepare for Big O questions?

Most common questions you’ll see will be: You design a new algorithm and you have to state the runtime of that algorithm. First of all, practice is a really useful thing. But one thing I’d be careful of is recognizing that variables have meanings. When you say inserting into a binary search tree is Log n, it’s not inherently Log n. It’s log of the number of nodes.

If you call the number of nodes “n” then yes, it’s Log n. But you could also say “n” is the depth of the tree. So you need to be specific and careful about what your variables are and what they mean. I’ve seen this mistake a lot. Be very careful of your variables. You’re better off not using “n” as a variable name at all. Instead, use logical variable names.

Also, be cautious of when you multiply and when you add. So, when you have two different steps of an algorithm and you do one thing and you’re all done. And then you do another thing, that’s an addition. When you walk through something and say every time you do this, you do that, that’s multiplying. That’s another mistake people make a lot.

Q: What’s the difference in interviewing process between Google and Facebook?

The interview process is far, far more similar than they are different. Yes, there are some differences, but they’re largely the same.

The first difference is that Facebook is usually more structured. People have a clearly defined role. E.g. for software engineer, you have an algorithm interview, design interview and culture fit/coding interview. It’s well-defined. Interviewee knows what they’re walking into.

The other difference is that Google tends to be more generalist in their hiring philosophy; Facebook has a little bit more recognition of specialties. At Google, there’s more of a tendency to hold a front end developer to the same expectations as a back end developer. Whereas Facebook is more likely to recognize: “Hey, you’re a front end developer, we really want that skill-set.

We might lower the expectation for some of the more generalist algorithms.” Ultimately, you don’t have to know much less, but when comparing you to other people, they don’t expect quite as much.

Again, they’re more similar than different.

Q: Is there any interview advice you’d give women and not men?

The advice I’d give to a man is typically the same that I’d give to a woman. There are some small differences. I’ve seen more women than men be particularly nervous in interviews. And be less willing to advocate for themselves. That’s one thing I often push on women than man. It’s okay to be clear about your accomplishments. I’ve seen a lot of women are nervous about attributing their accomplishments to themselves and they’re quick to giving credit to their team. Don’t take credit for your team’s stuff, but don’t give credit for what you did.

Be aware that you shouldn’t be talking about “we the team” constantly. Attribute to yourself. That’s advice that goes to both women and men, but I’ve seen this problem more in women. I’ve had women be worried about coming off as arrogant. I haven’t seen as many women that have come off arrogant as men.

Q: What skills do you need to land a job at top tech companies, like Google?

There are two parts to this:

1. Prove to the recruiter that you have the right skills.
2. Prove to the recruiter that you can pass their interview.

If you have the right experience to do well in the job and in the interview because ultimately if your resume looks great, but you can’t pass the interview, then I won’t interview you. The best thing you can do is develop a lot of projects. Have a project on your resume. Do a lot of coding. Learn a lot of programming languages. Don’t get tied to one programming language. It can actually be a little bit of a red flag for some people.

If the candidate’s all about Java, people tend to have a bad vibe from that. Identify yourself as a great software developer, and not someone who’s just great at one programming language.

The other side of the equation is demonstrating that you can do well in an interview. Demonstrate that by showing that you know algorithms and data structures. One way to do that is with a computer science degree. If you don’t have a CS degree, show that your’e taking classes on Coursera or doing things like taking coding challenges on HackerRank. Those are actually really effective.

When I’ve reviewed people who have done coding challenges like that, I put them in the “yes” pile because I know that they are interested in algorithm challenges, which is often a good sign that they’re knowledgeable about algorithms. It’s worth giving them a chance to interview.

Q: What’s the best Github project to get noticed?

I get this question a lot. The best thing to do is just do projects. People worry about little details but what really matters is that you’re doing something. If its open source, great. If it’s your own iPhone app, great. If it’s web app, great. An individual team or company might want one thing more than another. For the most part, it doesn’t matter that much. The most important thing is you’re coding.

That being said, open source has its advantages: You can what it’s like to work in a large code base. But it’s hard to attribute what exactly you did. Whereas if it’s your own iPhone app, it’s clear what you did.  Above all, pick something you’re excited about so you’ll enjoy it more….because what matters is that doing something.