Very few candidates thought about qsort() (or Array.sort()), and for those we noted "good thinking" and then asked for a version which does not use a predefined function.
We asked that question only if the candidate did not have previously demonstrated, through his answers to questions, that he did not know what a computer was.
About 30% of candidates seemed to know what a computer is.
Then only 25% or so of these people could produce, in 45 minutes, a ten-line program which compiles.
I was actually impressed when I first encountered a candidate who knew no programming language at all, but was planning on following a 10-hours course on Java before the assumed date of hiring.
I've used FizzBuzz fairly extensively in interviewing. It seems to be fairly effective. Despite the fact that it's a fairly well known interview tool, most fail it miserably. Many, in fact, can't even really get started solving it.
@ThomasPornin I see. I'm not sure how well i would do on your tests. But if i had access to a compiler I'm sure i would at least vomit some working code..
@DavidFreitag For such a test, we are interested in the ability of the candidate to write code which works, and also in his "coding style habits". That's the most revealing test: by seeing whether his indentation is systematic or not, we know how much reliable he is.
Our computers weren't setup properly, so if you wrote something in notepad and opened up cmd, it would bitch and scream at you for not having javac installed properly
@Simon You would have to have multiple instances of mIRC running, but i don't know. As many as you want, or rather as many as your ram can support i think.
@Simon You could first try to implement a few hash functions, and try to make them run fast. This is a good programming exercise and you will learn a lot.
A few years ago, I tried running SHA-1 on my CPU and on my GPU
A "normal" implementation could achieve about 20 millions SHA-1 per second (with four cores) but I could make one which achieved 48 millions per second with SSE2.
@ThomasPornin I assume you were on your GPU running many SHA-1 simultaneously (since the GPU essentially provides lots of parallelism) rather than updating one hash "context"? If I understand it correctly the speedup is by the number of concurrent hashing operations you can do, so calculate the hashes of multiple passwords, rather than more quickly compute a single hash (although that could be the case if the clock speed is quicker/you get better throughput using 128-bit registers like xmm1 etc)?
@AntonyVennard Yes, the context was password cracking.
In fact, the GPU has 128 "cores" but each core runs a lot of "threads" because though it can execute one instruction per core and per cycle, it also has a 22-cycle latency
so, to get the full speed of the GPU, you have to run 22·128 = 2816 SHA-1 instances in parallel (at least)
in practice, there are rounding issues in the allocation algorithms, so make it 4096 instances
@ThomasPornin I remember reading about this when looking at CUDA a few years back. CUDA gives you the ability to ask for a specific "kernel" of code to be loaded (not an OS kernel, just a function) and some fancy matrix of numbers which represent the specific instances, then it loads a copy of the kernel into each thread and off you go.
I don't remember the exact details and don't even have CUDA installed any more, but it was interesting :)
On the CPU I only have four cores, so 16 parallel instances with SSE2 registers (128-bit register, can compute the same operation on all four 32-bit words), but I can do two operations per cycle, and the clock rate is higher.
in Israel, approx. 60% (little bit less or quite a bit more, depending on how you count it (and who you ask...)) of total IT jobs (not just consulting) is government related.
@ScottPack I did a beer mile Monday night. The mile was the easy part. The horrible horrible beer I was expected to drink took longer to deal with than the running.