Design Patterns Interview Preparation Guide
Refine your Design Patterns interview skills with our 18 critical questions. Each question is designed to test and expand your Design Patterns expertise. Suitable for all experience levels, these questions will help you prepare thoroughly. Access the free PDF to get all 18 questions and give yourself the best chance of acing your Design Patterns interview. This resource is perfect for thorough preparation and confidence building.18 Design Patterns Questions and Answers:
1 :: How to test the quality of design?
Manufacturing in the quality of the design. design pattern
2 :: What WYSIWYG web design tools are available?
WYSIWYG stands for What You See Is What You Get. The WYSIWYG
web design tools available are Microsoft Silverlight,
Microsoft Expression Blend, Adobe Dreamweaver etc.
In such editors you edit not directly the source code of your
documents, but its presentation as it will appear in the final
document.
web design tools available are Microsoft Silverlight,
Microsoft Expression Blend, Adobe Dreamweaver etc.
In such editors you edit not directly the source code of your
documents, but its presentation as it will appear in the final
document.
3 :: What is software quality?
Whether all functionalities are working as per expected?
Whether customer is delighted with the solution?
Whether actual functionalities can be scalable and
extensibility is there?
Whether customer is delighted with the solution?
Whether actual functionalities can be scalable and
extensibility is there?
4 :: Explain What is good design?
These few characteristics are signal of good design and
code:
1.Extensibility without drastic modification.
2.Good code is easy to read and maintain, and well
documented.
3.Expose clear interfaces to avoid bad coding and increase
reusability.
4.Easy to test.
5.Easy to debug.
6.No duplication (no redundancy).
7.Good code gets re-used.
code:
1.Extensibility without drastic modification.
2.Good code is easy to read and maintain, and well
documented.
3.Expose clear interfaces to avoid bad coding and increase
reusability.
4.Easy to test.
5.Easy to debug.
6.No duplication (no redundancy).
7.Good code gets re-used.
5 :: Explain What are 5 common problems in the software development process?
Problems
•Poor requirements - if the requirements are not clear,
unfinished, too common, and not testable, then there will
be problems.
•Unrealistic schedule - if too much work is given in too
little time, problems are inevitable.
•Inadequate testing - no one will know whether or not the
program is any good until the customer complain or systems
collide.
•Futurities - requests to pile on new features after
development is underway; extremely common.
•Miscommunication - if developers do not know what's needed
or customer's have wrong expectations, problems are assured.
Solutions
•Solid requirements - clear, complete, detailed, cohesive,
attainable, testable requirements that are agreed to by all
players. Use prototypes to help nail down requirements.
In 'agile'-type environments, continuous close coordination
with customers/end-users is necessary.
•Realistic schedules - allow adequate time for planning,
design, testing, bug fixing, re-testing, changes, and
documentation; personnel should be able to complete the
project without burning out.
•Adequate testing - start testing early on, re-test after
fixes or changes, plan for adequate time for testing and
bug-fixing. 'Early' testing ideally includes unit testing
by developers and built-in testing and diagnostic
capabilities.
•Stick to initial requirements as much as possible - be
prepared to defend against excessive changes and additions
once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be
adequately reflected in related schedule changes. If
possible, work closely with customers/end-users to manage
expectations. This will provide them a higher comfort level
with their requirements decisions and minimize excessive
changes later on.
•Communication - require walkthroughs and inspections when
appropriate; make extensive use of group communication
tools - groupware, bug-tracking tools and change management
tools, intranet capabilities, etc.; insure that
information/documentation is available and up-to-date -
preferably electronic, not paper; promote teamwork and
cooperation; use prototypes and/or continuous communication
with end-users if possible to clarify expectations.
•Poor requirements - if the requirements are not clear,
unfinished, too common, and not testable, then there will
be problems.
•Unrealistic schedule - if too much work is given in too
little time, problems are inevitable.
•Inadequate testing - no one will know whether or not the
program is any good until the customer complain or systems
collide.
•Futurities - requests to pile on new features after
development is underway; extremely common.
•Miscommunication - if developers do not know what's needed
or customer's have wrong expectations, problems are assured.
Solutions
•Solid requirements - clear, complete, detailed, cohesive,
attainable, testable requirements that are agreed to by all
players. Use prototypes to help nail down requirements.
In 'agile'-type environments, continuous close coordination
with customers/end-users is necessary.
•Realistic schedules - allow adequate time for planning,
design, testing, bug fixing, re-testing, changes, and
documentation; personnel should be able to complete the
project without burning out.
•Adequate testing - start testing early on, re-test after
fixes or changes, plan for adequate time for testing and
bug-fixing. 'Early' testing ideally includes unit testing
by developers and built-in testing and diagnostic
capabilities.
•Stick to initial requirements as much as possible - be
prepared to defend against excessive changes and additions
once development has begun, and be prepared to explain
consequences. If changes are necessary, they should be
adequately reflected in related schedule changes. If
possible, work closely with customers/end-users to manage
expectations. This will provide them a higher comfort level
with their requirements decisions and minimize excessive
changes later on.
•Communication - require walkthroughs and inspections when
appropriate; make extensive use of group communication
tools - groupware, bug-tracking tools and change management
tools, intranet capabilities, etc.; insure that
information/documentation is available and up-to-date -
preferably electronic, not paper; promote teamwork and
cooperation; use prototypes and/or continuous communication
with end-users if possible to clarify expectations.
6 :: What are the Design Patterns you know explain?
Basic(
interface,
Abstract parent class,
Private methods,
accessor methods,
constant data manager,
immutable object,
monitor
)
Creation(
Factory method,
Singleton,
Abstract Factory,
Prototype,
Builder
)
Collectional(
Composite,
Iterator,
Flyweight,
Visitor
)
Structural(
decorator,
adapter,
chain of responsibility,
facade,
proxy,
bridge,
virtual proxy,
counting proxy,
aggregate Enforcer,
Explicit Object release
Object cache
)
behavioral(
Command,
Mediator,
Memento,
Observer,
Interpreter,
State,
strategy,
Null Object,
Template Method,
Object Authenticator,
Common attribute registry
)
concurrency(
critical section,
consistent lock order,
guarded suspension,
read-write lock
)
interface,
Abstract parent class,
Private methods,
accessor methods,
constant data manager,
immutable object,
monitor
)
Creation(
Factory method,
Singleton,
Abstract Factory,
Prototype,
Builder
)
Collectional(
Composite,
Iterator,
Flyweight,
Visitor
)
Structural(
decorator,
adapter,
chain of responsibility,
facade,
proxy,
bridge,
virtual proxy,
counting proxy,
aggregate Enforcer,
Explicit Object release
Object cache
)
behavioral(
Command,
Mediator,
Memento,
Observer,
Interpreter,
State,
strategy,
Null Object,
Template Method,
Object Authenticator,
Common attribute registry
)
concurrency(
critical section,
consistent lock order,
guarded suspension,
read-write lock
)
7 :: What is the publish/subscribe model?
The publish/subscribe model is an approach to distributed
system communication in which publishers publish information
to a subject address and subscribers subscribe to
information at a subject address. The publish/subscribe
model has the benefit of making publishers independent of
location. This enables subscribers to subscribe to
information without having to know the location of a publisher.
system communication in which publishers publish information
to a subject address and subscribers subscribe to
information at a subject address. The publish/subscribe
model has the benefit of making publishers independent of
location. This enables subscribers to subscribe to
information without having to know the location of a publisher.
8 :: Dd you use OOA/OOD methodologies? Did you use design patterns?
No
9 :: Explain three types of components comprise an application design?
An application design is comprised of legacy components,
vendor products, and developmental software.
vendor products, and developmental software.
10 :: What are the advantages of asynchronous architectures?
Asynchronous architectures decouple senders and receivers.
This brings about performance advantages for both the sender
and the receiver. The sender is able to even out his
communication traffic over the course of a day. This is
helpful in cases where sender and receiver communicate over
low-bandwidth lengths. The receiver can even out its
processing load by processing the sender's message as time
permits.
This brings about performance advantages for both the sender
and the receiver. The sender is able to even out his
communication traffic over the course of a day. This is
helpful in cases where sender and receiver communicate over
low-bandwidth lengths. The receiver can even out its
processing load by processing the sender's message as time
permits.