Write Some ****ing Code

[loinburger]

Got a final interview tomorrow, company would be paying me around 10-15% more than I'm currently making (depending on how the interview + post-interview negotiations go). Two options if I get the job:

1. Accept the job, quit my current job
2. Ask my now-current boss for a friggin huge pay raise, like 30-40%

Ordinarily I'd go with (2) because worst case is the CTO says no and I go with (1), however the problem with (2) is that even if I get a friggin huge pay raise on paper there's no guarantee that I'll actually get paid

[Ben Kenobi]

Loin 1.4x 0 = 0.

He can promise you the sun moon and stars, but it counts for diddly if he doesn't pay.

[Hauldren Collider]

Got a final interview tomorrow, company would be paying me around 10-15% more than I'm currently making (depending on how the interview + post-interview negotiations go). Two options if I get the job:

1. Accept the job, quit my current job
2. Ask my now-current boss for a friggin huge pay raise, like 30-40%

Ordinarily I'd go with (2) because worst case is the CTO says no and I go with (1), however the problem with (2) is that even if I get a friggin huge pay raise on paper there's no guarantee that I'll actually get paid

Not that my opinion matters, but I 100% agree with this decision. This company can't last long. They've already entered a death spiral.

[loinburger]

Yeah, if I went with (2) then I'd need to be paid in advance

[Sava]

My brother + sister-in-law + nieces + parents are all in Boise, and I don't like wearing pants

family
not wearing pants

[Hauldren Collider]

I just wrote a while loop in OCaml. What hath I wrought

let _ = while !changed do
        changed := false;
        map := blocks labels !map;
done in

My compiler also has a for loop hanging around somewhere. And some object-oriented code. And an imperative/stateful graph data structure

[N35t0r]

family
not wearing pants

Family not wearing pants

[H Tower]

Got a final interview tomorrow, company would be paying me around 10-15% more than I'm currently making (depending on how the interview + post-interview negotiations go). Two options if I get the job:

1. Accept the job, quit my current job
2. Ask my now-current boss for a friggin huge pay raise, like 30-40%

Ordinarily I'd go with (2) because worst case is the CTO says no and I go with (1), however the problem with (2) is that even if I get a friggin huge pay raise on paper there's no guarantee that I'll actually get paid

If you work remotely, just leave the old company laptop logged in, and sit on instant messenger, but don't do anything. With the level of insanity going on, they probably wouldn't notice for a week.

[Elok]

A friend of mine asked the following on FB:

I'm thinking of learning a programming language for the purpose of making myself even more unlikable. Of course, due to the proliferation of smartphones and the incipient brain tumors which follow, I've heard the praises of Java sung across the universe, but I want to make a personal appeal on the misbegotten troglodytes that are my friends for advice.

One of his other friends suggested Haskell. I seconded, because this man is a Medieval German scholar and does not require anything genuinely useful, plus he's predisposed to yak on about beautiful grammar structures. Are there other opinions here?

[onodera]

A friend of mine asked the following on FB:

One of his other friends suggested Haskell. I seconded, because this man is a Medieval German scholar and does not require anything genuinely useful, plus he's predisposed to yak on about beautiful grammar structures. Are there other opinions here?

Common Lisp, of course.

[loinburger]

Had a phone interview with the client of one of the companies I'm interviewing with - he asked me to implement a wait-free* queue off the top of my head, which is non-trivial (this would be sort of like asking somebody to solve differential equations off the top of their head). I gave him a lock-free* implementation and said that I didn't know how to make a wait-free implementation (every wait-free algorithm I've ever implemented, and there haven't been many, has relied on my already having a wait-free queue available, e.g. a ConcurrentLinkedQueue), but it's not likely that very many other people would have been able to provide an implementation off the top of their head so whatever.

* The "classical" way to implement a concurrent data structure, e.g. a queue that multiple threads can add to / remove from at the same time, is to use locks, e.g. a thread locks the queue and then either adds an item to it or removes an item from it. Locks are problematic because they're inefficient, and can also lead to deadlock (thread1 wants to lock resource1 and then resource 2, thread2 wants to lock resource2 and then resource1; thread1 locks resource1, thread2 locks resource2, and now the two threads are stuck forever because they're waiting on locks that will never be released). A lock-free data structure doesn't use locks, instead using some sort of atomic compare-and-swap: read the memory location into a local copy (e.g. in a register), modify the copy and store it in a different register, and then execute an atomic compare-and-swap that compares the current value of the memory location to the value you read into a local copy, if the values match then write the modified value into memory and otherwise do nothing, and the operation will return a "true" or "false" depending on if it succeeded. This is usually implemented at the hardware level using a compare-and-swap operator or a load-linked/store-conditional instruction, depending on the architecture. Anyway, a wait-free data structure is a lock-free data structure that also guarantees local progress: it's possible for a thread to get hung up indefinitely on a compare-and-swap because another thread keeps modifying the memory location, but a wait-free data structure guarantees that a thread will only fail a finite number of times before it succeeds with its compare-and-swap.

[regexcellent]

Man when we hired a software engineer we asked **** like "how do you traverse a binary search tree in order" and that weeded out all but maybe two applicants.

[loinburger]

Almost all of the coding questions I've gotten have been about concurrent/distributed computing, since all of the places I've interviewed with are into Big Data (Hadoop, key-value databases, etc)

[loinburger]

Actually, I take that back, there was one idiot who asked a bunch of Scala trick questions. Scala has a "map" function that, given a sequence, will apply a function to each element of the sequence and return a new sequence consisting of the function's outputs, for example Seq(1, 2, 3).map(i => i + 1) will return Seq(2, 3, 4). You can use a shorthand for this: Seq(1, 2, 3).map(_ + 1) will return the same thing.

So here's what this dumbass asks me:

Dumbass: What's the output of Seq(1, 2, 3).map(i => println("Hi"); i + 1)
loin: Prints "Hi" three times, and returns Seq(2, 3, 4)
Dumbass: How about Seq(1, 2, 3).map(println("Hi"); _ + 1)
loin: I assume the same thing, but if that were the case you wouldn't be asking me, so...
[puts the input into an interpreter]
loin: Huh, it prints "Hi" once and returns Seq(2, 3, 4)
Dumbass: Why?
loin: I don't care
Dumbass: Let me explain it to you anyway!
loin: AHHHHHHHHHHHH

[Hauldren Collider]

A lock-free data structure doesn't use locks, instead using some sort of atomic compare-and-swap: read the memory location into a local copy (e.g. in a register), modify the copy and store it in a different register, and then execute an atomic compare-and-swap that compares the current value of the memory location to the value you read into a local copy, if the values match then write the modified value into memory and otherwise do nothing, and the operation will return a "true" or "false" depending on if it succeeded. This is usually implemented at the hardware level using a compare-and-swap operator or a load-linked/store-conditional instruction, depending on the architecture. Anyway, a wait-free data structure is a lock-free data structure that also guarantees local progress: it's possible for a thread to get hung up indefinitely on a compare-and-swap because another thread keeps modifying the memory location, but a wait-free data structure guarantees that a thread will only fail a finite number of times before it succeeds with its compare-and-swap.

That's...a fairly complicated operation to make atomic. At least, if you have a non-primitive data structure you are comparing and swapping.