Some of my favorites are:
Programming Interview Questions and Answers
Nikhil Singhal's blog dedicated to helping you master the art of programming interviews.
- Introduction
-
Beginners
Simple coding questions–Part 1 How to find if a number is a Palindrome? Linked lists demystified Recursion–concepts and code Linked Lists – Sorting, Searching, Finding Maximum and Minimum Reverse a Linked List Searching algorithms–Linear search Binary Search String manipulation can be fun String pattern matching String functions galore Pass by value versus reference in C# How to find if a number is perfect square
-
Advanced
Lost in a Forest of Trees The Ins and Outs of a Binary Search Tree Simple Patterns: Singleton Pattern Simple Patterns: Repository Pattern Simple Patterns: Factory Pattern Implement a basic Stack using linked List Implement a Queue data structure using a linked list Operator overloading and pairing rules in C# LINQ Query, Selection, Partial Selections and Aggregations Explain System.IO and System.IO.Compression namespaces with an example How to Boost your Self-Confidence Distributed vs Parallel computing SOA interview questions Data migration strategies and design patterns
-
ASP.NET
How to redirect user to another page using ASP.NET Return different HTTP response codes from Response... Tracing page execution in ASP.NET ASP.NET page validation controls ASP.NET 4 site navigation using sitemaps How do you serialize an object to and from XML Manage state across entire application in ASP.NET How to monitor file system changes using FileSystemWatcher in C# ASP.NET @ Page directive How to add HTML Server Controls to a Web Page Using ASP.NET ASP.NET AJAX using UpdatePanel control ASP.NET Session modes explained Explain ASP.NET data binding using DataSets and DataSourceControls ASP.NET HttpModule explained ASP.NET HttpHandlers Asp.Net MVC interview questions
-
jQuery
jQuery AJAX functions part 1–the load() method jQuery AJAX functions part 2–get(), post(), getScript() and getJSON() jQuery AJAX functions part 3–ajax() Differentiate between alert(), prompt() and confirm() methods jQuery fadeIn, fadeOut and fadeTo effects jQuery Selectors reviewed jQuery to block paste in a textbox jQuery to create default text for a textbox jQuery to select/deselect all items in a CheckBoxList jQuery to show big image on hover
- SQL
- LINQ
- JAVA
-
Entity Framework
Entity Framework interview questions Entity Framework and eager loading of related entities interview questions Entity Framework and lazy loading interview questions Entity Framework transaction scope examples Entity Framework – what are the different ways to configure database name? Entity Framework - Explain ENUM usage in EF5
Please navigate to the bottom of the page for Table of Contents
Tuesday, May 10, 2016
Website design, SEO and advertising
If you are interested in learning about website design, SEO and advertising, I recommend that you head over to www.omspark.com/blog and read the detailed articles written by Urmila Singhal.
Some of my favorites are:
Some of my favorites are:
Tags:
advertising,
SEO,
website design
Monday, November 18, 2013
Overall interview evaluation parameters for a software engineer/architect
When giving technical interviews, either as a software engineer or software architect, you are not only evaluated on technical prowess but also on a bunch of other factors that make a good or not so good hire. Every company and every team has a different set of parameters on which they evaluate candidates, but here is a list that is quite common across most organizations. Note that each of these categories may have a different weight assigned to them to provide emphasis to specific skills that are more important to that team. In addition, the team and company culture have a strong influence on the hiring process and that can be learnt to some degree by reading about the company and their development philosophy.
I have also given a typical question to highlight what I mean by that category. Again, this may vary, but it should give you a good idea on how to present yourself during an interview.
This should give you a good idea on what many interviewers gauge a candidate. There are of course many more factors and qualities that guide the hiring process.
I have also given a typical question to highlight what I mean by that category. Again, this may vary, but it should give you a good idea on how to present yourself during an interview.
Quality
|
Question
|
Energetic
|
N/A – Based
on observation
|
Ready to
learn
|
N/A – Based
on observation
|
Takes new
challenges
|
What would
you do if you happen to finish your assigned task earlier? (Hint: read new
tech, fix existing bugs, help teammate, slack off, analyze data, etc.)
|
|
|
Potentially
independent
|
Tell me about a situation that required you to build your knowledge
base before solving a complex problem
|
Results
oriented
|
When do you
consider a problem solved? How much time would you spend tweaking a solution
to gain more performance? When is the performance good enough and you move to
the next problem?
|
Growth
potential
|
Describe a time when you had to complete a project in which you were
provided with very little information or guidance
|
Adaptability
|
Describe a
time when you presented a proposal or provided a service that was given an
unfavorable response by stakeholders
|
Sincerity
|
Tell me about a time when you did not meet a planned milestone
|
Mentoring
|
Tell me about a time when you mentored others
in your area of technical expertise
Provide an example of a time when you had to
motivate others to complete a challenging deliverable.
|
|
|
Team Fit
|
Describe your most recent experience
working with a virtual team.
What were the challenges you faced and how did
you work through them?
Describe a situation when you led a
project with a geographically or functionally diverse team
Describe how you have collaborated with
others outside of your immediate team to resolve a critical issue
Tell me about a time when you
experienced a major organizational change (for example, a reorganization, a
new supervisor or a new procedure) that created stress.
|
Company Fit
|
Why would you join our team and not another competitor?
What are 3 words that describe you?
What experience do you have that qualifies you for the job?
What do you consider your strengths?
What are your short term and long term goals
|
|
|
Technical
|
Given an array of numbers, write a function to remove
duplicates and sort the output
In an org, given two employees, find their common manager
SQL: Given an employee table with salaries, find the employees
that make more than their manager
Design: Consider an API management system. There is an
API portal (say NB) that has managed services that point to a variety of backend
systems (let’s call them SB). The Developer apps call the NB system which
checks for quotas, throttling, authentication, access, etc and if everything
is good, massages the request to call the appropriate SB system. The SB
response is then returned to the client. Some requests may be stateless (e.g.
GetJobs()) and some may be more stateful (e.g. async call to translate speech
to text). Design me a transactionID/conversationIDsystem that allows me to
keep track of different requests for purposes of monitoring, measuring
latency, failures, etc.
|
Data driven
|
Describe a long-term project or
assignment of which you took ownership. How did you make sure each milestone
was achieved in a timely manner?
You wanted to make a change on the website, but your product
manager was not in favor. How would you handle this?
Tell me about a situation when you had
multiple alternatives from which to choose. What steps did you take to
determine the most appropriate alternative?
|
This should give you a good idea on what many interviewers gauge a candidate. There are of course many more factors and qualities that guide the hiring process.
Tags:
design,
interviewing
How to answer software design interview questions
In the previous post on How to answer algorithmic programming interview questions, we discussed a templated approach on how to solve algorithmic questions. In this post, we will explore similar steps that will help you think in the correct direction while solving design questions.
To set some context, design questions differ from their algorithmic counterparts in how you approach them. Design questions, as the name implies, focus more on how to architect a larger system than just writing an algorithm to solve a specific aspect of the problem. Some examples of design questions may include:
1. Design a transaction ID/conversation ID for an API system
OR
2. Design a cloud based employee performance management system that can support over 100,000 employers.
Here the approach you would take would focus more on component/system design with performance, throughput, stability, scale and redundancy in mind. Let's review some of these buckets that you should keep in mind when designing large scale software systems.
Design principles and philosophy: Before you even start your broader system design, talk about your design philosophy. That is, what are your guiding principles for a good design. For example, simple, robust, scalable, resilient to failures, etc.
Product requirements: To design a good system, you need to understand what the requirements are; UI, interactions, Middle tier, backend, etc. What are the different entry/exit points, metrics that matter, etc.
System requirements: Once you have articulated the different product requirements, it is important to think and list down system requirements such as availability, scale, perf, geo-redundancy, etc. This and the product requirements will help you design a system that meets both functional and system requirements.
Which features would be Pri-0 versus Pri-1 and why: This is an optional part and you might give this more attention if the interview is more focused on product design than a system design.
Architecture: This is the meat of the interview. Here you would define various components of the system, how they interact and the data flows. You would also talk about data redundancy, database backups, load balancing, etc.
Measurement and logging: All good designs should talk about how you would measure performance, key metrics and do your logging and analysis.
Performance characteristics: You should also spend some time discussing the performance characteristics of your proposed architecture. Pay special attention to key operations and high traffic sections.
Geo-redundancy: Designing systems that serve traffic all across the globe and allow failures and fall-backs are strong characteristics of a good design.
Define how the solution would scale: Scale is something that every company, product design looks for. How would you handle increased traffic across the globe while keeping your performance relatively constant should be thought through from the very start.
Security: Most non-trivial products today have security from start. User info, financial information need to be properly secured and steps defined on how to mitigate breaches.
Talk about stability/health checks: A highly performant system that is unstable does not help. Focus on aspects that help build a stable system. Local redundancy, failovers, uptime are important factors.
Deployments/Zero downtime: Think and define how zero downtime and rolling deployments will happen.
Proposed enhancements/improvements: Since this is a first pass on design, talk about alternate design and different technologies.For example, RabbitMQ versus QPID, PostgresSQL versus Cassandra. etc.
Of course, a good system design has a strong architectural component. Focus on building a strong foundation and rest everything should be a guiding factor towards that goal.
To set some context, design questions differ from their algorithmic counterparts in how you approach them. Design questions, as the name implies, focus more on how to architect a larger system than just writing an algorithm to solve a specific aspect of the problem. Some examples of design questions may include:
1. Design a transaction ID/conversation ID for an API system
OR
2. Design a cloud based employee performance management system that can support over 100,000 employers.
Here the approach you would take would focus more on component/system design with performance, throughput, stability, scale and redundancy in mind. Let's review some of these buckets that you should keep in mind when designing large scale software systems.
Design principles and philosophy: Before you even start your broader system design, talk about your design philosophy. That is, what are your guiding principles for a good design. For example, simple, robust, scalable, resilient to failures, etc.
Product requirements: To design a good system, you need to understand what the requirements are; UI, interactions, Middle tier, backend, etc. What are the different entry/exit points, metrics that matter, etc.
System requirements: Once you have articulated the different product requirements, it is important to think and list down system requirements such as availability, scale, perf, geo-redundancy, etc. This and the product requirements will help you design a system that meets both functional and system requirements.
Which features would be Pri-0 versus Pri-1 and why: This is an optional part and you might give this more attention if the interview is more focused on product design than a system design.
Architecture: This is the meat of the interview. Here you would define various components of the system, how they interact and the data flows. You would also talk about data redundancy, database backups, load balancing, etc.
Measurement and logging: All good designs should talk about how you would measure performance, key metrics and do your logging and analysis.
Performance characteristics: You should also spend some time discussing the performance characteristics of your proposed architecture. Pay special attention to key operations and high traffic sections.
Geo-redundancy: Designing systems that serve traffic all across the globe and allow failures and fall-backs are strong characteristics of a good design.
Define how the solution would scale: Scale is something that every company, product design looks for. How would you handle increased traffic across the globe while keeping your performance relatively constant should be thought through from the very start.
Security: Most non-trivial products today have security from start. User info, financial information need to be properly secured and steps defined on how to mitigate breaches.
Talk about stability/health checks: A highly performant system that is unstable does not help. Focus on aspects that help build a stable system. Local redundancy, failovers, uptime are important factors.
Deployments/Zero downtime: Think and define how zero downtime and rolling deployments will happen.
Proposed enhancements/improvements: Since this is a first pass on design, talk about alternate design and different technologies.For example, RabbitMQ versus QPID, PostgresSQL versus Cassandra. etc.
Of course, a good system design has a strong architectural component. Focus on building a strong foundation and rest everything should be a guiding factor towards that goal.
Tags:
architecture,
design,
interviewing
How to answer algorithmic programming interview questions
Most technical programming interviews have at least one or more programming whiteboard exercise. These generally include questions like
1. Write an algorithm to reverse a linked list.
OR
2. Write a function to sort a binary tree.
OR
3. Write an algorithm to remove duplicates and sort an arbitrary long input string comprised of single digit numbers.
Almost all of such questions require you to explain your thinking on whiteboard and then design and explain your algorithm or function on the whiteboard in real time. So how do you answer algorithmic questions and make sure that your thinking and direction covers various different aspects that an interviewer is looking for.
Here is one such list that you can keep at the back of your mind when attempting to solve such questions. Some of them may not be valid for some questions, but you should try to model your answer around these tenets.
Understand the question: Make sure you repeat the question. The goal is to understand exactly what the interviewer is looking for in your answer.
Asks clarifying questions to understand what the interviewer is looking for: This is an extension of the first point. You need to ask as many clarification questions as necessary to make sure you are solving the right problem. Most questions will have ambiguity built into them and it is your job to make sure you get them clarified.
Paraphrase the problem: Once you have clearly understood the question, paraphrase it. This helps make sure to the interviewer that you really get the question and the subtleties associated with it.
Call out assumptions: Before and as you are designing the algorithm, make sure to clearly spell out any assumptions that you are making. For example, array index starts at 0, the input is assumed to be made only of numbers, etc. Unsaid assumptions have a bad habit of coming back and biting you later in the exercise.
Articulate at least one or two acceptable input and output: If possible, it is always good to show one or two possible input cases and the desired output from your solution. This helps both you and interviewer to make sure that you are on track to understanding the question.
Define broad solution: Once you have reached this stage, define a broad outline of the solution. No code, just the big ticket steps. For example, Sort the input, find the most common elements, use hashmaps, clean output to remove duplicates, etc.
Define possible other solutions (using hashtags, linked lists, trees, etc): Once you have a broad solution, make sure that you discuss or highlight some alternative approaches. This shows that you can think from a higher perspective and evaluate alternate approaches.
Draw a “manual run” on the whiteboard for input/output: To make sure that your high level solution really works, manually run your input through that to make sure you get the desired output.
Define the high level design: Now is the time to start hashing out your high level design components. Basic functions, data structures, core logic. A lot of your time would be spent here understanding and building your design.
Define the basic algorithm: Here you would be defining the core logic and algorithm for your problem. Make sure you keep talking about your approach.
Discuss time taken by algorithm (1, log(n), etc): Once you have the detailed design in place, discuss the performance characteristics of your solution. Think about minor tweaks or improvements you can do here to improve the performance.
Talk about error handling: This is very important. You should at least talk about different error conditions and how your algorithm would handle it. You can keep the whiteboard clean by not writing every possible case, but make sure you talk about them.
Handle edge cases: Any good algorithm handles edge cases without going through the entire process very fast. Make sure you spend a few minutes thinking and articulating about them.
Testing: Once you think you have the final design ready, force yourself to turn-off your brain and run a couple of inputs through the algorithm. Follow exact steps there and do not use your brain. Basically, be the computer and test. Test. Test again. You will surely uncover a few things here that you might have missed (e.g. <= instead of ==).
Regularly check in to see if the interviewer is on the same page as you: This is a very important step and needs to be done through out the interview. You need to keep the interviewer engaged and focused. Speak clearly, slowly, think aloud and make sure interviewer is following you.
Hopefully this will help you answer algorithmic programming interview questions in a much better cleaner way using a templated approach.
In the next post we will look at such a templated approach to solving design interview questions.
1. Write an algorithm to reverse a linked list.
OR
2. Write a function to sort a binary tree.
OR
3. Write an algorithm to remove duplicates and sort an arbitrary long input string comprised of single digit numbers.
Almost all of such questions require you to explain your thinking on whiteboard and then design and explain your algorithm or function on the whiteboard in real time. So how do you answer algorithmic questions and make sure that your thinking and direction covers various different aspects that an interviewer is looking for.
Here is one such list that you can keep at the back of your mind when attempting to solve such questions. Some of them may not be valid for some questions, but you should try to model your answer around these tenets.
Understand the question: Make sure you repeat the question. The goal is to understand exactly what the interviewer is looking for in your answer.
Asks clarifying questions to understand what the interviewer is looking for: This is an extension of the first point. You need to ask as many clarification questions as necessary to make sure you are solving the right problem. Most questions will have ambiguity built into them and it is your job to make sure you get them clarified.
Paraphrase the problem: Once you have clearly understood the question, paraphrase it. This helps make sure to the interviewer that you really get the question and the subtleties associated with it.
Call out assumptions: Before and as you are designing the algorithm, make sure to clearly spell out any assumptions that you are making. For example, array index starts at 0, the input is assumed to be made only of numbers, etc. Unsaid assumptions have a bad habit of coming back and biting you later in the exercise.
Articulate at least one or two acceptable input and output: If possible, it is always good to show one or two possible input cases and the desired output from your solution. This helps both you and interviewer to make sure that you are on track to understanding the question.
Define broad solution: Once you have reached this stage, define a broad outline of the solution. No code, just the big ticket steps. For example, Sort the input, find the most common elements, use hashmaps, clean output to remove duplicates, etc.
Define possible other solutions (using hashtags, linked lists, trees, etc): Once you have a broad solution, make sure that you discuss or highlight some alternative approaches. This shows that you can think from a higher perspective and evaluate alternate approaches.
Draw a “manual run” on the whiteboard for input/output: To make sure that your high level solution really works, manually run your input through that to make sure you get the desired output.
Define the high level design: Now is the time to start hashing out your high level design components. Basic functions, data structures, core logic. A lot of your time would be spent here understanding and building your design.
Define the basic algorithm: Here you would be defining the core logic and algorithm for your problem. Make sure you keep talking about your approach.
Discuss time taken by algorithm (1, log(n), etc): Once you have the detailed design in place, discuss the performance characteristics of your solution. Think about minor tweaks or improvements you can do here to improve the performance.
Talk about error handling: This is very important. You should at least talk about different error conditions and how your algorithm would handle it. You can keep the whiteboard clean by not writing every possible case, but make sure you talk about them.
Handle edge cases: Any good algorithm handles edge cases without going through the entire process very fast. Make sure you spend a few minutes thinking and articulating about them.
Testing: Once you think you have the final design ready, force yourself to turn-off your brain and run a couple of inputs through the algorithm. Follow exact steps there and do not use your brain. Basically, be the computer and test. Test. Test again. You will surely uncover a few things here that you might have missed (e.g. <= instead of ==).
Regularly check in to see if the interviewer is on the same page as you: This is a very important step and needs to be done through out the interview. You need to keep the interviewer engaged and focused. Speak clearly, slowly, think aloud and make sure interviewer is following you.
Hopefully this will help you answer algorithmic programming interview questions in a much better cleaner way using a templated approach.
In the next post we will look at such a templated approach to solving design interview questions.
Tags:
design,
interviewing
Subscribe to:
Posts (Atom)