bought the first version of the CLRS algorithms book for 7 bucks

can't quit paper books for some reason

Reference material is the only time I still buy physical.

Heh, about a decade ago, a small Russian search engine ran a promo offering to choose a free paper book on programming from the shelf of a partner online book store, with a slogan like 'we care about your eyesight'. Most users chose CLRS because it was the most expensive; I didn't need an extra book on CS, and so I chose the twice smaller 'PHP and MySQL Web Development' (3rd ed.) by L. Welling and L. Thomson, which is where I got most of my scarce knowledge of SQL.

im writing in c on unix and i suck at both

i have a const called log_name which is "ring.log"

i tried fopen(strcat("../", log_name), "w+" );

it does nothing

but if i do fopen(log_name, "w+"); it works fine, creates the file and everything.

what am I doing wrong? i just wanted to make sure the ring.log file didnt go to some random place, and wanted to prefix it with a ./ or ../ or w/e

http://www.cplusplus.com/reference/cstring/strcat/

According to this, strcat overwrites the first string and the first string should have enough extra memory on the end to accept the result of both strings concatenated together. Passing in "../" definitely doesn't qualify.

Try something like

This is pretty brutal; now finished with 4 with 1 to go. 3 negative results and no offer so far: One rejection where the feedback was, everyone loved you, thought you were great technically but wasn't sure if you'd be good at communicating technical things to non-technical people; one near-rejection where they were about to make an offer but a last-minute corporate level decision just made it unlikely they can move forward with any hires; another rejection where the feedback was, you were great, everyone loved you but we decided that you were not the right profile and didn't have the right background for this position. The only good news is that the one remaining interview and the one where I haven't heard back are my top two choices and ones where I had strongest referrals.

that worked, thanks. i should probably read documentation before i head to forums xD

There are just no words to describe this situation. Totally rooting for Jeremy here. Also never been impressed by Sam Altman - it seems that he's really great in person from what people say about him but I can only judge him by what he writes and there's not much depth to anything I've ever seen him write, unlike Paul Graham whose essays are very interesting.

JFC dude. What idiots. That is the exact opposite of how I would characterize you. Did they ever ask you something like "How would you explain this to a non-technical person?" Otherwise of course you're going to try to be as technical as possible to show off your chops.

Could just a bogus reason.

Yeah to be fair I probably wasn't best at describing my current situation and often bit off more than I can chew by attempting to describe things that are too hard given the setting because what I do is both fairly complex and not something a lot of people are familiar with. This was also my first technical onsite interview in over a decade so for more technical problems, I wasn't necessarily good at balancing problem solving, which for me works in a very intuitive way that's hard to verbalize, and explaining my process. And their interviewers I thought were all excellent communicators so this is obviously something they are looking for, though I'd like to think that I'm normally pretty good at this as well.

They did ask at one point "how would you explain this to a junior developer" but that particular one I think I handled very well and that interviewer told me that he liked my description and diagram. I think I do much better when I'm put on the spot but I do sometimes ramble on when I'm in that problem-solving mindset. I could have chosen my topics more carefully and focused more on communication as opposed to getting things right.

I've also tightened this up quite a bit in my last interview and was pretty good IMO at taking the interviewer through my thought process. Slowing down was kind of the important part for me - as it turns out, I'm a pretty fast whiteboard coder so it seemed to work for my benefit to slow down as much as possible during the problem solving part of the step and work with the interviewer as much as possible before jumping into coding. Even just enunciating clearly and slowly can create an appearance of strong communication skills regardless of the words coming out of my mouth.

Is it common among developers to have an unhealthy desire to optimise the code beyond what would be enough for the task (I call this disease 'assembleritis' )?

E.g. when I want to implement a Google-like live (i.e. with prompts) search of a record associated with a family name, I'm tempted to store a 4-byte int hash value for each name in the DB, based on the first 6 letters of the name in lower case (6 x 5 bits), and search in the hashtable using bitwise 'and' with a mask calculated from the input letters, resorting to the usual substring search function only if the first 6 letters turn out to correspond to more than one record. I mean, I'm tempted to waste time on coding this even if the DB is small.

I'm not sure what's particularly efficient about this though - you're probably better off using database indexes (using a computed expression if your db supports it). If you truly want to do something like Google Suggest, you should also consider tries (prefix trees). Optimization can be interesting but going through the motion of trying to optimizing without a broader perspective of what you're trying to accomplish is definitely an anti-pattern.

TIL, ty

Tries would be an overkill, though, as PostgreSQL (in the C locale) indexes string columns for prefix search. Infix search is slow in general (strings aren't indexed for LIKE '%searchstring%' comparisons), but it will be enough to create aliases for those names that have too many common letters (would take too long to type) and look up the special (tiny) table of aliases along the main table of names; e.g. 'Bush, George H.W.' and 'Bush, George W.' can be aliased as 'Bush Sr' and 'Bush Jr'. It's more flexible and easier (as I can memorise all the few aliases) than using Lucene or Solr for term-based search.

For the more senior programmers amongst us, what effect does open source contributions have on future job prospects? Is that something that gets a lot of respect or just a lot of eye-rolling? I had an idea for a python script that would accomplish a task that bash currently can't.

It's fairly well known as premature optimization.

Famous Donald Knuth quote that I 100% agree with:
Write a basic version first, then profile. Only optimize code pieces that contribute significantly to the total runtime. Don't waste your time optimizing pieces that make up <<1% of the total runtime anyway, any gains there will be completely negligible in the big picture.

FWIW the reasons you received are complete BS and not stating this just to make you feel better. Don't beat youself up but yeah sure hone your interviewing skills. Look, the deal is that hiring outfits can afford to be very choosy in hiring senior developers and it is tough to get hired as a senior developer. Hiring outfits are cautious.

Naturally as a senior developer myself I don't think companies value their skills high enough and certainly ymmv on that. I have pretty much embraced the "1 out of 10" philosophy, out of 10 interviews I will get a job offer. Sometimes it is luck too.

Again FWIW, a lot of mansgement does a pretty piss poor job of managing their code bases, waste too much dev time in BS assignments that check a box but don't add value IE a slavish devotion to inflexible processes because they believe the process reduces risk. There is a lot of crappy code out there as a result.

I love the term

Btw, I'm guilty of having a mostly unread hardcover translation of 'The Art of Computer Programming'

Of the 3 companies I talked to (netflix, tinder, and a startup) - none of them seemed too interested in my open source projects.

However I think it might have helped me get the architect job I just transfered to in my existing company.

Even if that hadn't happened I still learned a lot and tightened up our node framework tremendously by packaging it up for open source.

As far as "open source contributions" i.e. making a PR to some library somebody else made/maintains I don't really care but if you mean like your python script I would be very interested. 4/5 resumes/applications have no visible way of showing that they can code i.e. no github, no links to things they've made, just experience and education.

Hey candybar, what are you looking for (fee free to PM me). We are always hiring senior people

i'm writing an API in node against a postgres backend.

i've posted about this before, and have done some research on various ORMs like sequelize, and query builders like knex. now i'm feeling like, **** it, i should just use node-postgres and write actual SQL which a) I have lots of experience with and b) is likely a better and more stable language than whatever SQL-adapter language any of these libraries has conconcocted.

What am I losing? The ability to swap out another database with no changes to my code? Yet a) that prospect is vanishingly unlikely to happen with the production app so b) the only real advantage is the ability to swap out to an in-memory db for testing. But I can always run a local postgres for testing which should still be fast, so advantage of b) isn't as great as it would seem.

Still, I feel like it's kind of a dirty thing to do, probably mainly because it's not done that much, which is ofc a terrible reason. Thoughts?

My $0.02 as someone who has no experience but had contemplated this question for a while.

ORMs exist for those lazy bones who don't like to write much code and want to increase their shortterm hourly earnings by spending fewer hours to produce a lower quality product (but their reputation and thus longterm profits suffer). You're not lazy.

And I think that designing the DB schema and queries yourself, instead of letting an ORM do this, makes room for significant optimisation.

You've probably already seen this lecture by Josh Berkus, but it doesn't hurt to remind about it:



It's also available as a slide show at SlideShare (search for 'ten ways to destroy your database' there) in case of intolerance of the poor quality video.

Wow, I'm glad you got some feedback, even if it is something everyone would disagree with. I've always been stonewalled by some policy mumbo-jumbo or been outright insulted.

The same people that rejected you will be contacting you, via recruiters, every 3 months for the next 2 years. This ends up becoming a game, where you call the "super stealth / secret" company, and name-drop the managers that wrote the ad.

I find this truly fascinating. The claim is everyone hires only the top 5%, but it appears that there isn't enough available people in general to cover any top N%, much less lofty numbers (ignoring the fact that there are probably like 10 people in any city who can do whatever tech the company is seeking). It also makes me wonder why, if after searching for years with no dice, the ads aren't rewritten to target others.

Consider all the things PostgreSQL has that MariaDB doesn't have:

* Insert / Update CTEs (CTE's in general)
* returning [value] after insert / update
* windowing
* lateral joins
* contribs: http://www.postgresql.org/docs/curre...c/contrib.html
* insert / update views
* materialized views
* (so much more to list)

An ORM has a few major flaws IMO:

1- An ORM has to be written to the lowest common denominator. It is truly impossible to write and ORM that is optimized to each and every flavor of SQL.

2- Due to (1), the queries can't be universally optimized to work on each flavor of database. A simple example is query hinting, which is apparently a leaning stick in Oracle, but will never make it into Postgres.

3- ORMs aren't human. This means that the ORM isn't going to magically create queries the guarantee optimal speeds and data integrity. Some ORMs don't even attempt to guarantee data integrity. This problem is just too damn hard, and until some poor soul decides to write a full-on AI for SQL ORMs, the problem will always be intractable, and even with AI, I doubt it would be functionally useful.

Upthread, someone had an issue he asked about. I managed to recognize the issue pretty quick, knowing that cascading deletions are a major perf bottleneck in PostgreSQL. This is an example of ORMs being built on some assumptions that aren't universal (I don't know if other databases move faster with cascades, but I suspect none do).

Overall, I don't think ORMs and raw SQL are really an either / or proposition. The approaches are so different that I don't consider them to be the same concept.