mock-job-mentor.vercel.app
- mock tickets on a large codebase - reviewing their PR submissions - giving them AI mentorship.
it's just the frontend for now and would really welcome feedback from you guys!!
If it’s serious, I doubt it provides much real value. Developer experience is built on accomplishing actual tasks, not the surrounding administration and ceremony. Aspiring devs should probably work on personal/toy projects or open source.
That said, it looks great—well done!
The advantages are there:
1. Reducing sign-up friction. Despite how much this crowd dislike such things, it's much easier for most people to hit "Use google login" or "use facebook login" than create a new account. One less password to remember ( or one less place to store the same password you use everywhere ) for people without password managers.
2. People trust "Google" or "Facebook" more than they trust random service they're just checking out. Having that "sign in with google" extends that trust to your service.
3. If you ever do need Authorization, it's much easier retro-fitting that if you already have OAUTH than trying to retro-actively fit it all to get that authorization.
4. Letting someone else take care of user account cancellation. Businesses hate it when there's no OAUTH, because they don't want to have to track down and change / cancel accounts when someone leaves their organization. They want to suspend/remove them from their Azure AD / Octa / etc and that user instantly becomes persona-non-grata across all services. They might also want to have different groups at their end, so they're still the same identity, but lost authorisation to log into <Service> now they moved from an ops role into development, for instance. They're still the same identity and same authenication in this case, but should no longer be authorised for your service.
At any big company, if you’re doing software you’ll be doing OAuth/OIDC like it or not.
So Oauth2/OIDC is what you typically want?
I don't really understand the details well. I understand what vendors and customers are after. I wouldn't ever try to write any clients/servers myself for this stuff.
But it's also easy to understand what there is to be scared about:
1. Security critical.
2. Single source of failure. ( If your auth fails, it doesn't just break one feature or aspect, it takes everything and everyone down with it. )
3. Performance critical. It's a bottleneck in most applications, it's very rare and even more difficult to get distributed auth working, if you factor in repudiation / token cancellation.
It's not an area you can "fake it 'til you make it" or "move fast and break things" with.
Even just "buying" the solution isn't easy. Actually implementing your own OIDC client/server solution is a large project that only makes sense to dedicate a team to in the largest of organisations.
If you then add outside people or companies to that, it becomes even more complex. Most companies aren’t in the business of implementing their own distributed auth system, and wouldn’t be able to do a good job if they tried. So they buy an implementation of a standard system like Oauth.
Discussions around Auth are typically confusing. This is not helped by authentication and authorisation sounding similar, but also because it is difficult to keep track of whether what is being discussed is first party or third party.
Most apps don't need third part authorization, although some do. For example if I were to use Cisco Meraki Oauth, then the third party authorization of which parts of the network were visible to me as a service is critical.
On the other hand, if I'm just using them as an easy way to provide authentication for a service which I only want to target to Meraki customers, then I don't care about the third party authorisation, and just need the authentication part. I still need first party authorization on my own system to keep different users' preferences separated.
Another source of confusion also mixing discussions of intra system authentication + authorization with external authentication + authorization. I've seen lots of discussions of JWTs for example which quickly start talking about local services, whcih might be better handled by not having the user involved at all, and just having a secured pipeline between services. You often don't need to have passthrough authentication/authorization, although again there are advantages and disadvantages to organizing services in this manner.
All they did was generate it with https://lovable.dev
That's why basically nothing works.
Also needs to simulate getting responsibility without authority, with weekly meetings to follow up on your progress.
From a "dashboard" point of view it's not bad for giving an overview of the state of things on a team project, but at the same time the main question in my head is: "Why not just work on an open source project?". That would give you experience, _and_ (hopefully) contribute to the improvement of something.
I question the experience of anyone interacting solely with AI to learn what it's like to work with others on a project.
that's what makes it even funnier
This is something that a company called Wilco were trying to solve. I thought they went under a year or so back but a quick google implies they are still around.
Just plug-in people to whatever codebase.
If I was VC I would probably immediately fund this.
”The human adapter”. As technology develops AI agents could be plugged in to replace human workers for suitable tasks.
Go seek funding now :)
Tech and the stuff around it is just one small dimension of the software engineering space.
Unsure what to do in Git workflow practice page, maybe some code didn't work for me? i can press "practice" or "visualisation" toggle but nothing happens
The AI mentor keeps saying "I understand you're interested in learning about that. Let me help you break it down and suggest some resources."
The whole thing feels like an incomplete placeholder? From your message, that's probably the intention to share it earlier, but people may expect more of it to be working...
I kinda get the idea though, could potentially lead somewhere, for example an actual onboarding step for a new role, or preparing for an entry level role before you start interviewing. The steps does give a hint to my experience as a SWE, at least.
> Make sure to follow the security best practices
Thanks Jane! Appreciate the input, don't you have your own work to do?
Keep up the great work!!
We've taken steps towards organizing our company dev knowledge by diataxis.fr (see the excellent Tailscale docs for a fleshed out example, whether purposeful or not), but the very first page of this gives the best docs overlay I've seen for one's first days at a new firm.
We'll likely reframe our onboarding around these layouts, where the detail is drawn from current work in the new hire's area, wrapped with references into docs, from how to set up one's dev env to how to write up a PR or pair on code review.
That being said, there isn't enough here to get any real idea of what it offers. Getting feedback early is good but this is too early.
For real, are you guys are redoing the auth implementation for every project?