At the Interview | Top Ten Mistakes Candidates Make

#1 | Practicing on a Computer
If you were training for a serious bike race in the mountains, would you practice only by biking on the streets? I hope not. The air is different. The terrain is different. Yeah, I bet you’d practice in the mountains.
Using a compiler to practice interview questions is like this - and you’ve basically been biking on the streets your entire life. Put away the compiler and get out the old pen and paper. Use a compiler only to verify your solutions.
#2 | Not Rehearsing Behavioral Questions
Many candidates spend all their time prepping for technical questions and overlook the behavioral questions. Guess what? Your interviewer is judging those too! And, not only that - your performance on behavioral questions might bias your interviewer’s perception of your technical performance. Behavioral prep is relatively easy and well-worth your time. Looking over your projects and positions and think of the key stories. Rehearse the stories. See pg 29 for more details.
#3 | Not Doing a Mock Interview
Imagine you’re preparing for a big speech. Your whole school, or company, or whatever will be there. Your future depends on this. And all you do to prepare is read the speech to yourself. Silently. In your head. Crazy, right?
Not doing a mock interview to prepare for your real interview is just like this. If you’re an engineer, you must know other engineers. Grab a buddy and ask him/her to do a mock interview for you. You can even return the favor!
#4 | Trying to Memorize Solutions
Quality beats quantity. Try to struggle through and solve questions yourself; don’t flip directly to the solutions when you get stuck. Memorizing how to solve specific problem isn’t going to help you much in an interview. Real preparation is about learning how to approach new problems.
#5 | Talking Too Much
I can’t tell you how many times I’ve asked candidates a simple question like “what was the hardest bug on Project Pod?”, only to have them ramble on and on about things I don’t understand. Five minutes later, when they finally come up for air, I’ve learned nothing - except that they’re a poor communicator. When asked a question, break your answer into three parts (Situation / Action / Response, Issue 1 / Issue 2 / Issue 3, etc) and speak for just a couple sentences about each. If I want more details, I’ll ask!

Questions, questions, questions

Many aspiring negotiators make the mistake of doing all the talking. We need to ASK, ASK, ASK, until it becomes second nature to ask questions, and listen for the answer. It is written somewhere, ‘Be quick to listen and slow to speak.’ One of my earliest mentors used to say to me, ‘Oliver, you have two ears and one mouth; you need to learn to use them in that proportion.’

Let’s face it, the less you say, the more relevant you are likely to be. Let me ask you a few questions myself. If you are talking, who are you normally talking about? Of course the answer is ‘yourself’. That produces a defensive or bored response in the counterpart. Worse still, you will inevitably be giving away information that they can use to their advantage.

What sort of questions?

If questioning is so vital, what kind of questions should we be asking? We should be asking open-ended questions. Closed questions are questions to which the only answer is ‘Yes’ or ‘No’. They produce no additional information, they close down the conversation, they close down the proper negotiation process too early. Typical closed questions are prefaced with ‘Do you…?’, ‘Could you…?’, ‘Will you…?’

Open-ended questions cannot be answered ‘Yes’ or ‘No’; they always produce a response and always yield information. In training circles they are loosely referred to as W questions. They include What?, Which?, When?, Where?, Why?, Who?, and the odd one out: How? They always generate information and they are key to retaining control at every stage of the negotiation process.

A builder had negotiated a deal with a Baptist church for renovation work valued at £120,000. The deal appeared to be agreed, but the architect simply would not give the builder the start date. The builder was stalled for some weeks and could not get a clear picture from the architect. In a move to get things under way, the MD of the building company approached the church direct and began asking W questions to attempt to discover the nature of the problem. It transpired that the church wanted to carry on meeting in the building while the renovations were going on. They had been told that it would not be possible. The builder simply offered to find alternative accommodation while the work was in hand – offering to pay for it himself. The cost of that was a few hundred pounds but would have the effect of releasing £120,000 of work.

Subsequently, with the goodwill his gesture generated, he was able to work out a method of working that enabled the church to carry on meeting – with some temporary facilities – within their existing premises. The job got under way.

Creating a memory leak with Java

Here's a good way to create a true memory leak (objects inaccessible by running code but still stored in memory) in pure Java:

1. The application creates a long-running thread (or use a thread pool to leak even faster).
2. The thread loads a class via an (optionally custom) ClassLoader.
3. The class allocates a large chunk of memory (e.g. new byte[1000000]), stores a strong reference to it in a static field, and then stores a reference to itself in a ThreadLocal. Allocating the extra memory is optional (leaking the Class instance is enough), but it will make the leak work that much faster.
4. The thread clears all references to the custom class or the ClassLoader it was loaded from.
5. Repeat.

This works because the ThreadLocal keeps a reference to the object, which keeps a reference to its Class, which in turn keeps a reference to its ClassLoader. The ClassLoader, in turn, keeps a reference to all the Classes it has loaded. It gets worse because in many JVM implementations Classes and ClassLoaders are allocated straight into permgen and are never GC'd at all.

A variation on this pattern is why application containers (like Tomcat) can leak memory like sieve if you frequently redeploy applications that happen to use ThreadLocals in any way. (Since the application container uses Threads as described, and each time you redeploy the application a new ClassLoader is used.)

JVM Architecture

When a Java virtual machine runs a program, it needs memory to store many things, including bytecodes and other information it extracts from loaded class files, objects the program instantiates, parameters to methods, return values, local variables, and intermediate results of computations. The Java virtual machine organizes the memory it needs to execute a program into several runtime data areas.

1. The JVM Basic Tutorials, the Method Area

The Java Virtual Machine has a method area that is shared among all Java Virtual Machine threads. The method area is analogous to the storage area for compiled code of a conventional language or analogous to the "text" segment in an operating system process. It stores per-class structures such as the run-time constant pool, field and method data, and the code for methods and constructors, including the special methods (§2.9) used in class and instance initialization and interface initialization.

The method area is created on virtual machine start-up. Although the method area is logically part of the heap, simple implementations may choose not to either garbage collect or compact it. This version of the Java Virtual Machine specification does not mandate the location of the method area or the policies used to manage compiled code. The method area may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger method area becomes unnecessary. The memory for the method area does not need to be contiguous.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the method area, as well as, in the case of a varying-size method area, control over the maximum and minimum method area size.

The following exceptional condition is associated with the method area:

If memory in the method area cannot be made available to satisfy an allocation request, the Java Virtual Machine throws an OutOfMemoryError.

1. The JVM Basic Tutorials, the Heap Area Video

The Java Virtual Machine has a heap that is shared among all Java Virtual Machine threads. The heap is the run-time data area from which memory for all class instances and arrays is allocated.

The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector); objects are never explicitly deallocated. The Java Virtual Machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements. The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous.

A Java Virtual Machine implementation may provide the programmer or the user control over the initial size of the heap, as well as, if the heap can be dynamically expanded or contracted, control over the maximum and minimum heap size.

The following exceptional condition is associated with the heap:

• If a computation requires more heap than can be made available by the automatic storage management system, the Java Virtual Machine throws anOutOfMemoryError.

GDB Tutorials

Zariga.com  Present

What is GDB?

GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.

GDB can do four main kinds of things (plus other things in support of these) to help you catch bugs in the act:

• Start your program, specifying anything that might affect its behavior.
• Make your program stop on specified conditions.
• Examine what has happened, when your program has stopped.
• Change things in your program, so you can experiment with correcting the effects of one bug and go on to learn about another

gdb is in the gnu package on CEC machines. If you don't have this package loaded then type pkgadd gnu at a shell prompt. If you can run g++, then you will be able to run gdb.

gdb can only use debugging symbols that are generated by g++. For Sun CC users, there is the dbx debugger which is very similar to gdb.
gdb is most effective when it is debugging a program that has debugging symbols linked in to it. With g++, this is accomplished using the -g command line argument. For even more information, the -ggdb switch can be used which includes debugging symbols which are specific to gdb. The makefile for this tutorial uses the -ggdb switch


Summary of the info Command

info ...	Information displayed
address sym	Information about where symbol sym is stored. This is either a memory address or a register name.
all-registers	Information about all registers, including floating-point registers.
args	Information about the arguments to the current function (stack frame).
break [bpnum]	Information about breakpoint bpnum if given, or about all breakpoints if not.
breakpoints[bpnum]	Same information as the info break command.
catch	Information on exception handlers active in the current frame.
classes[regexp]	Information about Objective-C classes that matchregexp, or about all classes if regexp is not given.
display	Information about items in the automatic display list.
extensions	Information about the correspondence of filename extensions to source code programming languages.
f [address]	Same information as the info frame command.
files	Information about the current debugging target, including the current executable, core, and symbol files.
float	Information about the floating-point hardware.
frame[address]	With no argument, print information about the current frame. With an address, print information about the frame containing address, but do not make it the current frame.
functions[regexp]	With no argument, print the names and types of all functions. Otherwise, print information about functions whose names match regexp.
handle	The list of all signals and how GDB currently treats them.

Alias	Short for ...	Alias	Short for ...
bt	backtrace	i	info
c	continue	l	list
cont	continue	n	next
d	delete	ni	nexti
dir	directory	p	print
dis	disable	po	print-object
do	down	r	run
e	edit	s	step
f	frame	share	sharedlibrary
fo	forward-search	si	stepi
gcore	generate-core-file	u	until
h	help	where	backtrace

BreakPoints

awatch	Set an expression watchpoint.
break	Set a breakpoint at a line or function.
catch	Set a catchpoint to catch an event.
clear	Clear a given breakpoint.
commands	Specify commands to run when a breakpoint is reached.
condition	Supply a condition to a particular breakpoint.
delete	Delete one or more breakpoints or auto-display expressions.
disable	Disable one or more breakpoints.
enable	Enable one or more breakpoints.
hbreak	Set a hardware-assisted breakpoint.
ignore	Set the ignore-count of a particular breakpoint.
rbreak	Set a breakpoint for all functions matching a regular expression.
rwatch	Set a read watchpoint for an expression.
tbreak	Set a temporary breakpoint.
tcatch	Set a temporary catchpoint.
thbreak	Set a temporary hardware-assisted breakpoint.
watch	Set an expression watchpoint.

Data Analysis

call	Call a function in the program.
delete display	Cancel one or more expressions that have been set to display when the program stops.
delete mem	Delete a memory region.
disable display	Disable one or more expressions that have been set to display when the program stops.
disable mem	Disable a memory region.
disassemble	Disassemble a section of memory.
display	Print the value of an expression each time the program stops.
enable display	Enable one or more expressions that have been set to display when the program stops.
enable mem	Enable a memory region.
inspect	Same as print.
mem	Define attributes for a memory region.
output	Similar to print, but doesn't save the value in history and doesn't print a newline. For scripting.
print	Print the value of an expression.
print-object	Cause an Objective C object to print information about itself.
printf	Print values such as the printf command.
ptype	Print the definition of a given type.
set	Evaluate an expression and save the result in a program variable.

GDB Tutorials # 1

So you now have an executable file (in this case main) and you want to debug it. First you must launch the debugger. The debugger is called gdb and you can tell it which file to debug at the shell prompt. So to debug main we want to type gdb main. Here is what it looks like when I run it:

GDB Tutorials # 2

Inspecting crashes

So already we can see the that the program was at line 28 of main.cc, that this points to 0, and we can see the line of code that was executed. But we also want to know who called this method and we would like to be able to examine values in the calling methods. So at the gdb prompt, we type backtrace which gives me the following output: