Someone said 90% of programmers cannot solve a binary search.
So for a guy who claimed he has in depth understanding on multi-threading technology, what is the basic but ideal question to ask?
It can be either C++ or Java.
Someone said 90% of programmers cannot solve a binary search.
So for a guy who claimed he has in depth understanding on multi-threading technology, what is the basic but ideal question to ask?
It can be either C++ or Java.
I bet, a question to show a simple practical example of thread interference will weed out 80% of your specialists. Something like this.
But basically, you can ask about any common multithreading problem, like deadlock or race condition.
I would be careful with going into specific questions, though (e.g., how exactly one uses semaphores in C or atomic classes in Java), as I'm not sure that having whole API in your memory shows your understanding of underlying concepts.
In Java, ask them what the difference between public synchronized void foo()
is and public static synchronized void foo()
in terms of locks acquired and what happens in differenct scenarios.
Also, see if they know what benefits the new lock objects in Java provide and also what good things like AtomicInteger are. You should basically ask anything from Java Concurrency in Practice if they claim to have an in depth understanding.
I think you could ask the candidate to describe a standard race condition in a program, and how he would solve it.
You could also describe a basic situation hinting at a deadlock (use multiple threads trying to create/write into a file failing some of the time) and have him describe reasons for why that could be happening.
That's for basics, complicated stuff could be sharding problems, network on udp with threads blocking for response, etc...
A few that quickly came to mind:
For Java:
ans: lock objects based on some unique property. eg:
if (a.id() < b.id()) {
synchronize(a) {
synchronize(b) {
x();
}
}
} else {
synchronize(b) {
synchronize(a) {
x();
}
}
}
C/C++:
General:
If it was me, I'd ask him to explain what "unsafe publishing" meant, or why the double-checked locking idiom is broken in Java. These should be common knowledge to anyone with "in depth experience" in Java concurrent programming.
(The answers to both these questions are in "Java Concurrency in Practice" by Brian Goetz et al. This is required reading for any Java software engineer, IMO.)
One that I've been asked: implement a producer-consumer queue.
It covers both the proper use of synchronization/mutexes in your language of choice, as well as the likely bug of retaining those mutexes for longer than your want.
Of course, you have to understand how to write one yourself for this to be a valid question.
Define some basic multi-threaded primatives.
Do this so they are generic and not platform specific.
Then ask hom to write a higher level multi-threadec construct.
Example:
class Lock
{
void lock(); // Thread safe acquisition of lock.
// Same thread may lock multiple times.
// Each call to lock() requires a call to unlock()
void unlock();
};
class ConditionVariable
{
wait(Lock& lock); // Calling thread is suspended and added to wait queue.
// Lock is released.
signal(); // Releases one thread in the wait queue.
// This means that a thread that has previously called wait()
// will be un-suspended and allowed to exit the wait() method.
// Note: The thread will have re-quired the lock before exiting wait()
};
Describe what you know about locks and condition variables and comment on the above generic descriptions.
Build an exception safe lock.
After he has finished get him/her to explain how it works and why it is exception safe.
Build an exception safe semaphore
After he has finished get him/her to explain how it works and why it is exception safe.
Build a thread pool.
After he has finished get him/her to explain how it works. Get them to show you several uses cases and explain how it would be used.
Explain a real world problem that you had with threads last year.
Get them to make suggestions about the problem (see if he gives you any new ideas) :-)
People who think software development skills and experience can be measured in terms of mundane tasks such as sorting, searching, etc are simply clueless.
If/when a member in my team needs to implement some low level algorithm that's already been solved and documented profoundly in the literature, I urge him to pick his data structures book and double check his implementation even if he claims he knows it by heart. Why take the risk? Understanding business requirements, communication skills, being a team player, having solid education and experience, projects completed and shipped, making best use of tools... these matter the most for software development. I don't care how fast he can type from memory.
Understanding multi-threading without any experience is nonsense. Make sure he can show real multi-threaded work that's in production and does not deadlock and makes efficient use of system resources.
What is Amdahl's Law?
Anyone who claims to be expert in multi-threading must be aware of Amdahl's Law.
Design a read-write lock that allows multiple readers to read the resource but allows only a single writer to modify the resource. A writer cannot modify resource when one or more readers are accessing the resource and vice-versa. How do you provide fairness to writers when large number of readers exist compared to number of writers?