I'm a heavy user of git-spice: https://abhinav.github.io/git-spice (created by a former coworker) and can't really go back to a time without it. While still not nearly as good as Facebook's Phabricator, it's probably the best workflow for small, focused stacked PRs you can achieve in a Github / Gitlab based repository.
I was Triplebyte's first engineering placement. I still remember going to a random SoMa apartment with Harj and Ammon and Guillaume and coding up tetris in ruby, having no prior experience with game loops. That landed me a job with Flexport in 2016. I doubt that I would have gotten that placement without Triplebyte. So I am quite grateful that they existed, for jumpstarting my early career.
With that said, when it came time to look for a job again a few years later, I did chat with Triplebyte but ultimately took an offer through other contacts that I had built up by then.
After my (virtual) TB interview (which I barely passed), I had onsites at 5 places. After the five on-site interviews, I had 2 job offers, one of which was a company I wanted to work for since graduating college. I took the other offer.
This was preceded by a four or five month job search. I had received two offers in that time, but nothing seemed great.
I think TB's process kinda worked, but I understand your skepticism.
I'm actually not all that skeptical of TB's approach. They built a real business around it, way more targetted than eg Karat. Even though ultimately unsuccessful, that is surely more due to PMF and various missteps, than to lack of advantage for individual applicants vs spray and pray approach. (When taken as an average across all applicants.)
I'm just highlighting that GP's specific anecdote doesn't really demonstrate that advantage. Your example seems much more clear.
Somewhat OT for this specific sub-thread but I wonder how much "OA" tools that are part of coderpad etc, contributed to TB's demise. These are meant to be fizzbuzz kind of pre-screens. I know TB's approach was more than that, but from the hiring side, was the value not there since you'd always (?) have your own coding exercise after the TB screening.
Hi, I'm Michael. Product developer. Formerly at Facebook and Flexport. Full stack, but recent projects have been more frontend focused. Preference for slightly boring problems that provide real business value.
I just watched a video about this, that basically goes over all your points:
"Air Cargo's Coronavirus Problem" by Wendover Productions
https://www.youtube.com/watch?v=r2oPk20OHBE
A summary of the video:
- Passenger flight belly cargo used to be responsible for 25% of air cargo capacity, so capacity is severely reduced.
- PPE emergency logistics has caused a huge spike in demand, since PPE allocations are currently too volatile for anything except for air cargo. Air cargo prices are high.
- Government funding for airlines require pilots to remain on salary, so there's no additional marginal cost of labor.
- The biggest marginal cost of a flight, the cost of fuel, has understandably also become very cheap.
The end result is that even though it's still quite inefficient as compared to dedicated freight planes, the perfect storm of circumstances makes passenger-planes-as-cargo-planes momentarily profitable.
From what I understand, most airlines are rotating the few remaining shifts. This way each pilot gets a couple of flights per month, which is enough to keep their ratings.
That said, since many airlines have completely stopped flying some plane types (particulary the A380 superjumbo), those pilots are going to have a problem soon.
I was thinking about spec compliance. I think the best thing would be to provide these guidelines in the whoishiring post, and then ask that those who follow the guidelines put a unique string, like "metafriendly" or "whoshiringspec" at the end of the post. Then those of us who write mini-apps would know that the post conforms to the format.
Yes. Please add a way to reliably determine metadata on hiring posts. I wrote https://github.com/perspectivezoom/curated-hn-hiring but abandoned it after a couple months because it took way too much time to tag all posts.
By far the most important information seemed to be location and/or remote filtering. Gaganpreet stepped up and is doing a pretty good job with https://github.com/gaganpreet/hn-hiring-mapped, but it's still not 100%.
I would really love for whoshiring to provide this pipe-delimited template, and then optionally allow posters to conform to it. I also agree with danso's order of importance, but would also like to add that the location string(s) should be something geocodable by Maps APIs (ie, feed the string in and get an unambiguous LatLng).
I don't actually like that proposal[1] very much as it stands -- but perhaps moving discussion/pull-requests there would be useful? (I've not yet added my own comments there, but now with two threads on the subject on hn, I'm seeing the need to consolidate, if we want to get a wide range of contributions, and try to gravitate to the "best" solution...).
[ed: ah, I see I'm replying to the author here... I was a bit quick. Anyway -- the point of discussing a spec with a tool that support pull-requests/diffs etc still stands -- and I think it might be a good idea.]
I'm a full-stack web developer with significant Ruby on Rails experience. I have a history of pairing and TDD. Looking for a good team to join and to challenge myself a bit more.
