How to do better without actually practicing
https://www.interviewcake.com/tips-and-tricks
Communication
Ownership/leadership
Communicate
Make it feel like you're on a team.
Use "we" instead of "I,"
Think out loud.
If you're stuck, just say what you're thinking. Say what might work. Say what you thought could work and why it doesn't work.
Say you don't know.
Slow the eff down.
Get unstuck
the interviewer usually cares more about your ability to cleverly poke the problem from a few different angles
Draw pictures. Don't waste time trying to think in your head—think on the board. Draw a couple different test inputs. Draw how you would get the desired output by hand. Then think about translating your approach into code.
Solve a simpler version of the problem.
Write a naïve, inefficient solution and optimize it later.
Think out loud more
Wait for a hint. Don't stare at your interviewer expectantly, but do take a brief second to "think"—your interviewer might have already decided to give you a hint and is just waiting to avoid interrupting.
Think about the bounds on space and runtime.
Get your thoughts down.
Call a helper function and keep moving.
Don't worry about syntax.
Leave yourself plenty of room.
Start at the top of the board and leave a blank line between each line.
Save off-by-one checking for the end. Don't worry about whether your for loop should have "<" or "<=." Write a checkmark to remind yourself to check it at the end. Just get the general algorithm down.
Use descriptive variable names.
Walk through your solution by hand, out loud, with an example input.
Look for off-by-one errors. Should your for loop use a "<=" instead of a "<"?
Test edge cases. Bonus: mention unit tests!
Don't be boring.
If you're unsure, say something like, "Then I'd usually check the code against some edge cases—should we do that next?"
Practice
Actually write code with pen and paper.
https://www.interviewcake.com/tips-and-tricks
Communication
Ownership/leadership
Communicate
Make it feel like you're on a team.
Use "we" instead of "I,"
Think out loud.
If you're stuck, just say what you're thinking. Say what might work. Say what you thought could work and why it doesn't work.
Say you don't know.
Slow the eff down.
Get unstuck
the interviewer usually cares more about your ability to cleverly poke the problem from a few different angles
Draw pictures. Don't waste time trying to think in your head—think on the board. Draw a couple different test inputs. Draw how you would get the desired output by hand. Then think about translating your approach into code.
Solve a simpler version of the problem.
Write a naïve, inefficient solution and optimize it later.
Think out loud more
Wait for a hint. Don't stare at your interviewer expectantly, but do take a brief second to "think"—your interviewer might have already decided to give you a hint and is just waiting to avoid interrupting.
Think about the bounds on space and runtime.
Get your thoughts down.
Call a helper function and keep moving.
Don't worry about syntax.
Leave yourself plenty of room.
Start at the top of the board and leave a blank line between each line.
Save off-by-one checking for the end. Don't worry about whether your for loop should have "<" or "<=." Write a checkmark to remind yourself to check it at the end. Just get the general algorithm down.
Use descriptive variable names.
Walk through your solution by hand, out loud, with an example input.
Look for off-by-one errors. Should your for loop use a "<=" instead of a "<"?
Test edge cases. Bonus: mention unit tests!
Don't be boring.
If you're unsure, say something like, "Then I'd usually check the code against some edge cases—should we do that next?"
Practice
Actually write code with pen and paper.
No comments:
Post a Comment