tom_b

My BS in CS is from NC A&T.

My MS in CS in from UNC-CH.

Anybody who thinks the hackers from Duke/UNC consistently outshine the hackers from NC A&T is a damn fool.

I was regularly FLOORED by the skills and raw programming chops from peers at NC A&T. Some of the smartest young men and women in the CS field.

I worked in a small research group at NC A&T. Maybe 10 undergrads. Last time I checked, there were something like 6 MS in CS folks from that group and a couple of PhDs.

When I was an undergrad at NC A&T, we had a weekly colloquium for all CS students. We regularly had alumni from NC A&T and other HBCUs on stage who talked openly about navigating the hiring world, which companies you could expect racism in, and what the working world of programming was like for "people who look like us."

If some shitty recruiter event occurred, we all knew about it.

Want to score some of the best engineers from HBCUs? It's easy. Hire the best ones you can convince to take your mega-FAANG package from. Then send them back every freaking year with a corporate card and tell them to impress people.

I hate these "stupid recruiter" stories. Somebody should get their ass fired.

I think this a much more nuanced question than a yes-or-no answer can cover.

Looking at LinkedIn or indeed.com with just a simple search for Clojure with no geographic qualifier (in the US), we see a very small number of listed openings - 252 over the last month at LinkedIn or 44 in the last 14 days at indeed. A plain google job search on Clojure jobs in the US returns an even smaller number.

Some of those job listings will almost certainly have Clojure listed as part of a "laundry list" of technologies and the actual job will probably not be Clojure oriented.

So just from a raw numbers perspective, the job sites to suggest that there aren't a huge number of opportunities. Comparatively speaking, there are like 60,000 Java job postings on LinkedIn in the last month.

However, if you attend a Clojure/conj (one of the "primary" Clojure programming conferences), you will find that many attendees are part of some (not super-large?) number of companies that use Clojure.

My best advice on building a Clojure career (that I failed to follow) is that a programmer who wants to make a Clojure career path is to be prepared to spend a significant amount of time trying to make connections inside the Clojure community. On top of that, you probably need to build a portfolio of project experience that you at minimum blog about and preferably speak at Clojure conferences, user groups, or meetups.

<edit: removed off-topic thought>

I would gently observe that long-time Clojure developers are maybe too close to the tree to see the forest when it comes to judging Clojure career opportunities.

But I would love to be wrong about my impression of Clojure job opportunities! Perhaps fellow-HN readers could post (anonymous?) numbers of Clojure job openings for their company to give us a better idea?

I was unable to bring Datomic in-house. Mainly because our organization has a huge agreement with Oracle and all our database servers are essentially "free" to teams.

So I cheated. I created some schema designs that were immutable. I added a GUID, timestamp, and a deleted flag (value of 'Y' or 'N') to tables. Basically, all selects are against views that are defined over the tables to select the tuple associated with the max(timestamp) for that tuple along with the tuple having a deleted flag value of 'N'. This means that any select only sees the most recent tuple value for a GUID if it hasn't been "deleted".

There was a little bit more hiding in there to handle dirty writes.

But this worked very well for my requirements. By really only doing inserts, I was able to do similar "point in time" looks at the db as an immutable value.

Fun stuff.

Congratulations to Cognitect. Hopefully the acquisition will help Rich's retirement funding. (see 'History of Clojure' for the not-so-insider joke here)

I have had the pleasure of "using Clojure in anger" and for a few years was very dedicated to learning how to use it effectively. This was a significant step up for my general programming skills and the simplicity of the language often saved me from myself with respect to bad design or choices in code. Whatever programmer "maturity" I can claim is probably due to Clojure and teaching introductory programming and databases (not with Clojure and Datomic to be clear).

This acquisition is more abstractly interesting to me in that a VERY dedicated Clojure/Datomic company made it. We didn't see here, for lack of a better example, a FAANG company grabbing Cognitect. That may have been a choice! Maybe Cognitect went with an acquisition where they retain a high degree of autonomy with the benefits of being acquired.

I never made the leap into a larger organization with Clojure at its core. I was able to use Clojure only in my small shop where I have a small degree of autonomy on development language choice. For a few years, I was somewhat actively seeking an opportunity to join a larger Clojure-oriented team but struggled to gain much traction when applying to openings. It seems possible to build a Clojure career, but I've not been very good at that.

I think much training for dog aggressiveness is more about helping people to understand drives and managing "triggers" than training them out of the animal . . . it seems underappreciated by many normal dog owners.

My last dog had super high-prey drive and was also a fear biter.

Both drives were incredible. You could play train her to do almost anything in a very short period of time with classic behavior shaping. It was unfortunate that her fear drive was higher. But this mostly meant proper space management and patience were required along with never assuming that a situation was "ok" by default.

We worked with a number of animal behavioral specialists (including university veterinary behavioral practices), all of whom concluded it was just her default personality. Much of our success in keeping her with our family was building environments that minimized her fear drive impulses.

Still a great dog in many situations. She passed after a pretty healthy 15 1/2 years and I'm currently on a break from pets.

Thelios Major from System76.

  64GB memory
  8 GB GeForce RTX 2070 Super with 2560 CUDA Cores
  A couple of NVME SSDs.

I install Centos as the OS. Setup, including Nvidia drivers was very easy.

Probably could be built from components cheaper, but I appreciated just making an order and having a box show up later.

My past machines have been Thinkpads, then six years with a Macbook Pro that I wiped and installed Debian on. I made the move back to desktops for a variety of work-related reasons.

I remember being at the first Clojure/conj - I had just spent some time learning a bit of Common Lisp and stumbled onto the conference announcement somehow.

This was very fortunate for me - after attending the conj, I was able to use Clojure at work to sneak in some FP on the readily-available JVM platforms. I later used it to do some internal REST-API work. The code for that project has run for years without modification or error.

For whatever reason, I also discovered that thinking functionally with Clojure worked so much better and naturally for me than object-oriented design methods. While I have drifted away from Clojure over the last couple of years, I find that my problem solving mind is much better in other languages because of the time spent thinking functionally with Clojure.

I have enjoyed all of those and the Stockfighter attempt in this space as well. They all seem to have hit a hard obstacle in convincing the general, non-FAANG hiring market that they can provide "better" candidates that any old staffing agency. I have definitely had hiring managers in non-software companies tell me that they will just pick from three resumes from a staffing agency of a standard enterprise developer job without much actual consideration of the candidate's resume or portfolio of previous work.

I do suspect there exists a category of higher-end headhunter agencies with a stable of high-quality, proofed candidates that those agencies can more successfully place than other attempts. Just an anecdote, but I have seen in my area some things that look more like a "small team" placements where that team has some history of helping companies radically improve their software quickly. I am specifically thinking about an actual team that gets hired as a group but into fulltime roles at a company as a unit. This seems to be a prequel to an acquisition of the company that hired them being the end goal. Then that entire team seems to repeat the process elsewhere . . .

The response is enthusiastic, but kind of misses the point my original comment was making. All I was saying in that comment is that as a hiring organization, we bring in candidates who on paper have the skills and experience we are looking for, but flame out in spectacular fashion when asked to talk about their skills, experience, and how they might apply to our specific problems and situation.

Note that I am carefully NOT saying, oh the candidate knows javascript, but not vue.js, so they don't fit for us. I am also not saying "oh, if only candidates knew we wanted them to get vue.js certified and it would be more likely we would put them in our interview loop."

I don't think the problem of how candidates can better understand why they are or are not getting callbacks from employers maps very well to any stats-based measurement of job posting descriptions against applicant resumes/CV/LinkedIn profiles.

My only thoughts on the hiring process are really anecdotal, but I believe a few things to be true.

  1 - Most job descriptions are crap.
  2 - Most jobs for software engineers can be done by any
  reasonably trained and/or experienced candidate 
  who can pass a work-sample test.
  3 - Totally untrained and inexperienced candidates 
  seem to apply to lots of jobs.
  4 - Software engineer hiring should be ideally 
  based on work-sample tests.
  4a - I have a *very* hard time finding companies 
  that do #4.

But stats like that also can signal being over-selective.

I would gently suggest that it is a mistake to think in terms of unqualified vs highly-qualified candidates and ML for "callback probability". I don't want a good, but not FANG-level, candidate to NOT apply for our standard software engineer opening just because 74 people already did.

Why? We had 60+ candidates for a recent posting for a junior developer role with some experience - think 1-2 years or some good school projects. Somewhere around 45-50 of those applicants were easily HARD-FLAGGED don't interview at all after a quick cover-letter and resume review by a technical person using a rubric. That rubric was scoped only to weed out applicants with absolutely no meaningful experience.

While I also hate the laundry-list approach for job listings (Must Have: Expert Java and C#, Spring ORM and ActiveRecord skills with deep understanding of React internals), I think the best way to attack that is with a short, but focused cover letter. That should include a short paragraph or two about a candidate's hands-on experience and speculate how their experience might apply to the position. I guess what I am driving at is that this idea of ML assigning importance weights to "soft" vs "hard" requirements is, at best, just another low-value signal in job postings that are already full of low-value signal.

Matches my experience on the hiring side.

In the group between "don't qualify" and "can't afford", we have a hard time with candidates who are unable (or maybe lack the communication skills) to effectively talk about how their experience+potential are a good match for even a generic job opening.

We don't do any algorithmic/challenge screening during interviews.

A common interview fail for us is to have a candidate that can't generalize from or build on something from his/her resume. This usually comes out during "tell us about project X that you worked on" and comments from our side like "oh, that sounds like project Y here. But Y is different this way - what are your thoughts about how to handle <insert small-scoped, specific difference>?"

YMMV, but in my non-FAANG experience in the mid-/south- eastern US, tech managers seem to make at least 1.25X for X=senior dev salary. Maybe keep that in mind?

My dev friends over the last 10+ years have included people who made a management/dev track career decision and anecdotally speaking, those who chose management have earned more and seemed to have more employment stability. In a couple of cases, I have friends in my personal network earning 3X a senior dev salary managing dev teams.

Personally, I decided to stick with the dev track and have been somewhat dismayed to find (after 10+years with one employer) that I am often pulled into decision/management-type situations but am consistently evaluated as a lower-level employee because "coder." It's even more annoying when I chat with my peer group who made the mgmt track choice and I find that the overlap between what I do and they do is actually very large.

We've found that graph-based community approaches have some really nice benefits in our bioinformatics data.

In particular, we have found that these approaches seem to preserve very small cluster structure "better" than traditional approaches. Meaning, we have a small group of cells that we know belong to their own cluster group and the graph-based community approaches preserve these "small" groups outside of other clusters nicely.

But we have also noticed (and had some feedback) that we windup with final modularity scores that are very high - greater than or equal to 0.90 (on a scale of -1 to 1). Applied math folks in the graph algorithms world kind of seem to look at that and go "eh, that is so high you should probably just do PCA and move on . . . "

Especially given that you could (and people seem to) use UMAP as a precursor to louvain methods, I'll probably be looking into UMAP to see how it goes. But our current performance bottleneck is that the clustering (or community approach of graphs with the louvain method) is our computational bottleneck, so we'd like to whittle that runtime down as much as possible.

Nope. But I think UMAP would be a dimensionality reduction step that you fed into a graph-based community extraction algorithm? In our current code experiments, we have been starting with a k-nearest-neighbor approximation algorithm to build the graph. UMAP would, at first glance, replace that.

I think there is even a louvain clustering method (really a graph-based community extraction method) built into several UMAP libraries floating around . . .