Software Engineering interviews can be stressful. They're typically 4 - 5 hours long meeting with 4 - 6 different people. Being prepared can be the difference between getting that job you've always wanted or failing to truly demonstrate your capabilities and skill-set. Here are some tips for preparing for software development interviews.
Make Sure You Understand The Problem, Ask Clarifying Questions
One of the bigger problems I often see in interviews is the candidate just jumping in to solve the problem without making sure they understand what they're being asked to do. Even if you feel like you understand the problem 100%, you should ALWAYS repeat back what you think the problem is before jumping in.
Every problem comes with some level of ambiguity. As you repeat back the problem think about how to remove that ambiguity. Ask clarifying questions that help you understand what is in scope and out of scope for the problem.
Review Your Data Structures
One of the main things that you need to be able to demonstrate in any software engineering interview is how well you 1) know your data structures 2) know when to use certain data structures and 3) understand the systematic complexity for each one (e.x. how long do reads or writes take). Before every interview you should review the following data structures and understand how to apply them to solve real world problems.
Give An Overview Of How You're Going To Solve The Problem
To be successful as a professional software engineer you need to be able to communicate well. It's not enough to simply be able to code. Because you're going to work on a team and with people that aren't engineers (product development, program management, design, and etc) being able to communicate effectively is an essential part of the job.
Being able to talk through your solution helps you demonstrate that you're able to communicate effectively. Additionally, talking out loud about a solution often helps you identify gaps or potential bottlenecks before you get into your code. Essentially, it gives you a chance to validate your design and show the interviewer that you can approach a problem systematically.
Focus on Solving The Problem First Then Optimize
Another common mistake I see interviewees make is getting so focused on giving the most optimal solution that they never finish creating a valid solution. You're not likely to get an offer if you can't complete the exercise within the time allotted.
Your goal should be to create a working solution first. At that point, if you have time, you can optimize it. Along the way you can point out potential bottlenecks or un-optimized code.
Keep Things Simple
Simplicity in software is a gift. Complex software typically has problems with readability, understandability, and scale. You should focus on demonstrating that you understand how to keep things simple when solving your problem.
Some easy ways to do this are:
Know How To Test Your Solutions
Make Sure You Understand The Problem, Ask Clarifying Questions
One of the bigger problems I often see in interviews is the candidate just jumping in to solve the problem without making sure they understand what they're being asked to do. Even if you feel like you understand the problem 100%, you should ALWAYS repeat back what you think the problem is before jumping in.
Every problem comes with some level of ambiguity. As you repeat back the problem think about how to remove that ambiguity. Ask clarifying questions that help you understand what is in scope and out of scope for the problem.
Review Your Data Structures
One of the main things that you need to be able to demonstrate in any software engineering interview is how well you 1) know your data structures 2) know when to use certain data structures and 3) understand the systematic complexity for each one (e.x. how long do reads or writes take). Before every interview you should review the following data structures and understand how to apply them to solve real world problems.
- Array
- Linked List
- Hash Table
- Binary Tree
- Queue
Give An Overview Of How You're Going To Solve The Problem
To be successful as a professional software engineer you need to be able to communicate well. It's not enough to simply be able to code. Because you're going to work on a team and with people that aren't engineers (product development, program management, design, and etc) being able to communicate effectively is an essential part of the job.
Being able to talk through your solution helps you demonstrate that you're able to communicate effectively. Additionally, talking out loud about a solution often helps you identify gaps or potential bottlenecks before you get into your code. Essentially, it gives you a chance to validate your design and show the interviewer that you can approach a problem systematically.
Focus on Solving The Problem First Then Optimize
Another common mistake I see interviewees make is getting so focused on giving the most optimal solution that they never finish creating a valid solution. You're not likely to get an offer if you can't complete the exercise within the time allotted.
Your goal should be to create a working solution first. At that point, if you have time, you can optimize it. Along the way you can point out potential bottlenecks or un-optimized code.
Keep Things Simple
Simplicity in software is a gift. Complex software typically has problems with readability, understandability, and scale. You should focus on demonstrating that you understand how to keep things simple when solving your problem.
Some easy ways to do this are:
- Limiting the number of classes/interfaces you create.
- Use meaningful variable names.
- Encapsulate the code into short simple methods, rather than one giant method.
- Use built in language constructs rather than re-inventing the wheel.
Know How To Test Your Solutions
Professional software engineers test their own software. You need to be prepared to identify:
- Test cases when the code should succeed
- Test cases when the code should fail
- Test cases that handle typical edge cases like NULL values, being passed 0, 1, or many objects, no connectivity, and etc.
No comments:
Post a Comment