Interview preparation software engineering

Resume critique 20m. Your experience 30m. Where do you want to go next? End of Week Quiz 30m. Reading 1 reading. Screen and video recording tips 15m. Quiz 1 practice exercise. Introductions self-assessment 30m. Week 2. Video 12 videos. Welcome and Introduction to Live Coding 57s. Cold Live Coding Assignment Walkthrough 2m. Sample demonstrating key pitfalls 5m. Talking Through Processes 4m. Getting Started 2m.

Getting Stuck and Recovering from Mistakes 5m. Correctness and Testing 3m. A Very Good Phone Interview 10m. When I struggled: a first technical phone interview 43s. Imposter Syndrome and Stereotype Threat 7m. Imposter Syndrome Gallery 15m. Reading 3 readings. Resources for finding problems to practice with 10m.

Cold Live Coding Assignment 30m. Your evaluation criteria 30m. Self-assessment 20m. Imposter syndrome and growth mindset 30m. Live coding assignment, take 2 30m. Live coding take 2, self assessment 20m. Week 3. Video 16 videos. Welcome and Introduction to Personal Narrative 2m. Sample Pitch, Broadly Technical 4m. Sample Pitch, Non-Technical 5m. Sample Pitch, Technical 5m.

Personal Narrative: Key Aspects 4m. Making the Problem Compelling 4m. Common Pitfall: Mixing Problem and Solution 4m. Common Pitfall: Assuming Too Much 4m. Presenting Your Solution 4m. Common Pitfall: In the Weeds 4m.

Common Pitfall: Chronology 4m. Eye Contact, Speaking, and Projecting Excitement 4m. When I struggled: A surprising discovery 33s. Responding to Your Audience 3m. Describing a group project 7m. Planning your narrative 30m. Video 1 video. Assignment Overview 3m. Describe your work 30m. Week 4. Video 17 videos. Welcome to algorithmic problem solving 39s. Algorithmic problem solving and interviews 4m.

Case study: introduction 5m. After reviewing the topic, you may realize that you leverage many of these patterns daily, even if you aren't aware of the formal name.

Reviewing these concepts helps provide a common shorthand, streamlining complex discussions. Example: "For gaming projects, my level state and player character are generally implemented as singletons.

Additionally, the bullets being fired by the character will be implemented in an object pool to avoid performance hits from excessive instantiation and garbage collection. If the game is more complex, I may switch to a compositional model such as Entity-Component-System. The system functions would then leverage dependency injection to better separate concerns and increase testability of the game logic. Process is an extremely important component of software development.

Since its inception, growing numbers of companies have adopted the methodologies in some form. However, there are a wide range of opinions and interpretations on the subject. And there are yet others who wholly disagree with the philosophy. No matter your opinion, wide industry adoption means you will likely work within the framework at some point in your career.

You should be capable of articulating the details of the process. Try using concrete examples from your experience. In your answer, address areas of the process such as:. Example: "Agile software development is a process that focuses on incremental delivery by the team as a whole. We used two-week sprints and kept high contact with many face-to-face discussions to review questions and concerns as they arose. In addition, we had daily standup meetings to keep everyone synced on team progress.

The only adjustment to the process I would have made was in regard to our standup meetings. However, our meetings tended to transition over into standard status meetings for our team lead rather than remaining a time for our team to sync. Other than this, the process really did facilitate delivering higher quality software on a more predictable timetable.

Testing is an extremely important component of the software development life cycle because it ensures the quality of the software before it is deployed to users. There are other approaches that enumerate particularly complex or sensitive code and write a test for those as opposed to every line.

You should have informed opinions on why you favor one approach over another. It will demonstrate that you are aware of the range of methodologies and have made a choice based on sound reasoning.

Similar to speaking about Agile software development, negative statements should be avoided in general. Example: "Testing is vital to producing high-quality software for our users.

However, in a new project, I generally will not lead with them. I think of tests as a tool for locking down mature functionality. Often, the project concept varies quite a bit from the final product as we begin collecting usage metrics and feedback. For this reason, I will begin with simple manual testing. As the feature set stabilizes, I will then begin to implement tests. The majority of my test suite will be unit tests that target key areas of the application.

Finally, assuming the infrastructure provided by the DevOps team supports it, a canary deployment will be leveraged for each release to ensure any potential impact of missed bugs is limited.

Bugs usually appear in new applications and software programs, and it's a software engineer's responsibility to locate and resolve these issues. Difficult bugs are often the result of an unusual alignment of conditions. Hearing your experience of resolving bugs explores several aspects of your skills including critical thinking and how well you handle stress and pressure.

Example: "I received a bug report from our DevOps team about one of our databases being stressed from an expensive query being called excessively from the UI. I first checked the logs to find out when the trouble started. This gave me the rough commit range in which the bug was introduced.

I was able to reproduce the bug on the latest piece of code, but only in production. I ran a git bisect to isolate the specific commit that introduced the bug and pulled the branch.

However, I was not able to reproduce the issue. I went to the UI to debug using the browser devtools. Sourcemaps are not available in our production environment, so I had to map the minified JavaScript code to the source CoffeeScript code. I was able to determine that the offending method was being called on every page as opposed to the occasional call from a lesser-used specific feature.

I decided to deploy some distinct logging statements to ensure that I had correctly identified the method. My logging confirmed the connection. Businesses form software development teams to solve problems for real people. Unforeseen obstacles often present themselves in one form or another, requiring a conversation on how to best solve the problem. Employers want to know that you are able to clearly communicate these obstacles to non-technical stakeholders, ensuring all parties are fully informed when decisions are made.

However, with the right preparation, you can boost your confidence, as well as increase your odds for success. Interviews can be stressful situations, so I go out of my way to make candidates feel comfortable. When candidates are more relaxed, it's easier to get a good understanding of their skills and assess their fit within the team.

I like to ask candidates to walk me through a complicated program on which they've previously worked that's specific to them. By allowing them to pick the system, I expect them to be able to talk about and describe it with confidence.

I want to see if they can clearly explain the system, provide the right amount of information, and field follow-up questions. Candidates get bonus points when they ask to use a whiteboard to diagram their current and past projects. I need my engineers to effectively communicate their ideas, and a whiteboard can be a great way to accomplish this visually.

Also, I want to hear about the technical challenges they've faced, what they found interesting about a certain project, what they were trying to solve, and if they were successful. I want to know if they are able to connect their work to higher business goals. Additionally, I find it really interesting to hear about failed projects. Engineers can perhaps learn more from failed projects than successful ones. I like to try and uncover — if the developer could do the same project again — what would be done differently and why.

In fact, there are still projects I think about from time to time that I wish I could approach differently now that new techniques and tools have been developed. I'm always trying to gauge how well an individual will work within a team. It's definitely one of the hardest things to assess during the interview process, but incredibly important to my team's success. There are really smart people out there that have the right technical skills, but if they believe that their 'kung fu' always has to be the best — that all the answers have to come from them — then they won't be a good fit.

Engineering is a team sport. I believe that the best and most productive teams are composed of diverse groups of people who approach problems from different perspectives. Scott E. I want to know that they're curious about where they're going to work and what is they will be doing.