I think you're better off looking non-specifically self-taught than you are listing a $50 MOOC.

I'm not. I learned a little since my post. I rdp'd to my work pc from my home pc and it logged me out of my work PC. And it can't be RDA as I didn't grant permission.

The logs show up at:
event viewer > applications and services logs > Microsoft > windows >TerminalServvices-remoteConnectionManager

RDP history shows up here but other types of events. When I rdp'd to my work pc it showed up as event 1149. Most of the events are 1155 I believe.

I think accepting this and being happy is the best scenario. If they are giving you even more than you expected and would have asked for on your own, why do you think there is some law of the universe that means you should ask for even more?

Seems disingenuous to just automatically think you should negotiate without accepting their move as reasonable.

Do people actually "negotiate" on yearly raises?

I'm on my 5th year at my company. I've gotten a raise each year for about 7%. Usually I'm too timid and insecure so I just thank them profusely and leave.

But the last interview I decided to stand my ground and ask for more. My supervisor asked why, and I gave some valid justification regarding my role in a new team. She countered with an offer to renegotiate after 6 months when they had a better feel for how my efforts were improving my team.

1 month later she left the company and I only had her word on this... wp, I guess.

What a joke, schedule call for 11 am and it's now 11:15. Supposed to be a 45 minute call. Still no sign of the interviewer showing up. This is why I don't like investing too much time researching a company.

Dumb q but you sure you're on the same time zone?

I will try to post a stripped down version of the main query after work today.

@daveT. It has been my experience so far that any time i've attempted to use a sub query whether its in the join or in the where clause, the query has been very slow. Maybe that isn't always true and it has something to do with how our db is setup (maybe we need indexes on columns that don't currently have them for example).

Yea same time zone. I had to email the guy and remind him. Started the call and we went through some questions. Then went through a live demo programming session with an iOS app. I was free to use any resources, google/stackoverflow whatever. That was stressful as balls. Don't think I did well but whatever.

Well, you DID it, so youre a large step ahead of many ppl, including me

Well got some good news, google recruiter called and said I didn't fail the technical phone interview but now I have another one upcoming that I need to schedule.

Interviews are so damn stressfullllll

If you use subqueries in a join clause, you are probably doing it wrong, which is why query #2 in my example will generally work faster than query #1. There are quite a few other little tricks, but the point is, you have to consider how the query planner thinks. Your job as a developer is to guide the query planner. I could write that query in several other ways. I won't know what is best until I run the query and run the analysis on a dataset (though I've been doing this long enough to have a decent idea what runs faster, but that is because I know why it runs faster).

Here are two more variations:

This one, I would suspect, will be faster than any of the queries I already wrote:

And this one may be faster than the regular join I wrote before:

This is a simple query, but I could expound on this further. A large, complex query can have many more variations, but I think you get the point by now.

I was going to add that subqueries generally do better with indices, but this is more rule of thumb that derives from the definition of an index, and they aren't guaranteed to work on your preferred queries, and they may not fire at all if your database isn't set up properly.

I take issue with "don't use [item] because [item] is slow." In PostgreSQL, CTEs have a bad rep because they are "optimization fences" but that doesn't mean that they are *always* the slowest option. You have to prove your case with set theory, a variety of approaches, and explain analyze, otherwise you aren't presenting anything of substance. The rules of SQL aren't able to be broken down into adages.

There are 3 rules of SQL:
1- measure
2- measure
3- when in doubt, measure.

Wouldn't it be better to actually create a variety of queries, run analyze on the results, and actually show your boss the results? If you actually prove that you can't do anything better than 30 seconds, then case closed.

... if your subquery has a where clause in it, the intuition is that you are querying a smaller table and the query optimizer will know that. This isn't true in databases that don't have query hinting. There is a terrible "limit 0" hack in Postgres, but I don't suggest using it (least of all because it doesn't always work out). Building up a full join then dissolving it down after the fact looks slower than using a subquery with a where condition, but counter-intuitively, building then reducing is generally faster.

anyone done anything with graphQL yet?

Thanks for the feedback re: the certificate, iversonian and Baltimore. iversonian, that's a good idea re: github, I'll start thinking about which solutions are worth saving.

The approach I went with (and was exceedingly slow) is your 'where exists' version. Per your comment about my boss, he has already made the assumption that it is possible even though he's pretty clueless in general. Me showing proof that what he wants is not possible does not disprove what he thinks. He has already made up his mind in advance.

This is a test I just ran and decided to test on. This first creates two tables:
Now create some test data.

This first query creates a collection of 1M rows, so that each number between 1 and 1,000 inclusive appears 1K times. That is converted over the varchar and inserted into the second column:

This next test data simply lists the numbers 1 -> 1M and coverts it to varchar:
To review, I have two tables, each 1M rows:

table_a has 1M rows with 1M different values in the val column.

table_b has 1M rows, but each val is between 1 and 1,000, inclusive and each val appears 1,000 times.

This is the query I suggested:

The result is 1,000 rows. Notice that I have converted an int to varchar, which is apparently a slow operation. This will list each id and val between 2001 and 3000 inclusive.

The explain analyze is as follows:

347.131ms is just north of 1/3 second. This is a subquery, does int -> varchar coersion, and dissolves 1M rows to 1K rows. All of this is intuitively slow, but I think this isn't too shabby. No indices either.

After creating an index:

...the execution time is 222 ms, which means this query is now executing in less than 1/4 second.

This equivalent query, with no subquery:
is running at 392ms and not using the index I created. This is slower than the subquery without an index.

Yes, this is a naive test, but I want to show you that subqueries are not inherently slow, and in fact, they can be faster when used correctly.

They offered you NOTHING so how does her leaving change anything? Promise to consider a raise in 6 months is a joke, not a real offer. There was a long debate about this very topic recently hacker news. I'm generally not a fan of that place but I think the discussion was pretty accurate from my experience.

https://news.ycombinator.com/item?id=12624112

Going to have to digest what you said tomorrow Dave. Seems like I might have some sql questions for you down the road

My contract specifies 1 salary review per year. She offered me a second review for this year, 6 months earlier than planned. That's a second chance for me to negotiate a pay raise, that I won't be getting now. It's no guarantee, but it's not "NOTHING".

I'm not dumb, I know that she was just trying to defer, but getting a second review still gives me some chance of added pay-equity in the future. However, now I will be more motivated for my next salary review to get a higher raise because of how this was handled, so that's something I guess.

edit:
I'm confused by your link. It seems to be discussing counter offers for people that are threatening to quit for another job. That wasn't my situation at all.

There's discussion about salary negotiation and how threatening to leave immediately opens up salary raise possibility (counter offer)

Generally you don't want to threaten to leave in order to get a raise.

Not sure how dependent you are on RethinkDB but you may want to keep an eye on this:

https://news.ycombinator.com/item?id=12641936

Thanks for posting that. I think we could switch to another NOSQL db pretty easily. We're not using any of the unique RethinkDB push features afaik.