>>> Alternatively, if you have a good set of people already in charge, 
>>> interviewing and making hiring decisions, you are not going to employ 
>>> any BS managers (or programmers) in the first place.
>>
>> I haven't seen that happen yet, but I live in hope.
> 
> Funny, the companies I've worked at, plus the customers I've dealt with 
> all seem to work this way.  I guess the ones that are rubbish don't get 
> much business, or if they do nobody comes back!

Apparently I'm applying to the wrong people...

(Actually, that's not true. I'm not applying to *anybody*. :-( But 
that's another story.)

>> Like I said, I think the difference is that in something abtract like 
>> programming, it's easier to pretend that you know what you're doing. 
>> If somebody asks you to build a wall and you can't, it's pretty 
>> obvious. ;-)
> 
> Personally I think it's pretty obvious if someone asks you to write a 
> program to show the first 1000 prime numbers, and you can't.  Even a 
> non-programmer would recognise that it wasn't working.

Sure, you'd think. But if you try to run it and it fails, you can spout 
some gibberish about "oh, it's a system incompatibility" or "yeah, it's 
a known bug in the new GCC release" or "ah yes, I'm used to working with 
RedHat. Under SuSE there's a known glitch with glibc that can sometimes 
make this happen" or any number of other BS excuses.

And, if the person doing the interviewing is some PHB, they'll sit there 
and be like "wow, this guy really knows is stuff!" (And they'll also 
completely ignore the tech dude sitting next to them going "uh, sir, 
this guy is talking utter crap!")

>> Ooo, that's harsh, man! Some of those are wicked-hard...
> 
> Yeh I'm just getting back in to doing some more of them.  Funny how just 
> 6 or 12 months later you come back and some that seemed wicked hard are 
> suddenly easy!

It's all about using the right abstractions. ;-) Some of the hardest 
programs of science and mathematics turn out to actually be trivial to 
solve once you already know how to solve it.

>> I'm trying to think of a language you could actually throw at me that 
>> I don't know, but then I realised it's actually not hard: C, Perl, 
>> Python, PHP, Bash, Ruby, VB, C#, F#, Erlang, any of those would fit 
>> the bill. o_O
> 
> I guess it also depends on what sort of job you want the person to do.  
> Do you want them to be a C++ code-monkey for their entire career at your 
> company, or are you looking for someone to do a bit more.  This will 
> determine whether you simply test their C++ skills or find some other 
> way to test them with unfamiliar languages and problems.

And that of course depends on what your company does. If you have a 
deployed application with 82 MLOC written in C++ and you just want 
somebody to maintain it, you'd better hope they know their C++. If on 
the other hand you want somebody to throw together a few housekeeping 
scripts, flexibility is probably more important.

And if you want somebody to design and build mathematical models, what 
programming languages they know is going to be utterly irrelevant - but 
you'd better hope to God they have a good grasp of algebra!

Post a reply to this message

Neeum Zawan <fee### [at] festercom> wrote:
> primes = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67,
71, 73, 79, 83, 89, 91, 97]
> for prime in prime:
>     print prime

  Way to overcomplicate a simple problem. Why not simply:

print 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73,
79, 83, 89, 91, 97

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> find :: (Ord y) => (x -> y) -> y -> IArray x -> (Int,Int) -> Maybe x
> find field target array (base,size)
>    | size <  0 = error "invalid subrange size"
>    | size == 0 = Nothing
>    | size == 1 = if field (array ! base) == target then Just (array ! 
> base) else Nothing
>    | otherwise =
>      let
>        size2 = size `div` 2
>        base2 = base + size2
>      in
>        case compare (field (array ! base2)) target of
>          EQ -> Just (array ! base2)
>          GT -> find field target array (base, size2)
>          LT -> find field target array (base + size2, size - size2)

  Btw, "binary search" all in itself is an ambiguous concept, as it may mean
one of several things depending on the specification:

  1) The algorithm tells whether the element exists in the array or not
(in other words, the return value is a boolean).

  2) The algorithm returns either the found element itself (if it is in the
array) or an index/reference to the element. If there are many elements which
compare equal, it returns one of them.

  3) Like the previous, but if there are many elements which compare equal,
it returns the first one, or the index/reference to the first one.

  Why the difference between 2) and 3) is relevant may not be immediately
obvious, but there are many cases where it is. For example, while the elements
may compare equal, they might have ancillary data that is different (iow.
each element is a key/value pair, where the key is used for the ordering).
Thus it makes a difference which element is returned.

  Also, if an index/reference is returned, it can make a significant
difference whether it's pointing to the first element in a series of equal
elements, or a random element among them. In many algorithms it's important
to get the first element.

  Changing the algorithm so that it always returns an index to the first
element of a range of equal elements (if they are what is being searched)
doesn't change the algorithm much, and it will still be O(log n).

  Sometimes you want the last element in the range of equal values instead,
or even an index to the one-past the last. One obvious use for this is if
instead of wanting just one of the equal elements, you want to know the
whole range. This is often useful.

  So let's see if you can modify the algorithm to conform to the spec:

  "A function which takes an array of sorted elements and a value, and
which returns an index to the first element in the array which is not
smaller than the value, or to the end of the array if the value is larger
than any of the array elements, in O(log n)."

  The algorithm is pretty much the same as the basic "naive" algorithm.
It just requires a tiny bit of fine-tuning.

  And just a slightly more complicated:

  "A function which takes an array of sorted elements and a value, and
which returns an index pair. The first index points to the first element
in the array which is not smaller than the value. The second index points
to the first element in the array which is greater than the value. Naturally
If the value is greater than all the array elements, they both will point
to the end of the array. And naturally all this in O(log n)."

  As stated, getting the range of equal values is sometimes very useful,
which is why it's important to know how to do this.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> writes:

> Neeum Zawan <fee### [at] festercom> wrote:
>> primes = [2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67,
71, 73, 79, 83, 89, 91, 97]
>> for prime in prime:
>>     print prime
>
>   Way to overcomplicate a simple problem. Why not simply:
>
> print 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71,
73, 79, 83, 89, 91, 97

Because I wanted one prime per line.

(Whew! Glad no one pointed out that my code doesn't work!)

Post a reply to this message