Global Guideline - Interviewer and Interviewee Guide

Links

C++ Syntax Interview Preparation Guide

C++ Syntax frequently Asked Questions in various C++ Syntax job Interviews by interviewer. The set of questions here ensures that you offer a perfect answer posed to you. So get preparation for your new job hunting

C++ extends the variable declaration syntax from built-in types (e.g., int
i;) to objects of user-defined types. The syntax is the same: TypeName VariableName.
For example, if the header file “Car.hpp” defines a user-defined type called Car,
objects (variables) of class (type) Car can be created:
#include "Car.hpp" // Define class Car
void f()
{
Car a; // 1: Create an object
a.startEngine(); // 2: Call a member function
a.tuneRadioTo("AM", 770); // 3: Call another member function
} // 4. Destroy the object
int main()
{
f();
}
When control flows over the line labeled 1: Create an object, the runtime
system creates a local (auto) object of class Car. The object is called a and can
be accessed from the point where it is created to the } labeled 4: Destroy the
object.
When control flows over the line labeled 2: Call a member function, the
startEngine() member function (a.k.a. method) is called for object a. The
compiler knows that a is of class Car so there is no need to indicate that the
proper startEngine() member function is the one from the Car class. For
example, there could be other classes that also have a startEngine() member
function (Airplane, LawnMower, and so on), but the compiler will never get
confused and call a member function from the wrong class.

Unnecessary complexity — the plague of OO technology.
Complexity, like risk, is a fact of life that can’t be avoided. Some software
systems have to be complex because the business processes they represent are
complex. But unfortunately many intermediate developers try to “make things
better” by adding generalization and flexibility that no one has asked for or will
ever need. The customer wants a cup of tea, and the developers build a system
that can boil the ocean [thanks to John Vlissides for this quip]. The result
is unnecessary complexity, which increases the risk of failure. The intentions
might be good but the result can be deadly.
Here are a few guidelines.
• Don’t solve problems that don’t need to be solved.
• Don’t worry about the future until you’re sure you can survive the present.
39
• Don’t build things for the fun of it.
• The organization’s health is more important than the developer’s desire
to play with the latest whiz-bang tool or technique.
• Don’t add risk without a compelling and measurable benefit to the project.
• Don’t invest in the future if your current project is in trouble.
Avoid the “death by one thousands cut” syndrome by avoiding unnecessary
complexity.

The Software Peter Principle is in operation when unwise developers “improve” and “generalize” the software until they themselves can no longer understand it, then the project slowly dies.
The Software Peter Principle can ruin projects. The insidious thing about the Software Peter Principle is that it’s a silent killer — by the time the symptoms are visible, the problem has spread throughout every line of code in the project.
Foolish managers deal with symptoms rather than prevention, and they think
everything is okay unless there are visible bugs. Yet the problem isn’t bugs, at least initially. The problem is that the project is collapsing under its own weight.
The best way to avoid this problem is to build to the skill level of the maintainers, not of the developers. If the typical maintainer won’t understand the software then it’s simply too complex for the organization to maintain. This means avoiding tricky, sophisticated, subtle, clever techniques unless there is a compelling reason for them. Cleverness is evil; use it only when necessary.
Shown concern for the long-term health of the system being developed.

Whichever one works best for the organization.
We believe in honesty, not advocacy, and the honest answer is that there
is no single answer. What is the organization’s policy regarding languages?
Must there be one and only one official language? What is the skill level of
the staff? Are they gung-ho developers with advanced degrees in computer
science/engineering or people who understand the business and have survival
skills in software? Do they already have OO skills? In which language(s)? What
sort of software development is being done: extending someone else’s framework
or building from scratch for resale? What sort of performance constraints does
the software have? Is it space constrained or speed constrained? If speed, is it
typically bound by I/O, network, or CPU? Regarding libraries and tools, are
there licensing considerations? Are there strategic partnership relationships that
affect the choice of languages? Many of these questions are nontechnical, but
they are the kind of questions that need to be answered the “which language”
issue can be addressed.
Regarding the choice between C++ and Java, java is a simpler language and
thus it is generally easier to use. However C++ is more established and allows
finer control over resources (for example, memory management), and this is required
for some applications. Also, C++ has language features such as destructors

i want to say Global scope(int i = 111;),Local scope (int i = 333;), and function scope (int i = 222;) but now, i\'m confused. I really don\'t understand what is this question asking me. Can somebody help me break it down

To declare a variable you use the syntax "type ;". Here are some variable declaration examples:
1- int x;
2- char letter;
3- float the_float;
It is permissible to declare multiple variables of the same type on the same line; each one should be separated by a comma.
1- int a, b, c, d;
If you were watching closely, you might have seen that declaration of a variable is always followed by a semicolon (note that this is the same procedure used when you call a function).