Prashant Mhatre

Make Money, Programming, Bollywood, Marathi

  • You are here: 
  • Home
  • Programming

General Interview Questions

Posted on March 13th, 2008

Experience-based:


-- Sponsored Links --


  • What do you expect out of this job?
  • Describe the best manager you ever had. What made him or her stand out? How did you interact with this manager? How did you react to feedback, instructions, and criticism he/she gave you?
  • What are your three most important responsibilities in your current job? What special skills or knowledge did you need to perform these duties?

Communication:

  • In your previous jobs, how important were communication and interaction with others?
  • What experiences have you had with a miscommunication with a customer/employee/supervisor? What happened and how do you solve the problem?

Interpersonal skills:

  • Give me a description of a time when you had to deal with a difficult customer (internal or external). How did you handle it, and what was the outcome?

Problem-solving:

  • Tell me about an assignment that really challenged you. How was your approach different from that of others?
  • Tell me about a project that really got you excited. (Can probe what happened to the project, how it turned out, what problems arose, how they were handled, and perhaps most important, whether the candidates’ obvious enthusiasm led to any oversights or miscalculations.)
  • Have you ever had to make a difficult decision where no policy existed? Tell me what you did.
  • Think of a day when you had many things to do and describe how you scheduled your time.

Leadership and personal development:

  • Tell me about an important goal you set in the past and how you went about accomplishing it.
  • What efforts have you made in the last year to become a better staff/faculty/administrator?
  • Tell me about an occasion when your performance didn’t live up to your expectation. (Tough one to answer. Give the candidate points for poise and honesty; and be sure to see whether anything was learned from the situation).
  • Tell me something specific you have done that has been creative in your current job.

Faculty/Research Specific:

  • How do your professional interests/research agenda contribute to teaching a multicultural student body?
  • What teaching strategies do you use in your classes? What are the intended outcomes of these strategies?
  • How do you expect to interact with department faculty who are not in your specialty?
  • Describe a positive experience that you had with a mentor, and how do you intend to apply that to your mentoring roles?
  • What do you know about the goals of this department, and how do you fit into those goals?
  • Describe a learning opportunity you had that increased your understanding and appreciation for workplace or educational diversity.

Reference: colorado.edu

Filed under General, Programming | Comments Off

C++ Software Design Tips Guidelines Checklist

Posted on March 8th, 2008


-- Sponsored Links --


C++ Software Design Tips Guidelines Checklist

* Open/close principle
* Prefer free to member functions
* Consider moving private members to the implementation file– pimpl idiom (handle/body, compilation firewall)
* Namespace names after content (not e.g. reverse domain names) and not too deep

“Early optimization is the root of all evil”

– optimize only if it makes sense (e.g. after profiling)
– consider the disadvantages in terms of maintainability/readability

* Consider the pimpl idiom for interface classes
* Code should be reentrant/thread safe
* Prefer code to comments
* Use third ­party libs if good, in particular the standard library and boost

Header files

– Appropriate include guards
– Be independently compilable
– Don’ t impose choices on including TUs

* Useless includes in place of forward declarations
* Using directives and declarations
* Namespace aliases

Exceptions

– “Do I want/can afford stack unwinding here”
– Don’ t use exception specifications, just document them
– Derive from std::exception
– constructor/copy constructor/operator= should be throw()
– Don’ t throw in destructors
– Code should be exception safe

at least basic guarantee possibly, if worth, strong guarantee or nothrow

Filed under Programming | 1 Comment »

Effective C++ Tips

Posted on March 7th, 2008



Shifting From C to C++.

– Prefer const and inline to #define.
– Prefer iostream to stdio.h.
– Prefer new and delete to malloc and free.
– Prefer C++­style comments.


Memory Management.

– Use the same form in corresponding uses of new and delete.
– Use delete on pointer members in destructors.
– Be prepared for out­of­memory conditions.
– Adhere to convention when writing operator new and operator delete.
– Avoid hiding the “normal” form of new.
– Write operator delete if you write operator new.

Constructors, Destructors, and Assignment Operators.

– Declare a copy constructor and an assignment operator for classes with dynamically allocated memory.
– Prefer initialization to assignment in constructors.
– List members in an initialization list in the order in which they are declared.
– Make destructors virtual in base classes.
– Have operator= return a reference to *this.
– Assign to all data members in operator=.
– Check for assignment to self in operator=.

Classes and Functions: Design and Declaration.

– Strive for class interfaces that are complete and minimal.
– Differentiate among member functions, non­member functions, and friend functions.
– Avoid data members in the public interface.
– Use const whenever possible.
– Prefer pass­by­reference to pass­by­value.
– Don’ t try to return a reference when you must return an object.
– Choose carefully between function overloading and parameter defaulting.
– Avoid overloading on a pointer and a numerical type.
– Guard against potential ambiguity.
– Explicitly disallow use of implicitly generated member functions you don’t want.
– Partition the global namespace.


Classes and Functions: Implementation.

– Avoid returning “handles” to internal data.
– Avoid member functions that return non­const pointers or references to members less accessible than themselves.
– Never return a reference to a local object or to a dereferenced pointer nitialized by new within the function.
– Postpone variable definitions as long as possible.
– Use inlining judiciously.
– Minimize compilation dependencies between files.


Inheritance and Object­Oriented Design.

– Make sure public inheritance models “isa.”
– Differentiate between inheritance of interface and inheritance of mplementation.
– Never redefine an inherited nonvirtual function.
– Never redefine an inherited default parameter value.
– Avoid casts down the inheritance hierarchy.
– Model “has­a” or “is­implemented­in­terms­of” through layering.
– Differentiate between inheritance and templates.
– Use private inheritance judiciously.
– Use multiple inheritance judiciously.
– Say what you mean; understand what you’ re saying.


Miscellany

– Know what functions C++ silently writes and calls.
– Prefer compile­time and link­time errors to runtime errors.
– Ensure that non­local static objects are initialized before they’ re used.
– Pay attention to compiler warnings.
– Familiarize yourself with the standard library.
– Improve your understanding of C++.

Filed under Programming | Comments Off

More Effective C++ Tips

Posted on March 7th, 2008



Basics.

– Distinguish Between Pointers and References.
– Prefer C++­Style Casts.
– Never Treat Arrays Polymorphically.
– Avoid Gratuitous Default Constructors.

Operators.

– Be Wary of User ­Defined Conversion Functions.
– Distinguish Between Prefix and Postfix Forms of Increment and decrement operators.
– Never Overload &&, ||, or,.
– Understand the Different Meanings of New and Delete.

Exceptions.

– Use Destructors to Prevent Resource Leaks.
– Prevent Resource Leaks in Constructors.
– Prevent Exceptions from Leaving Destructors.
– Understand How Throwing an Exception Differs from Passing a Parameter or Calling a Virtual Function.
– Catch Exceptions by Reference.
– Use Exception Specifications Judiciously.
– Understand the Costs of Exception Handling.


Efficiency.

– Remember the 80­20 Rule.
– Consider Using Lazy Evaluation.
– Amortize the Cost of Expected Computations.
– Understand the Origin of Temporary Objects.
– Facilitate the Return Value Optimization.
– Overload to Avoid Implicit Type Conversions.
– Consider Using Op= Instead of Stand ­Alone Op.
– Consider Alternative Libraries.
– Understand the Costs of Virtual Functions, Multiple Inheritance, Virtual Base Classes, and RTTI.


Techniques.

– Virtualizing Constructors and Non­Member Functions.
– Limiting the Number of Objects of a Class.
– Requiring or Prohibiting Heap­Based Objects.
– Smart Pointers.
– Reference Counting.
– Proxy Classes.
– Making Functions Virtual With Respect to More Than One Object.


Miscellany.

– Program in the Future Tense.
– Make Non­Leaf Classes Abstract.
– Understand How to Combine C++ and C in the Same Program.
– Familiarize Yourself With the Language Standards

Filed under Programming | Comments Off

C++ Standard Template Library Tips

Posted on March 7th, 2008

Effective STL – C++ Standard Template Library Tips


Containers.

– Choose your containers with care.
– Beware the illusion of container ­independent code.
– Make copying cheap and correct for objects in containers.
– Call empty instead of checking size against zero.
– Prefer range member functions to their single ­element counterparts.
– Be alert for C++’ s most vexing parse.
– When using containers of newed pointers, remember to delete the pointers before the container is destroyed.
– Never create containers of auto_ptrs.
– Choose carefully among erasing options.
– Be aware of allocator conventions and restrictions.
– Understand the legitimate uses of custom allocators.
– Have realistic expectations about the thread safety of STL containers.

Vector and string.

– Prefer vector and string to dynamically allocated arrays.
– Use reserve to avoid unnecessary reallocations.
– Be aware of variations in string implementations.
– Know how to pass vector and string data to legacy APIs.
– Use “the swap trick” to trim excess capacity.
– Avoid using vector<BOOL>.

Associative Containers.

– Understand the difference between equality and equivalence.
– Specify comparison types for associative containers of pointers.
– Always have comparison functions return false for equal values.
– Avoid in­place key modification in set and multiset.
– Consider replacing associative containers with sorted vectors.
– Prefer map::insert to map::operator[] when efficiency is a concern
– Familiarize yourself with the nonstandard hashed containers.


Iterators.

– Prefer iterator to const_iterator, reverse_iterator, and const_reverse_iterator.
– Use distance and advance to convert const_iterators to iterators.
– Understand how to use a reverse_iterator’ s base iterator.
– Consider istreambuf_iterators for character by character input.


Algorithms.

– Make sure destination ranges are big enough.
– Know your sorting options.
– Follow remove ­like algorithms by erase if you really want to remove something.
– Be wary of remove ­like algorithms on containers of pointers.
– Note which algorithms expect sorted ranges.
– Implement simple case ­insensitive string comparisons via mismatch or lexicographical_compare.
– Use not1 and remove_copy_if to perform a copy_if.
– Use accumulate or for_each to summarize sequences.


Functors, Functor Classes, Functions, etc.

– Design functor classes for pass ­by ­value.
– Make predicates pure functions.
– Make functor classes adaptable.
– Understand the reasons for ptr_fun, mem_fun, and mem_fun_ref.
– Make sure less means operator<.

Programming with the STL

– Prefer algorithm calls to hand­written loops.
– Prefer member functions to algorithms with the same names.
– Distinguish among count, find, binary_search, lower_bound, upper_bound, and equal_range.
– Consider function objects instead of functions as algorithm parameters.
– Avoid producing write ­only code.
– Always #include the proper headers.
– Learn to decipher STL ­related compiler diagnostics.
– Familiarize yourself with STL ­related web sites

Filed under Programming | Comments Off

C++ Design Tips and Tricks

Posted on March 7th, 2008

C++ Design Tips and Tricks by Dr. Michael Whalen

C++ Design Tips Tricks

C++ Design Tips Tip 1:

Learn Patterns

Someone has done what you are doing before:

For Example:

  • Extracting information from a complex graph of classes (visitor)
  • Creating a framework to notify observers when some data-of-interest changes (observer)

Design Patterns are a way of expressing these ideas that give you an abstract vocabulary for a complex idea

Good Book: “Design Patterns” by Gamma et. al GoF

C++ Design Tips Tip 2:

Learn Idioms

Idioms are easy ways of expressing certain universal concerns in your programming language of choice.

  • Example: Resource Manager
  • Example: Template Specialization
  • Example: Enumeration Classes

Many found in books:

  • “C++ Programming Language” – Stroustrup
  • “C++ Common Knowledge – Dewherst
  • “Essential C++” – ???

Idiom Example: Resource Acquisition is Initialization (RAII) Create class for managing resource Maps resource lifetime to object lifetime

Responsibilities:

  • Ensure that resource is properly initialized in the constructor
  • Ensures that the resource is properly freed in the destructor
  • Ensures that resources are properly freed in the presence of exceptions.

C++ Design Tips Tip 3:

Design an Error-Handling Strategy

C++ Has Several Good Mechanisms for Error Handling. Strategy depends on application

My view:

  • Asserts – use liberally for situations that should never occur
  • Exceptions – use for situations that are very unlikely to occur
  • For system applications, define additional facilities: logging, reporting, queuing, etc.

C++ Design Tips Tip 4:

The answer is not always Object-oriented.C++ allows a range of programming styles

Not every problem is OO, nor should it be.

Ex: A numeric algorithm, such as a sequnce of matrix transforms, is a function. This kind of function doesn’t make sense as a class member. Use namespaces to group related functions that do not belong in a class.

Filed under Programming | Comments Off