views:

198

answers:

3

I understand it should cover threading primitives (mutex, semaphore, condition variables etc.) plus design patterns (such as those specified in POSA2). But what's more? Every project has its own multithreading scenarios and one may have not dealt with those that the job is expecting?. So how does one build their knowledge and prove that they have the ability?

+3  A: 

I would expect the candidate has knowledge and experience of the issues that arise when multiple threads access shared resources. What problems can be caused by concurrent access and what problems the solutions (such as locking etc) present.

At the very least understanding of how to write and read asych code on the platform of choice.

After this it will be understanding the specifics if the platform - e.g. such how to access the primary window in windows system while many things needs up the display at the same time.

Fundamentally is about understanding what trade-offs are needed and when.

Preet Sangha
+6  A: 

Regardless of specifics solid, detailed and very deep knowledge is required. One should understand how the bottlenecks form, how to deal with scalability problems, how to diagnose cases where synchronization is required but is erroneously omitted.

If for example you had a job experience with multithreading and I ran an interview to assess you I'd ask detailed questions on typical scenarios that arise when developing multithreaded programs. I wouldn't expect you knew many technologies or some specific technology, but I'd expect you to have mastered the technology you claim you're familiar with in great detail and to understand which fundamental problems it solves and how.

sharptooth
As I understand from your answer, it is about ability to identify issues given a piece of code and more so on the platform of choice. But i am not able to digest that the interview window provides ample opportunity to go beyond trivial or obvious pieces of code. I think any non-trivial piece of code would be sufficiently integrated and will be difficult to understand in a standalone fashion.
R2D2
@Vaibhav Khattri: Believe me or not the key problem is to identify if you at least understand what problems are there - http://www.codinghorror.com/blog/2010/02/the-nonprogramming-programmer/Even quite simple detailed questions can be very good to assess the interviewee's competence.
sharptooth
+2  A: 

May I present a different view. I think you should understand the basics, but really never give up on a job based on a flyer description. I have not met a programming concept that could not be figured out in half a day. So, basically, read a tutorial before the interview, do not try to misrepresent your actual experience with threading, but make sure they know the things you had more hands on experience, and see if there is a mutual interest in you working for the company. They may like you even if you know nothing about threading if they are confident that you can pick it up at full speed.

Nikola Jevtic
I have met many things that need more than half day to figure out in programming.
David Rodríguez - dribeas
I completely agree with your comment that any programming concept could be understood in a short period of time, given one has a sufficiently developed logical thinking ability. And that is why I asked this question.How do you leave the impression in an interview that you are first class solution provider and have the potential to learn/master any new technology? There could always be a question that one may need more time to solve and the interviewer is not interested in loud thinking.
R2D2
You have 12 hours to figure out whether P=NP ;-) There's a difference between "figuring out" a concept in the sense of knowing what it's about, and "figuring out" a concept in the sense of being able to confidently and expertly apply it to give correct results.
Steve Jessop
Lemme see... Either P=0 or N=1. Otherwise no way. There, 10 seconds, with confidence.Anyway, its like with anything else in life, it depends. Only, among the many variables, the weakest link in my experience are the requirements in the job listing. Most of the time they are written by different people than those doing the hiring. Other times they are a collection of good technologies, but far from requirements to do the job. Eventually hiring committee reconciles the candidates with the job, and not with the flyer text.
Nikola Jevtic