You got off easy. Our red flag guy (barely knew his way around a computer) hung around as dead weight for two years.

I took a programming test today. It was 50 multiple choice questions using every major language you can think of, with the hipster ceiling being at Ruby.

The first part was "Look at this code and tell us why is wrong." It was mostly common sense and deductive reasoning, but still a PITA. There was an option of "i don't know" and I had to click that a few times. It was a timed test and presumably, copy / paste wasn't possible...

okay, it was possible to copy / paste because lol testing sites, but compiling 8 languages with a 1 minute timer on each probably wasn't gong to help since it was all wrong.

The next part was design stuff, and yes, obviously, you hook into Hadoop for everything. What kind of silly questions are these?

Apparently, I need to brush up on my bitwise operations and C pointers. I really don't know how that stuff works anymore and did my best with it.

I've had my fill for programming tests for the next 6 months. That was just too much and I surely will get the "thanks for wasting our time" email. That's why they didn't bother calling me first, I'm sure.

Slow typing was just one thing, but it showed lack of experience with programming in general. The vibe I got was that this person was coming from an enterprise world where the pace is slower. And had a hard time adjusting to the pace here.

Kind of sucks for the person leaving since they probably left a cushy laidback job for this only to leave 3 months later.

We had a guy leave recently who somehow stuck around for ~1.5 years while never finishing projects. He'd get assigned things and work on them forever and ever, while slowly making progress but never actually finishing ****. No idea how he lasted that long without getting fired. He wound up getting included in a small number of layoffs due to teams merging and creating a couple redundancies.

A friend once told me in 15 years of software engineering he could count on one hand the people who got fired, and nearly all of them did something malicious.

Going from aggressive quota-driven sales to software engineering has been quite the culture shock to me.

I'm also in this weird zone where I'm 10-20 times better than I was when I started and way way way faster than I used to be, but not everyone around me has realized it yet.

I got called "an expert" at work today yikes.

If we learned anything from suzzer, I think this means that within a few months you'll be working 100% remote on proof of concept ideas that have a buzzword to reality ratio of at least 3 to 1.

job search begins in earnest tomorrow.

hoping to land at least an internship by summer, with the (hopefully not limiting) caveat being I want to stay local.

Did you just say you don't like for loops? And you're a programmer. I wasn't even referring to efficiency, but to clarity of code.

It's probably just because certain things are more often used by tech people, but programmers sure are vocal about their work being stressful.

The inability to fire people is basically why there are so many oddball issues. I've always said the solution is pretty simple... (I understand I'm kinda crazy though)

I learned from this thread that for loops are bad and Functional code is good. Also Linq.

For loops do suck. I'd much rather read stuff like this:

R solves the for loop problem by working on sets of things all at once! It’s impossible to debug and doesn’t believe in telling where errors occurred, only that they did, but that’s a small price to pay for removing syntactical sugar...

I don't do much R but I used to teach a Matlab course. Matlab allows for loops but using them is usually a huge mistake. That was always lesson one in my class.

Like consider you have 2 arrays of the same length, a and b and you want to calculate sum(a[i]*b[i] for all i). Doing this using array math in matlab would be literally like 1000x faster than using a loop.

The EE department taught a class on numerical methods in EE and people would make these awful 2 and 3 dimensional loops to do numerical integration and wonder why their programs never finished.

It's called vectorization. It's great, but not always possible.

What's interesting, is that if you do need to use a for loop and performance is very important you can "mex" it (write it in C/C++ code) to speed it up. But if you mex your vectorized stuff you're probably slowing down the MATLAB code because the LAPACK/whatever code that MATLAB calls under the hood is going to be faster than your custom C loops. So the when and how of mexing a MATLAB algorithm is often an interesting trade-off of your for loops and pre-optimized MATLAB calls.

To be honest, I’m more frustrated with the limited debugging in R than the syntax, being able to say “add this column to this table and base the value on these other columns” in one line of code is nice and seems more accessible than thinking of loops.

Speaking as a data guy who learned a bit of SAS and SPSS in grad school and moved on to R later, I totally agree with the accessibility thing. I'm not a real programmer and for loops **** me up. OTOH, the apply() functions are very intuitive.

When using the github web UI for merge conflicts has anyone else experienced it not taking the changes the first time? Myself and a team member both have this happen frequently, where you have to do the resolution twice before it sticks. Are we doing something wrong (other than opinions about using the github merge conflict UI at all ) ?

I work with a vectorised system for my day job. It's a very quick approach if done well.

Havent had that specific issue, but githubs caching is weird and sometimes I have to do things twice or hard reload the page a few times

proc summary ttw!

Lol, I don't miss SAS.

What do you use? I've become a huge fan of J over the past year.

My favourite definition of expert is "someone that learns more and more about less and less until they know absolutely everything about nothing."

Although in my last consulting job, the definition of an expert was simply "someone from out of town."