101–109 of 109 posts
Earlier quoted context omitted.
Maybe possible in the US. Have not experienced this in any other place.
I work in Europe. This is quite standard for big tech companies. Of course, pay raise depends where you're coming from.
Earlier quoted context omitted.
> I remember showing PhDs about PKZIP and having them not believe it was possible to compress data without losing information - I had to literally show them the (rough) algorithm. They were right; that is a well-known and trivial-to-prove theorem about lossless compression. Lossless compression works because you only apply it to very particular types of data. It doesn't and cannot work on general data; that's why we…
I took graduate compression in the mid-90s.. JPEG was already invented and we studied that.. there was some handwaving but it was not as primitive as some comments make it out to be today
>I should pause here and point out that an interview at Apple was an all-day affair. Pairs of engineers would meet with and interview me for perhaps an hour. The first pair of engineers might grill me on some esoteric topic like code design, afterwards the next pair of engineers would sit down and maybe cover programming language specific questions. This took place in 1995, and sounds pretty much exactly like a techn…
I interviewed at Apple in 1987, and it was an all-day interview, but it wasn't much like the technical interviews I've done in more recent years--the ones characterized by brain teasers and whiteboard coding. There was none of that in my Apple interviews. They made me an offer and I worked there for ten years. Now, we can't conclude from that whether Apple has adopted whiteboarding and brain teasers generally. In tho…
Earlier quoted context omitted.
I took graduate compression in the mid-90s.. JPEG was already invented and we studied that.. there was some handwaving but it was not as primitive as some comments make it out to be today
JPEG is lossy
This was a great read. Some commenters discussed the nature of the interview, and compared it to today. But personally I get this feeling that this was still in a time when software was developed mostly in bubbles. Knowing how to code was far less obvious back then than it is today, and knowing the right stack meant you could get hired on the spot. Also, I don't know of it's nostalgia, the way it's written or somethi…
can confirm all this, and more. It wasn't until the late 2000s when programming became easy enough for the mainstream and you started to see "coding camps," upwork and the like. In the mid-90s, you had crazy demand for development but needed to be a brain surgeon to get hello world to work, let alone a website to be remotely reliable. There was no automated testing, let alone CI. Source control was sometimes used, so…
Today you need 11 frameworks to even write a hello world
Earlier quoted context omitted.
The rest of the professional class certainly doesn’t interview the way we do. Neither do people in the trades. People in performance careers like orchestra musicians and actors are the only other professions that really come close for all but new grads.
But programming is special ! The same approaches to hiring used for accountants or electricians couldn't possibly work! Don't you know programming is like painting? That's why we make people regurgitate algorithms they memorized in a high-pressure situation, while pretending they didn't memorize them. It's just like painting. eyeroll
You can pretty much easily test if you have enough knowledge to be a good accountant or if you can play the violin well. There are couple smaller issues. Having knowledge will not tell you if they are hard working a knowing how to play violin well will not tell you if they will do well with orchestra and large audience. But in general you can do a testing period and be done with it.
With developers... the main issue is that it is super difficult to judge how good a developer is and that is IMO mostly because there is a huge delay between making a decision and suffering consequences of the decision and then it is frequently difficult to tell how the consequences are connected to the decisions and what were the alternatives.
And a lot of it is just opinions, so even if you hire a better developer you get into territory of trying to figure out whose opinion is right (probably the higher paid one? maybe?)
And so when I hire developers I am trying to look at various other things that I hope are proxies for what I really need. So maybe I will try to look whether they have good judgement in general, how they dealt with difficult situations in the past. Maybe get to know them a little bit as a person.
Which you don't have to do with an accountant or violinist.
Earlier quoted context omitted.
I mean, sure, if you boycott the question you probably won't move on. But I'm not sure I want to work with someone unwilling to be curious or participate in problem-solving together. To me this filter is a positive effect of the test. In the interviews I've given I'll even handhold an applicant through to the optimal solution if need be, because to be perfectly honest I'd much rather have a coworker who is enthusiast…
> refuses to do so in a social setting (i.e. an interview). Interviews are very different from working together collaboratively. They're very different from presenting work to or working with a client or stakeholder, too, and even very different from a sales presentation. The space of things that might come up is effectively unbound, how you're being judged is wildly uncertain, you are being judged, and you know almo…
Earlier quoted context omitted.
can confirm all this, and more. It wasn't until the late 2000s when programming became easy enough for the mainstream and you started to see "coding camps," upwork and the like. In the mid-90s, you had crazy demand for development but needed to be a brain surgeon to get hello world to work, let alone a website to be remotely reliable. There was no automated testing, let alone CI. Source control was sometimes used, so…
> I remember showing PhDs about PKZIP and having them not believe it was possible to compress data without losing information - I had to literally show them the (rough) algorithm. They were right; that is a well-known and trivial-to-prove theorem about lossless compression. Lossless compression works because you only apply it to very particular types of data. It doesn't and cannot work on general data; that's why we…
Earlier quoted context omitted.
If the demand was high, why was the pay so low?
Was it? In 1995 I was shocked to discover what the “computer guys” were getting paid, and decided I ought to be writing code (etc) as my official job instead of just the thing I do within my other job.
Compared with management, no.