Moving in IT/Programming

[BusError]

Just to help the OP make a decision, I've decided to post a couple of my personal favourite programming sniped, fished out over the years from my Esteemed Colleagues output. This is of my personal collection of course, and I'm quite selective as to the 'scope', generally.

My personal grand favourite is this gentleman, who is actually Dr CS gentleman. He made MANY other of the same grade, but this one has an intrinsic beauty that is something to behold.

// Compute 2^n //
/////////////////

inline Int_t TwoToThePower ( HowMany_t n )
{
  ASSERT(n>=0) ;
  ASSERT(n<30) ;
  Int_t k = 1 ;
  while ( n != 0 )
  {
    k += k ;
    n-- ;
  }
  return k ;
}

And this one in it's simplicity more or less sums up the level of programming skills that is available on the market today.

memset(&serv_addr, '0', sizeof(serv_addr));

These guys were hired, well paid, and are still on the market. I say, it can't be hard to be better

 

[Tuppy_Glossop]

Keep Kernighan and Ritchie close at all times

 

[sniffy]

I'd be inclined to argue the opposite to be honest, anyone can learn to code, but if you're a social retard who can't communicate with people, that's not really something that can be improved upon easily. Not so much an issue in a big company where you get given your spec and go off to your cubicle to work on it in isolation, far more of an issue in a small company where everyone has to work together more closely

I'm not convinced anyone can learn to code. I saw it at university and I see it in the workplace. There's also a huge cost for a company to turn someone with little technical knowledge into someone who is useful. It's not only their wage but the wage of other developers. Why bother when you could hire someone with both social skills and technical knowledge? I see where you're coming from, I just think both are important from the offset.

 

[Lightnix]

I personally rarely bother that much on the pure technical; what I ask is more 'open ended' questions that shows pretty quickly if someone knows what they are doing. It's actually fairly easy to do tech questionnaires, that will not prove you can program your way out of a paper bag.

Something like "can you tell me the differences between a cooperative and preemptive scheduler, and what would you consider be the advantages and disadvantages of both"

That sorts out the lamers very, very quickly. Some other, even simpler questions I have turned out to have and even lower response rate.

I have to hold my hands up because, despite having an overly inflated opinion of myself as a student programmer, I don't think they covered that on our course. We did scheduling stuff like round robin, priority queues, multilevel feedback queues and the like. I did google cooperative scheduling, though. It strikes me as unsurprising that a concept that hasn't been employed in an operating system for over a decade might seem out of date and get cut in the face of an ever expanding breadth of knowledge in the field. Or I might have missed that lecture, but learning about it wasn't exactly taxing so I won't worry too much.

Take, for instance, this article on Linux's Completely Fair Scheduler:

http://en.wikipedia.org/wiki/Completely_Fair_Scheduler

Nowhere does it seem to categorise it as preemptive or cooperative (despite being an example of preemptive scheduling). So you can potentially go about reading about modern scheduling systems in much more depth without coming across those concepts.

Moreover, being a humble current industrial placement student, it seems as though testing people based on specific domain knowledge is disingenuous. What you should want to know is if the person can take new information and apply that effectively.

 

[BusError]

... and what do you think 'coroutines' are, and why they are still around (despite having 'not been employed in an OS for over a decade') ?

 

[Lightnix]

First, I'd like to add that I can appreciate that you might be in some situation where you want the person to write their own scheduling system.

I'm not going to lie, I was reading some stuff about coroutines a little while back although my recollection is hazy at best. Without googling:

It has something to do with the problem of when one function calling another is ambiguous. It solves that somehow. Knuth wrote about them in the art of programming (which I should probably go back over at some point if I'm totally honest). Thinking of the terminology 'routine' - thinking of assembly. So I imagine it's some piece of code which is shared between some routines which is not called as a function but rather jumped to. I was reading an article about implementing python style generators in C++ a little while back (which is where most of this speculation is coming from) - and that just used macros to insert code directly using some rather unfortunate looking syntax mangling (because the point was to make it appear like a function which returned one value at a time rather than returning, for instance, a vector)

Based on that, wouldn't be surprised if it was employed in embedded systems which don't have an OS of which to speak (which would at least make your comment somewhat amusing. ). That, or if I'm taking potshots, somehow it applies to concurrent systems.

Yeah, that was honestly quite rambly by my own standards of these things.

 

[jsmoke]

The world of professional software development is full of a lot of snobbery, some think everyone has to be an expert/extreme geek from the get go.

Some things that will get you a lot further than you think...personality, social skills, business sense etc. Depends on the company/who is involved in the hiring process of course.

I do understand this to a fair degree, I imagine it's highly competitive, fairly arrogant and full of people trying to get one over on another through their intellectual knowledge/arrogance. Bit like Stock Brokers I would have thought. But there must be plenty of decent people.

Actually we'd decided to make an offer on a guy I interviewed yesterday. I did about 25 phones interviews, 2 in-person interviews and we picked one guy.

It is surprising how few people can even pass a phone interview. Some of them have shinning CVs full of buzzwords, some of them even have positions on their CV that are rather amazing sometime, and can't even answer simple questions about generic things. And even the guys we interviewed in house are not 'fantastic' either; we decided t hire one because 1) we need someone and 2) we hope he will shape up, his "shape-upability" seems better than the other guy.

Do you have any examples questions, I know there are loads on the net, for example I've read a bit of this book,

Interview Questions

some of it is quite funny, also this is quite good,

steveyegge2


These are not just specific programming questions somewhat more of a personality test combo.

I've noticed this book Algorithms For Interviews, had a quick look and this is where I am lacking and it's the most fundamental CS topic there is......

 

[drakioned]

The world of professional software development is full of a lot of snobbery, some think everyone has to be an expert/extreme geek from the get go.

Some things that will get you a lot further than you think...personality, social skills, business sense etc. Depends on the company/who is involved in the hiring process of course.

and then:

I personally rarely bother that much on the pure technical; what I ask is more 'open ended' questions that shows pretty quickly if someone knows what they are doing. It's actually fairly easy to do tech questionnaires, that will not prove you can program your way out of a paper bag.

Something like "can you tell me the differences between a cooperative and preemptive scheduler, and what would you consider be the advantages and disadvantages of both"

That sorts out the lamers very, very quickly. Some other, even simpler questions I have turned out to have and even lower response rate.

*facepalm*

As an aside, I had to look this up, and having done so, I can't see how this question is relevant in the majority of programming roles.

 

[jonneymendoza]

Those things wont get you that far.
We send out a technical test and only success at that will we arrange a Skype interview with more technical questions. Only once that is passed will we fly someone over for the interview and do more technical and personality tests.


Regardless of someones personality if they don't pass the technical tests then it is likely no one will even speak to the candidate.

well i got got turned down because i wasnt that awsome in my social skills but blew them away technically

 

[D.P.]

I personally rarely bother that much on the pure technical; what I ask is more 'open ended' questions that shows pretty quickly if someone knows what they are doing. It's actually fairly easy to do tech questionnaires, that will not prove you can program your way out of a paper bag.

Something like "can you tell me the differences between a cooperative and preemptive scheduler, and what would you consider be the advantages and disadvantages of both"

That sorts out the lamers very, very quickly. Some other, even simpler questions I have turned out to have and even lower response rate.

That is asking a very specific question about knowledge, which is rarely that useful to test.

We strive to test peoples intelligence, speed, ability to think of novel solutions under pressure, problem solving, ability to learn new skills/methods and experience. we do this in a language agnostic way, but if they claim c++ experience we will test some of that, get them to understand some fairly basic code and point out any errors.


A typical question might be:
L = [[A,B,C], [D,E], [F], [G,H], [I,J,K]]

Given the list of Lists L, write me some postcode that will generate all possible permutations that include exactly 1 element from each sub list, e.g
A,D,F,G,I is one permutation.

Good programmers will quickly write up some recursive psudocode. bad programmers will struggle to get anything and will be doing some horrible nested iteration.

EDIT:And we typically dont get if they get a working solution, only we want to understand their thought process. Do they write jump up some nonsense on the whiteboard that doesn't work, and then spend 20 minutes trying to make it work getting all flustered, or do they think for a few minutes, take a pause, think again, and right up a good solution in 5 minutes, or do they start with the former but after 5 minutes step back from the mess, re-think and come up with a better solution.

it amazing watching people get angry because they can't solve a simple problem. There is another problem we have which is much harder, we've had people start argument with us, claim that is was not computable or state that is not fair to ask such a hard question at an interview. The whole point is to ask a hard question and see how they cope and their approach, not whether they can solve it - complaining at the interviewer doesn't help! maybe only 10%-20% solve the harder question but some of the rest go home at night and think about it coming up with a solution - if they email us the solution we will be mcuh more liekly to hire them because we know the problem picked their interest and they were excited to solve it.

 

[D.P.]

well i got got turned down because i wasnt that awsome in my social skills but blew them away technically

I never said that bad social skills wont have a negative effect - they will, but if the technical stuff is not up to par no one will likely ever find out of you are an axe-murderer or prince charming.

we've rejected people because they wouldn't fit in despite a flawless technical record, but someone who fails are programming test will get a short email saying they were technically not good enough long before they even spoke to a anyone.

 

[jonneymendoza]

I never said that bad social skills wont have a negative effect - they will, but if the technical stuff is not up to par no one will likely ever find out of you are an axe-murderer or prince charming.

we've rejected people because they wouldn't fit in despite a flawless technical record, but someone who fails are programming test will get a short email saying they were technically not good enough long before they even spoke to a anyone.

yea thats what i mean mate. tech is more important .

Social skills is hard to identify from a single interview because that person could be a bit shy and nervous at the time.

I have iinterviewed many that appeared shy in interview but once settled they are fine and get along well with ohers.

Thats something u cant really identify from a single interview IMO

 

[BusError]

and then:



*facepalm*

As an aside, I had to look this up, and having done so, I can't see how this question is relevant in the majority of programming roles.

Well I do; I only recruit people who know how a computer works, how an operating system might or might not work, and other various 'boring system' things that are "totally irrelevant" for a programming role...

Otherwise, you can end up with capable programmers who, for example, think walking a 2D table by columns is the same as walking it by rows.

 

[Lightnix]

Well I do; I only recruit people who know how a computer works, how an operating system might or might not work, and other various 'boring system' things that are "totally irrelevant" for a programming role...

Otherwise, you can end up with capable programmers who, for example, think walking a 2D table by columns is the same as walking it by rows.

I think the point isn't necessarily that good systems or OS knowledge isn't important - it's that you can still have a good working knowledge of those things (by many criteria) without having come across those bits of specific terminology. By and large this is because the field of computing in general has grown really, really huge and there are a lot of different takes on the same problems depending on which subfield you're dealing with.* Take for instance the example of coroutines asked me earlier - yep, definitely was a hole in my knowledge. I'm glad you brought it up, so I probably won't forget now. I wouldn't even necessarily consider it boring, just not something which is at the forefront of discussion of scheduling, at least insofar as my limited experience with the subject goes.

In regards to coroutines: What really didn't click to me when I was rushing that post before going to bed (probably higher pressure than an actual interview ) was that they're closely related to the idea of generators in Python (generators in that context being a restricted form of coroutine), and had I made that connection I could've talked your ear off about their relevance with regards to iterators and lazy evaluation with far more confidence than my previous, ramblomatic post.

*In general this is a point I'd quite like to vent about. My CS course is kind of an old one that has tried to modernise itself to incorporate new stuff over the years. As such it has kind of ballooned to try to encompass both CS and software engineering, but doesn't make that much of a dinstiction between the two fields. Really, in my opinion, those things should be split in two (in the same way that physics and mecheng/eleceng are). It also doesn't provide a lot of choice in the modules you get until third year so you're sort of stuck with it if you didn't realise that was how it would be when you applied.

You get people who seem to advocate, for instance, that recursion is a "better way to solve these types of problems" (for instance that permutation list elements problem - because they obviously have a lot of mathematical niceties, and some problems appear more elegant when witten in that style), and people who think that recursion in production code is dumb because you're opening yourself up to the possibility of a stack overflow (and besides, you can always emulate that behaviour with an explicit dynamic stack structure rather than relying on the call stack if you really need to). Neither of them are really 'wrong' as such - it's just one approach is usually better in one field than in the other.

 

[Lightnix]

edit: welp. Apparently I don't know how to use forums. I should come with a warning sign.

 

[BusError]

I to be fair I was hiring someone "senior", so thats the sort of background knowledge you expect to have been picked up within the last 20 years.
Mind you, YOU have the right approach too, you looked it up, drew the parallel with other stuff you know, etc. I definitely dont want to sound up my arse, but, heck, well done

And what I want to hear about cooperative vs premptive is "they both have uses" -- the system preemptive scheduler allows you to have completely heterogenous tasks sharing resources at the price of some non negligible overhead, and with a strong possibility of introducing bottlenecks (and also what I call 'waves' when you have multiple threads trying to hoard one lock)
The cooperative can be dangerous as one task can indeed hoard the whole CPU, but on the positive side, if you scope it well, you will remove the need for critical sections on shared resources, and thus make a subsystem that is a lot more fluid. Without having to maintain horrible (notice they ALWAYS become horrible ) state machines.

 

[robotSocks]

There is far more to development than this guff ^

I mean do people really care about this any more? The majority of devs in my area have seen the light and moved into enterprise & cloud

Stuff like all that low level OS stuff doesn't matter a dime when you're working with autoscaling disposable VM nodes

 

[Pants]

I'd be far more likely to hire someone with intelligence and a hunger for improvement than somebody who could solve a really specific problem than nobody cares about.

jsmoke: do you have any more information about the interview? Is it competency based, or something else? We might be able to give you better advice.

 

[Lightnix]

The low level guff can still become your problem if you're at all worried about performance. The compiler/recompiler/interpreter can't optimise everything away because at the end of the day it's still limited by computability and scope. There are cases that you might have some O(n^3) or more complex operation with some branching to do on a fairly large array (or whatever your choice of abstraction for that is) - and it can turn out that, on a modern x86 processor, you can get some fairly sizeable speed increases by sorting your data before hand. That's totally counter-intuitive (you're doing "more work"!) without knowing something about the processor architecture, specifically branch prediction, which is about as low level as it gets in software.

 

[jon86]

...
I mean do people really care about this any more? The majority of devs in my area have seen the light and moved into enterprise & cloud

Stuff like all that low level OS stuff doesn't matter a dime when you're working with autoscaling disposable VM nodes

I work with a private enterprise PaaS most days and understand the beauty of having autoscaling and disposable VM nodes with automatic load balancers, etc, but I would disagree that lower level stuff isn't important. I watched some interesting talks from some Whatsapp developers recently who were explaining that they had to fix some very specific bottlenecks in certain parts of the Erlang stack (which wasn't because of their code itself) in order to have a successful, scalable worldwide server infrastructure. IIRC, it is run on Amazon AWS, which is undoubtedly one of, if not the, pinnacle of cloud platforms.

You often need people who understand the intricacies of low level stuff in order to have a diversified team.