Tips for Coding Interview

During the Coding Interview

Congratulations, you are ready to put your skills into practice! In a real coding interview, you will be given a technical question (or questions) by the interviewer, write code in a real-time collaborative editor (phone screen/virtual onsite) or on a whiteboard (onsite) to solve the problem within 30–45 minutes. This is where the real fun begins!

Your interviewer will be looking out for signals that suggest you fit the requirements of the role and it is up to you to display those signals to them. Initially it may feel weird to be talking while you are coding as most programmers do not have the habit of explaining out loud as they are typing code. However, it is hard for the interviewer to know what you are thinking just by looking at the code that you type. If you communicate your approach to the interviewer before you start coding, you can validate your approach with them and the both of you can agree upon an acceptable approach.

Self introduction

Self introductions in interviews are slightly different from real life - you need to tweak it to your advantage - tailor the self introduction to the role and company you are applying for! Your self introduction evolves as you grow and are at a different stage of your career.

Whether you're at a job fair with hundreds of other candidates and you have limited time or you are simply explaining who you are to a potential connection or client, it is important to be able to clearly and accurately describe your knowledge and skills quickly and succinctly. Your self introduction is an elevator pitch for yourself!

Short - You have limited time!

Direct - As you only have limited time, you should get to the point

Attention-grabbing - Present your most attractive ideas

Upon receiving the question

Many candidates jump into coding the moment they hear the question. That is usually a big mistake. Take a moment to repeat the question back at the interviewer and make sure that you understand exactly what they are asking. Repeating back/rephrasing the question will reduce chances of miscommunication.

Always seek clarification about the question upon hearing it even if it you think it is clear to you. You might discover something that you have missed out and it also sends a signal to the interviewer that you are a careful person who pays attention to details.

Some common questions you can ask:

🚀 How big is the size of the input?

🚀 What kind of values are there? Are there negative numbers? Floating points? Will there be empty inputs?

🚀 Are there duplicates within the input?

🚀 Can I destroy the original array/graph/data structure?

It’s ok not to know everything

You will receive lots of questions during the interview. You can’t know everything. Nobody can know everything, it’s fine. What important is that knowing at least the fundamentals of your expertise area.So when you receive a question that you don’t know much or nothing at all, just say it, but you should also tell them that you are willing to improve yourself, you’re open to learning new things

Think loud during interview

You might have heard this phrase many times "Always think loud during interview". In fact this is key to crack any interview even if you don't know the answer to a particular problem. Trick is just speaking the way you are approaching the solution so interviewer can track your thought process and guide you. Believe me, this is the best scenario if the interviewer will give you the hint and you crack the solution, If this happens maximum chances are there you nailed that round of interview

If anything is unclear about the problem when you first read it over, ask your interviewer. Clarifying your assumptions and basic ambiguities are vital to ensuring you’re solving the correct problem.

If the interviewer offers a hint or counterexample, make sure you incorporate them in your approach.

Don't code silently

It’s important to remember that this portion of the interview is not actually all about coding. Your interviewer doesn’t want you to code in silence for fifteen minutes and then announce that you’re done, but rather to talk out loud and explain what you’re coding.

As an interviewee, it’s important to ensure that your interviewer understands what you’re doing and why you’re doing it in real-time. If you’re explaining your thought process out loud and you take a wrong turn, your interviewer may offer you a hint to get you back on track. However, if you jump straight into coding without explaining your thought process first, you may miss the opportunity to receive support from your interviewer. Worse, you could be wasting valuable time on an incorrect approach.

While you’re coding, don’t read your code; but rather, talk about the section of the code you’re implementing at a higher level. Explain why you wrote it that way and what it’s trying to achieve.

Remember that your interviewer needs to be able to understand your code to efficiently evaluate whether your code returns the expected result and solves the problem. As you code, keep these pointers in mind:

🚀 Use good style when writing your code. Reading another person’s code is typically not an enjoyable task, but reading badly formatted code can be a challenge for your interviewe

🚀 Naming Matters. Make sure to use the right variable, function, and class names. You should also avoid single letter variables unless they’re for iteration

🚀 Demonstrate good modularity. Your goal is to write code that’s adaptable to change. Identify the concepts that are likely to persist as new requirements come in and cement them into your design; more volatile logic should be easy to identify and change

🚀 When you’re finished, let the interviewer know and then ask them if you can have a look at your code to ensure there are no mistakes

🚀 Take a step back and briefly read through your solution, examining it as if it were written by someone else, but don’t start debugging it manually. This is the same approach that will be taken by your interviewer. Fix any issues you may find

Walk your interviewer through the code and explain your rationale. If you find a bug or mistake, feel free to acknowledge it and make the change

Progressively optimize your solution

After talking through the brute-force solution, at this point, the interviewer will usually pop the dreaded "Can we do better?" question, meaning that they are looking for a more optimal approach. If so, it’s now time to revisit your suboptimal solution and optimize it.

Like the process of getting to a brute-force solution, don’t jump straight into code when finding a more optimal solution. Discuss your approach with your interviewer and lean on them to get a sense of whether they have a preference for whether you optimize for time, space, or both. When optimizing, some of your initial assumptions may change, so it’s important to check with your interviewer

You may see the most optimal solution right away or be unsure on how to proceed. If you’re stuck, here are some common approaches to optimizing:

🚀 Take a second look at the problem, its constraints, and write down your assumptions and possible simplifications

🚀 Consider similar problems you’ve seen and discuss them with your interviewer

🚀 Solve an example by hand and extrapolate about what algorithm(s) could be used

🚀 Simulate the brute-force solution by hand and identify the inefficiencies that could be optimized with a data structure

🚀 Solve a simple version of the problem first, then build on it

Don’t forget to communicate and analyze the time or space complexity of the solution you plan to optimize. Once you and your interviewer agree that you have a good solution, it’s time to code it

How to write test cases

You’ve coded up a solution that you may not be so happy with, it’s time to do some manual testing to ensure it performs how you expected. The interviewer will want you to write tests for your code, so it’s a plus if you write tests without being prompted.There are a few types of inputs you’re going to test for:

Large and small valid inputs

Large and small invalid inputs

Random input

For each input, manually go through your code and ensure that it performs. You should jot down or tell your interviewer the values of each variable as you walk them through the code.

If you find an error, explain the error to your interviewer, fix it, and move on. Similarly, if there are large duplicated code blocks in your solution, you can take the time to restructure the code

In this stage, you’ll also have the opportunity to showcase your knowledge around automated testing. You can chat about how you’d generate different types of inputs, how you would stub parts of the code, the test runners you’d use, and more. These are all great signals to show an interviewer

If your interviewer was content with your solution, the interview would end here. Time permitting, they may ask you additional questions such as how you’d approach the problem if the input was too large to fit in memory. For companies that care about scale, this is a common follow-up question.

Binary tree obsession

Why do engineers love to ask fundamental linked list and tree questions in interviews when you rarely code these problems in real-world development?

It’s how it’s always been done. But it makes sense. This ritual has sustained itself over the past few decades because it’s a fast, reliable way to spot smart candidates who can think deeply. Plus, it’s better to hire for ability to solve timeless fundamental problems than hire for knowledge based on transient tools.A typical programmer, even at a top tech company, would rarely implement a data structure like a binary tree from scratch. So, many developers might be out of practice with this at their next interview. In this course we cover all the aspects of binary tree to candidates no need to covers all the problems

Important topics in graph

Graph is the most complex topics in data structure field. But cracking interview there are 3 most important concepts to understand in graph. Most of the problems are based on these 3 concepts only

BFS(Breadth First Search)
DFS(Depth First Search)
Topological sorting

Matrix related problems

Sometimes matrix related problems plays a key role. Mostly matrix related problems comes in DFS,BFS, Dynamic programming or some array related problems. Please pay a special attentions on these problems as these problems might be the game changer

Identify a dynamic programming problem

Dynamic programming is helpful for solving optimization problems. The best way to recognize a problem as solvable by dynamic programming is to recognize that a problem is an optimization problem.We have one lecture also in our course regarding this topic

When problem given then try to identify wether it's an optimization problem or not.With optimization problems, you see terms like shortest/longest, minimized/maximized, least/most, fewest/greatest, biggest/smallest, etc.

When you see these kind of terms, the problem may ask for a specific number (like "find the minimum number of edit operations") or it may ask for a result (like "find the longest common subsequence"). The latter type of problem is harder to recognize as a dynamic programming problem, so you have to pay attention to anything that sounds like optimization

Dynamic programming simply takes the brute force approach, identifies repeated work, and eliminates the repetition. So before you even start to formulate the problem as a dynamic programming problem, think about what the brute force solution might look like. Could there possibly be repeated substeps in the brute force solution? If so, try to formulate your problem as a dynamic programming problem

Why logicmojo ?

We have seen from many years many professionals and students are spending thousands of bucks to multiple coaching centers. These coaching centers tutors never appeared for interviews. They never explain the concepts of Data Structure, Algorithms and System Design. They just touch the basic simple problems and done with topics. In logicmojo, you might have seen in our home page we have selected all the questions that are asked in top product based companies and explain the topics with those examples. So just by completing all these lectures candidates are ready to appear for the interview with a difficulty level of maximum

Why concepts are important

Concepts and how to apply those concepts in others problems. While going through these lectures you might have seen many problems are related to the same concepts. Once you understand the concepts then while interview even if the interviewer asked you problems you never heard before then you can apply those learned concepts and solve the problems

System Design for interview

System Design is mandatory for all aspirants having more than 1 year of experience in the tech industry. Through system design round interviewer can judge whether a candidate can help in designing live software product. System Design understanding is all about complete understanding various distributed components that currently trending in the market.

In this course we explain all the system design components with many live product examples like

Designing Facebook NewsFeed, Instagram, Twitter
Designing Drop Box, Uber, Search Engine, Google Docs
Designing Api rate Limiter, Distributed Cache and many more .....

Note: We keep on updating this course and adding more and more lectures so it will help subscribers throughout there tech carrier while preparing for interview

Distributed System is the key

Distributed systems are becoming more popular these days. Many top companies have created complex distributed systems to handle billions of requests and upgrade without downtime.

All organizations have majorly looking for candidates having good understanding distributed system. All e-commerce, retail business or technology companies are moving their current production house to scale. Current market trends are moving towards distributed System. We have touches lots of topics of distributed system with multiple examples in our system design course and our goal is to explore more in this area only in future. There's a lot to go into when it comes to distributed systems.

monolithic system ----> Microservice architecture

ActiveMQ,rabbitMQ ----> Kafka,Spark

RDBMS(SQL) ----> Cassandra,mongoDB

You should now have a good idea how distributed systems work and why you should consider building for this architecture. These systems are important for scaling for the future. There is still a lot to learn. Next, you should check out these topics:

Microservices and applications
Load balancing and caching
Designing databases for your systems

To get hands-on practice with building systems, check out LogicMojo's learning course for System Design. In this learning path, you’ll cover everything you need to know to design scalable systems for enterprise-level software.

By the end, you’ll understand the concepts, components, and technology trade-offs involved in architecting a web application and microservices architecture. You’ll learn to confidently approach and solve system design problems in interview settings.

Object Oriented(OOP) Design for Interview

If you're a fresher or a software engineer working in a company then surely you might be aiming to reach some big companies such as Facebook, Microsoft, Google, or Amazon. These companies conduct the design round to check the ability of the candidate whether he/she is able to build a complex system or not. This round can be a system design round or an object-oriented design round.

The main ojective of the round is to identify :

🚀 A generic problem statement will be given to the candidate, and the candidate has to come up with a technical solution using his object-oriented designing skill.

🚀 The candidate needs to identify the different objects and entities in a given problem statement.

🚀 The interviewer will check how much a candidate is comfortable with OOPs concepts and principles and how well a candidate can design a system, using these concepts.

We cover almost all the problem of Object Oriented Design. We explain class diagrams and relationship between the classes. There are plenty of problems we cover in object oriented section

Airline Reservation System(Like MakeMyTrip), Hotel Management System, Parking Design Designing Car reservation System, Deck of cards design and many more ....

Design Pattern for Interview

Design patterns are documented tried and tested solutions for recurring problems in a given context. So basically you have a problem context and the proposed solution for the same. Design patterns existed in some or other form right from the inception stage of software development. Let's say if you want to implement a sorting algorithm the first thing comes to mind is bubble sort. So the problem is sorting and solution is bubble sort. Same holds true for design patterns.

Design patterns use object-oriented concepts like decomposition, inheritance and polymorphism.They provide the solutions that help to define the system architecture

Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns

Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case
Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities
Behavioral Patterns- These design patterns are specifically concerned with communication between objects.

Scaling the system

Scalability is a key consideration when designing a system. An enterprise level program must be able to handle a large amount of requests at once and respond quickly with the latest information.

Running your next million dollar idea off of a laptop simply won’t cut it. It's time to scale. This can be achieved in a couple of ways:

Vertical scaling: You scale by adding more power (CPU, RAM) to your existing machine.

Horizontal scaling: You scale by adding more machines into your pool of resources.

Caching: Application caching requires explicit integration in the application code itself. Usually it will check if a value is in the cache; if not, retrieve the value from the database.

In-memory caches are most potent in terms of raw performance. This is because they store their entire set of data in memory and accesses to RAM are orders of magnitude faster than those to disk. eg. Memcached or Redis.

Load balancing: Public servers of a scalable web service are hidden behind a load balancer. This load balancer evenly distributes load (requests from your users) onto your group/cluster of application servers

Behavioral Round

Succeeding in an engineering career involves more than just technical skills. Behavioral interviews become more important as an engineer becomes more senior. Senior engineers should have the ability to lead and influence, resolve conflicts, anticipate risks, plan the roadmap, and more. Companies value behavioral skills and do evaluate candidates on them

STAR Format

The STAR format is a framework to help you organize your experience into sections that flows nicely.

Situation - The interviewer wants you to present a recent challenge and situation which you found yourself in

Task - Describe what your responsibility was in that situation.

Action - What did you do? The interviewer will be looking for information on what you did, why you did it and what the alternatives were

Results - What was the outcome of your actions? What did you achieve through your actions and did you meet your objectives? What did you learn from this experience and have you used this learning since?

Previous workplaces culture

Always talk carefully about your former employers/companies. I assure that you will receive a question like: “What are the reasons that you want to change your job?” or “Why did you leave company XYZ?”.Whatever the reason is, your potential employer shouldn’t think that you’re complaining about everything and if they hire you, you will probably also do the same with their company.

Perfect answer should be "I’ve worked in some nice projects with friendly colleagues, but the promotion I was expected since 3 years is still not there, so I thought maybe it’s time for a change.”

Questions to ask

Finally, when your interview is on the verge, they will ask you to ask a question. Here are some good questions to ask at the end of the interview.

🚀 What is the most important/valuable thing you have learnt from working here?

🚀 What are some weaknesses of the organization?

🚀 Why did you choose to come to this company?

🚀 What is the most frustrating part about working here?

🚀 What is unique about working at this company that you have not experienced elsewhere?

🚀 What is the most fulfilling/exciting/technically complex project that you've worked on here so far?

🚀 Tell me about the main products of your company.

🚀 What does success look like for your team/project?

Time to nail it!

With these technical interview tips, you’re equipped to begin your own technical interview preparation journey! The next step is taking advantage of all the amazing resources out there that teach you how to ace a technical interview.

Above all, keep seeking out knowledge, improving your trade, and honing those coding interview skills with practice! Getting your dream coding job means getting through the interview.