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 his course we cover all the aspects of binary tree to candidates no need to covers all the problems
During an interview it's very important when interviewer asked DSA questions, don't jump to most efficient solution directly if you know the answer, that creates a wrong impression. Always start solving any problems with the brute force approach then gradually start enhancing your solution time and space complexity
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.
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
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
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
Graph is the most complex topics in data structure field. But cracking interview there are 3 most imp concepts to understand in graph. Most of the problems are based on these 3 concepts only
BFS(Breadth First Search)
BFS(Depth First Search)
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
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
The main ojective of the round is to identify :
Given a generic problem statement candidate can ask the right questions and come up with a technical solution is he able to identify the different objects and entities from a problem statement Identify how much the candidate is comfortable with OOPs concepts and principles
We cover almost all the problem of Object Oriented Design. We explain class disgrams 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 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.
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.
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
Don't waste your energy and time on those topics which is rarely asked.For knowledge purpose you can learn these topic.We have experienced developers who has given 100+ iterviews and these topics are rarely touch in any interviews. So its better just put all your efforts in different types of tree, graph and algorithms questions
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 problemsas these problems may be the game changer
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
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.”
After talking through the brute-force solution, your interviewer may ask you whether you can come up with a better solution. 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
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
Leave time to check for bugs and edge cases. Include this in your mental to-do list
Once you’re finished coding, there’s a high chance that you missed a bug or syntax error somewhere in your code. Don’t stress about it, but you will want to repair the code by yourself
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
Debugging is a very important skill, and in environments where it’s available, showcasing your ability to analyze why code failed and quickly understand how to fix it is a great signal. Good programmers are pragmatic: we’re more likely to create and solve bugs as we code, rather than to write perfect code on the first try
During the testing portion of the interview, you should have a few goals in mind
Demonstrate that you care that your code actually works
Show that you can understand and solve problems even if it doesn’t work
Exhibit your understanding of the various edge cases
Establish a feedback loop for your code that allows refactoring without having to worry about breaking existing functionality
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
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.