In the example interview schedule in your blog post there's only an hour allocated for BYO project discussion. Is that representative of your typical interview schedule? The scope of some of your examples in the blog post may be challenging to cover in much detail in the first hour working with brand new collaborators, although perhaps is enough for calibration. Are you able to share any examples of the fun projects/ideas you have as suggestions for candidates that don't have a project of their own?
Yup, we do an hour. After that, it feels like there's diminishing returns. There's absolutely no expectation anyone will "finish", and we make that clear. It's the journey we're interested in, not the destination.
One that we tend to do a lot is creating an image gallery using Flickr or Unsplashed's API. It's vague enough that people can take it in whatever direction they want, and simple enough that you can get pretty far in an hour.
I was surprised it was that long, I can talk about a project for much longer than an hour but the average interviewer won't give a shit past 15-30 minutes.
Your candidate-focused interview process is very inspiring! I really like the "bring your own project" idea and it also looks like you've cleverly integrated your product into the interview experience (I'm assuming that is what powers the personalised interview website). I also think the general tone and styling of your content is very considered and engaging. My honest first impression is surprise that I haven't come across your brand yet, but I'm definitely going to learn more.
According to the page edit history, this humorous article was created in 2004 and has continued to evolve since then with 400+ edits (including updated stats for 2020). I often describe my Wikipedia experience as the "largest MMORPG I've played", and this article does an excellent job of fleshing out the comparison.
Great Ball Contraption (GBC) is a standard for building modular Rube Goldberg machines that continuously move LEGO soccer balls or basketballs from one GBC in-basket to the next using LEGO motors and programmable controllers: https://www.greatballcontraption.com/wiki/standard. This video from Brickworld Chicago last year has almost 400 GBCs with some impressively creative approaches.
I disagree that these examples are a waste of time. In all cases you benefit from having created the code to address your own use case, but perhaps don't see further direct benefit from sharing your work.
Submitting a PR allows others in the community to apply your patch (or incorporate into a forked version of the project) if the PR doesn't get merged or deleted. From a project maintainer's point of view, significant patches can be difficult to test & review, and merging a PR implies accepting the long term maintenance of those changes. I've left some promising PRs for much longer than I'd prefer to because of factors like time to review and the risk of merging code which may not have adequate tests. If an open PR attracts some community interest or discussion, that can give project contributors a helpful signal for prioritising.
If a PR is featured somewhere, this can be an opportunity to raise your profile and perhaps introduce those inquiring users to something you can benefit from more directly. If I get direct emails about a PR or project I contribute to, I try to politely point those users to the right channel (eg raise a GitHub issue) and ideally a contributor guide so they can be empowered to contribute directly. This may not be a straightforward reflex to develop, but I think responding with "This is a volunteer effort -- here's how you can help with docs, testing, or code" is a better viewpoint than "Ugh, more entitled users". I've been pleasantly surprised to see this approach turn some agitators into useful contributors.
If a project has very niche dependencies (like requiring API access to a satellite ground station), there can still be an audience and they may be even more motivated to collaborate on your open source project. I feel like this may have the best upside in terms of potential ratio of users to collaborators.
I think your last example is the most challenging. If you are concerned about someone else benefiting by stealing or repackaging a project you have openly shared, it would be best to keep that effort private. Compliance with open source licenses (or the spirit of open collaboration) requires ethics that are not universal across developers, companies, and countries. This problem isn't unique to open source (commercial licenses also don't prevent piracy), but is a harder blow when you are personally affected.
If you are going to use public commit profiles as part of your screening process and hiring decisions, I would encourage you to ask candidates what aspects of their public activity are relevant. For example, ask for a few specific highlights and why the candidate thinks those are interesting.
Hobby projects and open source contributions are evidence of patterns of collaboration and commits, but may not be indicative of one's typical (or best) work. There are also many reasons why a great software engineer may not have a public activity profile.
The majority of my public commits are scratching itches on open source projects, and are very opportunistic depending on other life and work commitments at the time. Code may not always be pristine, but I can probably rationalise why I took a certain approach (following existing code style, hacking for my own use, actually aiming for quality and performance, ...).
As a hiring manager, I'm also OK if candidates want to do something with their personal time that doesn't involve committing to public repos :).
Cosmos' API is an emulation of MongoDB which differs in features, compatibility, and implementation from an actual MongoDB deployment. Cosmos' suggestion of API version support (eg 3.6) is referring to the MongoDB wire protocol rather than the full MongoDB server feature set for that version. There are also some inherent differences, such as Cosmos' Request Units (RUs) which need to be considered for capacity planning and costs: https://docs.microsoft.com/en-us/azure/cosmos-db/request-uni....
Those differences may be fine for some use cases, but definitely compromise portability if you want to run or test the same application with a database deployment on GCP, AWS, or your own infrastructure. The lowest common denominator is based on Cosmos DB's underlying limits and features (not a MongoDB server feature set): https://docs.microsoft.com/en-us/azure/cosmos-db/concepts-li....
Great comment! My corollary would be that "Many managers have never had a great role model". In my first role as an engineering manager I thought it was the logical career progression and promotion from lead, but my preparation was more along the lines of "I've had managers, I can do what I think they do". I was very fortunate that my company at the time was supportive with follow-up training and building a peer group of newly minted managers, but it would have been more ideal to have some prior leadership & management training so I was more aware of the role and responsibilities I was signing up for. I think training provides helpful insight into intentional motions and being a competent manager, but it is hard to beat experience and learning from some great role models.
One secret I would tell any engineers considering management: "management is a career change, not a promotion". Charity Majors has some excellent blog posts on this, including the Engineer/Manager Pendulum: https://charity.wtf/2017/05/11/the-engineer-manager-pendulum....
A promotion doesn't mean you have to take on the role of your manager, it generally means you have expanded (or new) responsibilities and expectations. For larger companies career progression broadly falls under either an individual contributor (IC) track or a leadership track. As an IC you can grow your career from Engineer to Senior Engineer to Staff Engineer without changing managers or teams, and there is a similar progression for leadership.
Becoming a manager because you think that is the only ladder to climb is definitely the wrong choice. I think a great manager is also a leader who takes an active interest in the motivation, growth, and outcomes of their team. If a management team worked the way you describe (manager's managers run the show and broker deals with their peers for micromanaged promotions), that would be an extremely dysfunctional environment.
In my experience it is always the direct manager who recommends someone for promotion rather than the next level up (although your manager's manager likely has final approval on budget). As a manager, I support and coach my team toward their career growth aspirations with regular performance & growth conversations. I also try to ensure my direct manager has visibility on the state of the team, but ultimately they are expected to be looking at a bigger picture and trust that I am taking care of my team.
I haven't seen this design in practice using MongoDB Atlas or Compass, but would hope for an "Are you really sure?" confirmation in an admin UI.