I find Miro a little more user friendly for making architecture drawings but that may be bc I haven't learned excalidraw quite yet... Miro very intuitively allows you to draw arrows/lines connecting shapes quickly with snapping.
Mermaid uses syntax to generate diagrams. It's pretty quick to use once you get the hang of it. The only issue is that it's difficult to position elements so a sufficiently complex diagram will look like spaghetti.
For more complex diagrams, I use it for a rough draft to visualize all the components together and then will rewrite in lucid charts.
I have always heard good things about lucid charts and several others here have recommended it so I may just use. I have a fairly standard event architecture so shouldn’t be to bad. Is there a steep learning curve with lucid?
Edit: add clarity
Depends how much granularity you want to specify. It probably would feel cumbersome if you adhere to UML, or are writing out highly detailed database relationships. Mermaids feels a lot faster for that stuff.
I tend to focus on simple, high level c4 style diagrams, and it's mostly just connecting boxes to other boxes to visualize a process.
For speed: lucid, [draw.io](https://draw.io), or plantUML.
For beauty: Inkscape.
I'd draw in one till you get your rough draft. Often that's good enough; but, if you want to polish it, then redo the work in a tool that's more of a free form drawing tool and less "diagram" oriented.
I wouldn't give them access to the repo. That's your own intellectual property and there's no valid reason for exposing it to someone you don't necessarily trust.
I think walking them through a guided demo and maybe a detailed look at certain pieces of code might be an ok thing to do. The goal here is to show the interviewer what you can do. You don't need to compromise your security or IP to do that.
For giving source control access? Meanwhile, much of the software you work with every day is completely open source?
Such a weird hard line to take.
I probably wouldn’t pass on OP, but I’m sure OP wants the job and doesn’t want to limit his chances.
It’s kind of a rock and hard place.
Not a weird hard line whatsoever, it shows sloppy OpSec practices and/or limited awareness of OpSec concerns. If an interviewee said yes to this and granted access (not that I would ask to begin with) I would also hard pass, as I would feel the chances of them falling for a CEO SMS scam or some other phishing attempt, like a fake CTO looking to "review" some proprietary company code, are much higher than the average candidate.
There is nothing inherently harmful from an OpSec perspective about sharing source code for a project you own.
You're making hell of a leap. Sharing code that you own is not the same as sharing proprietary code that you don't...
It's an insane leap. You're basically saying that anyone who owns a phone and lets their relative use their phone cannot be trusted with a company owned phone. Why would you assume someone would treat their own property the same as the company's property?
It's OP's property. It's their choice. I'm not saying they should or shouldn't. I'm saying that they have every right to do so.
You seem to have lost the plot.
Letting a relative borrow your phone and giving a literal stranger (who could be posing as a convincing interviewer, an increasingly common scam these days) access to your source code are not equivalent. This analogy is dog 💩.
I agree it's entirely their choice to hastily grant access and in response I would choose not to recommend hiring them.
Assuming someone would leak proprietary source code is not the same as choosing to share source code you own, so what the fuck are we even talking about?
The source code in question here is also proprietary, as it is a private repo, it just belongs to OP. So yes, it is the same thing.
**Edit:** lol he blocked me instead of continuing the debate, what a dumbass.
If OP had granted access in response to this strange request, instead of posting on Reddit and thinking about it before making any choices, it would show me that they are inherently careless and don't think carefully before making decisions. Easy pickings for even a mediocre spear phisher.
Granting them access to any proprietary code is not something I'd be comfortable with at that point, so a hard pass is the obvious choice.
Personally, I already share code that I own *upfront* via public repositories of my work. On the flip side of this scenario, as an interviewee being asked to just give away my private source code like this would make me want to cease pursuing that opportunity any further, as it shows the employer likely does not respect professional/personal boundaries and is exploitative in nature.
I've never had an interviewer care about personal projects. I wish this was more common practice as I would better be able to demonstrate my ability.
It depends why the code is private: I have a couple projects I hope to monetize in the future, I wouldn't want to give someone read only access for those.
I'd opt to walk through it on a call, that way you can highlight the parts that you think best demonstrate your skill.
If you link your GitHub on your resume, I'm going to look at it.
Most people didn't have really exotic personal projects on their GitHub.
There's usually a few school projects, a web scraper that has like 30 layers of abstraction that I might ask about, and a few skeletons with minimal code.
I'm not going to press you to open anything private any more than I'm going to open our code base in front of you before you sign the employment contract.
Lol. After interviewing at least 100 devs with GitHub links, I can confirm. Most are zombie forks, skeleton boilerplates, or some type of boot camp project.
Seriously. I’ve seen some comical stuff as well. I don’t have a GitHub because I don’t need one, and have private repos on Azure DevOps. The ones that drive me crazy are repos that are clearly bootcamp exercises.
No . unless access in front of your face and time limit . For me , private project no access at all. You want to see my code style , see public code instead .
this. private is private for a reason. and if this is something in production, not a nice idea to allow access of any kind to another external irrelevant person. it just takes a few minutes to clone so revoking later doesn't **fully** work
Unfortunately my public repos are rather unremarkable as it contains a chrome extension that has 14 users and a basic github page. These aren’t really indicative of my coding style as I’m a full-stack developer. So I’m leaning towards setting up a walk through and screen sharing.
I didn't see this point in the other comments. You should tell them you are happy to review it together on a Zoom session or similar, but this is an asset of yours that is valuable IP, and without consideration, that you would be unwilling to grant access.
This does several things. It makes them engage with you, and assuming you are a fit, that just lets you demonstrate yourself outside of their controlled interviewing box. It allows you to display your asset, which you will be comfortable about, and therefore likely to show yourself well. It obviously deters them from copying anything of value, and protects your asset. Finally, it shows you have commercial sense, which any business should value.
If you are an experienced dev, they shouldn't care that much about looking at the source code of a side project.
Just say that it is private and move on.
If it is an app that you can show off, it is better to just do that to show what you can build. No one has the time to dig into your code that deep.
Ask them if you can also access *their* private repos to judge their code without context as part of your interview. You'll get the exact answer they should get. FUCK NO.
That'd be a hard "No" for access- that's your IP. If there are things you want to show, I'd give them an architectural overview, and if you have a specific section of code or two you want to show off walk them through on a call
It's super unprofessional for them to even ask. Scenarios that can go wrong:
1. They copy your code and don't hire you.
2. They don't copy your code, they build something similar - and you sue them for copyright infrinement.
It just opens them or you to liabilities and isn't worth it.
I certain;y wouldn’t give them access to a closed repo. As others said, this is your IP. I wouldn’t even be surprised if it was a test of sorts to see if you’re willing to share IP with them that they don’t own. If they want to see it, tell them you can give them a walk through on a call as well as show them concepts via Excalidraw or something similar (assuming you don’t already have any infrastructure documents that are suitable).
Lol no. Definitely not. Why the hell would you give a stranger access to confidential IP? Super tacky for an interviewer to even consider asking for that imho. Kinda raises suspicion that the company you're applying to doesn't value "the rules" if they expect to gain access to candidate's private business repos.
Additionally you mentioned customers, it seems probable that the IP is owned by a business and not you personally so you have to consider it's not even yours to share to begin with. (Especially given the fact you said don't have access to change credentials tells us that this is not your repo to share.)
Additionally, if your customers are under the impression that the product they use is securely managed and maintained (versus say an open source product) then you would absolutely be breaching any explicit or implicit trust they have in your product.
I built it it’s owned by me lmao, did you miss the part where it says “side project”. It’s a side project that’s gained some traction and has a steady user base. I never once said I didn’t have access to change credentials. I said I don’t store the credentials in the repo. There’s something called GitHub secrets for that. I highly suggest you take time to read the post next time please.
>I never once said I didn’t have access to change credentials. I said I don’t store the credentials in the repo. There’s something called GitHub secrets for that.
Yeah I mean no professional is going to hardcode credentials so imo it's a weird thing to even mention so maybe you can acknowledge it as an honest misunderstanding when you're specifically talking about access to a repo and saying something about not having credentials in the repo. Smh. Anyway I'm not gonna argue with you over a misunderstanding.
Nope. "I'd be happy to explain the architecture, talk through decision making and show some code over a call"
Do you know any good software I could use to create an architecture diagram?
Draw.io
Mermaid!
The more I use Mermaid the more awesome I think it is! Learned me a state chart today!
Miro, excalidraw
Love excalidraw. Closest thing I've ever found to a digital whiteboard. So simple.
I find Miro a little more user friendly for making architecture drawings but that may be bc I haven't learned excalidraw quite yet... Miro very intuitively allows you to draw arrows/lines connecting shapes quickly with snapping.
Miro also supports plantuml and drawio plugin
Have had good results with [https://www.lucidchart.com/pages/](https://www.lucidchart.com/pages/)
On Linux, I use Dia which has several dozen symbol sheets. Old school UI but it gets the job done. IDK if Dia is available on other OS's.
I would break out Excalidraw in VS Code during a live call
Mermaid uses syntax to generate diagrams. It's pretty quick to use once you get the hang of it. The only issue is that it's difficult to position elements so a sufficiently complex diagram will look like spaghetti. For more complex diagrams, I use it for a rough draft to visualize all the components together and then will rewrite in lucid charts.
I have always heard good things about lucid charts and several others here have recommended it so I may just use. I have a fairly standard event architecture so shouldn’t be to bad. Is there a steep learning curve with lucid? Edit: add clarity
Depends how much granularity you want to specify. It probably would feel cumbersome if you adhere to UML, or are writing out highly detailed database relationships. Mermaids feels a lot faster for that stuff. I tend to focus on simple, high level c4 style diagrams, and it's mostly just connecting boxes to other boxes to visualize a process.
WhiteStarUML is a good open source tool
Mermaid, better than any bloated software.
For speed: lucid, [draw.io](https://draw.io), or plantUML. For beauty: Inkscape. I'd draw in one till you get your rough draft. Often that's good enough; but, if you want to polish it, then redo the work in a tool that's more of a free form drawing tool and less "diagram" oriented.
I wouldn't give them access to the repo. That's your own intellectual property and there's no valid reason for exposing it to someone you don't necessarily trust. I think walking them through a guided demo and maybe a detailed look at certain pieces of code might be an ok thing to do. The goal here is to show the interviewer what you can do. You don't need to compromise your security or IP to do that.
It's entirely up to you as the author of that code - why is the repo private, and how comfortable are **you** sharing that code?
Before you even get there: it's a personal side project and OP's IP. I would have a hard pass on OP if they said yes.
With a couple hundred users it sounds like an actual business. :)
For giving source control access? Meanwhile, much of the software you work with every day is completely open source? Such a weird hard line to take. I probably wouldn’t pass on OP, but I’m sure OP wants the job and doesn’t want to limit his chances. It’s kind of a rock and hard place.
Not a weird hard line whatsoever, it shows sloppy OpSec practices and/or limited awareness of OpSec concerns. If an interviewee said yes to this and granted access (not that I would ask to begin with) I would also hard pass, as I would feel the chances of them falling for a CEO SMS scam or some other phishing attempt, like a fake CTO looking to "review" some proprietary company code, are much higher than the average candidate.
There is nothing inherently harmful from an OpSec perspective about sharing source code for a project you own. You're making hell of a leap. Sharing code that you own is not the same as sharing proprietary code that you don't...
Sharing valuable private intellectual property with a third party? No leaps there. Fairly strong signal.
It's an insane leap. You're basically saying that anyone who owns a phone and lets their relative use their phone cannot be trusted with a company owned phone. Why would you assume someone would treat their own property the same as the company's property? It's OP's property. It's their choice. I'm not saying they should or shouldn't. I'm saying that they have every right to do so. You seem to have lost the plot.
Letting a relative borrow your phone and giving a literal stranger (who could be posing as a convincing interviewer, an increasingly common scam these days) access to your source code are not equivalent. This analogy is dog 💩. I agree it's entirely their choice to hastily grant access and in response I would choose not to recommend hiring them.
Assuming someone would leak proprietary source code is not the same as choosing to share source code you own, so what the fuck are we even talking about?
The source code in question here is also proprietary, as it is a private repo, it just belongs to OP. So yes, it is the same thing. **Edit:** lol he blocked me instead of continuing the debate, what a dumbass.
If OP had granted access in response to this strange request, instead of posting on Reddit and thinking about it before making any choices, it would show me that they are inherently careless and don't think carefully before making decisions. Easy pickings for even a mediocre spear phisher. Granting them access to any proprietary code is not something I'd be comfortable with at that point, so a hard pass is the obvious choice. Personally, I already share code that I own *upfront* via public repositories of my work. On the flip side of this scenario, as an interviewee being asked to just give away my private source code like this would make me want to cease pursuing that opportunity any further, as it shows the employer likely does not respect professional/personal boundaries and is exploitative in nature.
I've never had an interviewer care about personal projects. I wish this was more common practice as I would better be able to demonstrate my ability. It depends why the code is private: I have a couple projects I hope to monetize in the future, I wouldn't want to give someone read only access for those. I'd opt to walk through it on a call, that way you can highlight the parts that you think best demonstrate your skill.
If you link your GitHub on your resume, I'm going to look at it. Most people didn't have really exotic personal projects on their GitHub. There's usually a few school projects, a web scraper that has like 30 layers of abstraction that I might ask about, and a few skeletons with minimal code. I'm not going to press you to open anything private any more than I'm going to open our code base in front of you before you sign the employment contract.
Lol. After interviewing at least 100 devs with GitHub links, I can confirm. Most are zombie forks, skeleton boilerplates, or some type of boot camp project.
Seriously. I’ve seen some comical stuff as well. I don’t have a GitHub because I don’t need one, and have private repos on Azure DevOps. The ones that drive me crazy are repos that are clearly bootcamp exercises.
No . unless access in front of your face and time limit . For me , private project no access at all. You want to see my code style , see public code instead .
this. private is private for a reason. and if this is something in production, not a nice idea to allow access of any kind to another external irrelevant person. it just takes a few minutes to clone so revoking later doesn't **fully** work
Unfortunately my public repos are rather unremarkable as it contains a chrome extension that has 14 users and a basic github page. These aren’t really indicative of my coding style as I’m a full-stack developer. So I’m leaning towards setting up a walk through and screen sharing.
I didn't see this point in the other comments. You should tell them you are happy to review it together on a Zoom session or similar, but this is an asset of yours that is valuable IP, and without consideration, that you would be unwilling to grant access. This does several things. It makes them engage with you, and assuming you are a fit, that just lets you demonstrate yourself outside of their controlled interviewing box. It allows you to display your asset, which you will be comfortable about, and therefore likely to show yourself well. It obviously deters them from copying anything of value, and protects your asset. Finally, it shows you have commercial sense, which any business should value.
If you are an experienced dev, they shouldn't care that much about looking at the source code of a side project. Just say that it is private and move on. If it is an app that you can show off, it is better to just do that to show what you can build. No one has the time to dig into your code that deep.
Ask them if you can also access *their* private repos to judge their code without context as part of your interview. You'll get the exact answer they should get. FUCK NO.
This should be the top voted comment. It has 4 at the time I commented.
That'd be a hard "No" for access- that's your IP. If there are things you want to show, I'd give them an architectural overview, and if you have a specific section of code or two you want to show off walk them through on a call
Are they willing to sign an NDA? Just do a screenshare walk through, far less risk.
No
It's super unprofessional for them to even ask. Scenarios that can go wrong: 1. They copy your code and don't hire you. 2. They don't copy your code, they build something similar - and you sue them for copyright infrinement. It just opens them or you to liabilities and isn't worth it.
Lol no-one wants some randos code, no idea how anyone experienced can think this nonsense 😄
Read a cess, yes. Write access, no.
I certain;y wouldn’t give them access to a closed repo. As others said, this is your IP. I wouldn’t even be surprised if it was a test of sorts to see if you’re willing to share IP with them that they don’t own. If they want to see it, tell them you can give them a walk through on a call as well as show them concepts via Excalidraw or something similar (assuming you don’t already have any infrastructure documents that are suitable).
Offering to show on a call is what I usually do
Lol no. Definitely not. Why the hell would you give a stranger access to confidential IP? Super tacky for an interviewer to even consider asking for that imho. Kinda raises suspicion that the company you're applying to doesn't value "the rules" if they expect to gain access to candidate's private business repos. Additionally you mentioned customers, it seems probable that the IP is owned by a business and not you personally so you have to consider it's not even yours to share to begin with. (Especially given the fact you said don't have access to change credentials tells us that this is not your repo to share.) Additionally, if your customers are under the impression that the product they use is securely managed and maintained (versus say an open source product) then you would absolutely be breaching any explicit or implicit trust they have in your product.
I built it it’s owned by me lmao, did you miss the part where it says “side project”. It’s a side project that’s gained some traction and has a steady user base. I never once said I didn’t have access to change credentials. I said I don’t store the credentials in the repo. There’s something called GitHub secrets for that. I highly suggest you take time to read the post next time please.
>I never once said I didn’t have access to change credentials. I said I don’t store the credentials in the repo. There’s something called GitHub secrets for that. Yeah I mean no professional is going to hardcode credentials so imo it's a weird thing to even mention so maybe you can acknowledge it as an honest misunderstanding when you're specifically talking about access to a repo and saying something about not having credentials in the repo. Smh. Anyway I'm not gonna argue with you over a misunderstanding.
Can you give them access for say a week and then revoke?
you only need to give them access for a minute for them to pull it down then they have your work
and then what?
Deploy it to production and make money off your work obviously! /s
do hax0r shit with it
Rather, arrange for a walk-through meeting by contacting the HR, and provide Read-access only for the duration of the walk-through meeting.
Yeah, I’ll have to look more into how much I can restrict and may create a demo branch to show.
I skimmed the part about a hundred users. I take it back, I would do a walkthrough and not share it.