Oneleet (YC S22) | Multiple Roles | US & NATO Countries | Remote | Full-time
Oneleet is an all-in-one cybersecurity startup that has built its own Attack Surface Monitoring (ASM), Code Scanner, Device Monitoring, and Compliance Platform. We are growing at an unprecedented pace and working on some very exciting projects.
What we're looking for:
Strong problem solvers who can work independently in a remote environment - Security-minded professionals passionate about building robust, scalable systems - Comfortable working during Eastern Time
Tech stack: Go, TypeScript, React, Kubernetes
Open roles:
* Senior Software Engineer (Backend)
* Security Program Manager
* Internal Security Compliance Auditor
* Technical Sales (must have background in Computer Science or Cybersecurity)
* Invoicing Coordinator
We offer:
- Competitive salary - Equity in a fast growing cybersecurity startup - 100% remote work - Company offsites every quarter (past offsites have been in The Netherlands and Italy)
If you're interested in joining our team, please reach out to samuel<at>oneleet<dot>com with the subject line "HN: <Job Title>". If you have already applied but haven't heard back, feel free to follow up on the thread, things have been super busy!
Oneleet (YC S22) | Multiple Roles | US & NATO Countries | Remote | Full-time
Oneleet is an all-in-one cybersecurity startup that has built its own Attack Surface Monitoring (ASM), Code Scanner, Device Monitoring, and Compliance Platform. We are growing at an unprecedented pace and working on some very exciting projects.
What we're looking for:
Strong problem solvers who can work independently in a remote environment - Security-minded professionals passionate about building robust, scalable systems - Comfortable working during Eastern Time
Tech stack: Go, TypeScript, React, Kubernetes
Open roles:
* Senior Software Engineer (Backend)
* Security Program Manager
* Internal Security Compliance Auditor
* Technical Sales (must have background in Computer Science or Cybersecurity)
We offer:
- Competitive salary - Equity in a fast growing cybersecurity startup - 100% remote work - Company offsites every quarter (past offsites have been in The Netherlands and Italy)
If you're interested in joining our team, please reach out to samuel<at>oneleet<dot>com with the subject line "HN: <Job Title>". Alternatively, you can also apply at https://www.ycombinator.com/companies/oneleet/jobs
I have always said that you can gain more value from self-help/life management type books by reading the table of contents and then spending the time you would have read the book just thinking about those topics and coming to your own conclusions.
This is obviously a bit hyperbole but seriously most self help books could be an article instead and I wouldn't miss anything that was cut
Yeah most self-help books start off as viral articles, popular newspaper editorals, or conference talks, and publishers will then approach the creators of these ideas and ask them to write a book about it.
The formula is simple, the idea you presented has already demonstrated itself as extremely popular. But only a thousand people can attend that conference, let's print it as a book and sell it in airports, websites, and stores around the world as a nice packaged book that everyone can buy and it will surely be just as popular but we can sell it to more people.
But then the problem. Writing down the original idea only takes a few pages, maybe 10-20. So we let the author expound a little, which brings it up to 80 pages. But still no one is going to pay $20 for an 80 page book, so the publishers ask them to break small sub-concepts into entire chapters to get to the magical 275-325 page mark that 95% of books sell at. These fit into shipping boxes well, every store bookshelf is designed around this size, even US Postal Service's "Media Mail" is optimized around this sizing.
So in the end, you are left with most self-help books being extremely padded to get to the the standard mass-market-paperback size. So books that should be long blog posts or a 15 min presentation get dragged out into 275 page epics where it becomes clear by the end that the author has ran out of stuff to say and is just filling the page count.
One great example right now is the top-selling book: "The Subtle Art of Not Giving a F$&#". I highly recommend everyone go to the nearest bookstore and read the first introduction and first chapter. They are absolute gold. The author summarizes the whole book in about 20 pages and does an excellent job. It is well written, entertaining, and enlightening. Everything you want in a good book. But then you can put the book down and walk away. Because the next 225 pages are just rehashing the same thing from the first chapter. Repeating itself. The author is clearly trying to reach the minimum 250 page count that the publisher will allow. He is grasping at straws and just re-iterating the same basic concept for 80% of the book. Sadly most self-help books are the same thing. Great concepts that need to be 20-50 pages.
The very first test can be a simple "Did my HTTP request receive a response?". Then you can build on "Does this HTTP response have this value I need"....
etc
The way I have always gone about TDD is just that I am testing the code I am writing by running the test, not from the main entrypoint of the application. The things you would log and look for when you run the application you instead validate with an `assert()`. Then once you have finished developing, you do a single pass verification from main and you have both a test and a function written
Do you see how playing this game of writing iterative tests would actually provude slower learnings than prototyping a call to an API and receiving a result that would inform a series of tests that would be much more informed?
It's just as easy to be inefficient writing useless/bad tests than it is writing bad code. I think every developer should do TDD in their career, because it will make you think about the testability of the code. That said once you understand how to write testable code than I think it makes sense to be flexible on whether you write the test first or take a crack at an implementation.
The argument that you should have a good understanding of requirements I think leads to a lot of analysis paralysis, and isn't a practical method for building novel things in a timely manner.
I think the key distinction here is "run my new function through the entry point of the application" vs "run my new function from a test". You leave out whatever startup time is involved from the rest of the application to get to that function, & you have a tiny feedback loop to test the function.
You have your test which gets the response, and you can still log the output to see what it looks like. It's a little slower at first since you have to write the test, but I'm not sure I see a big distinction vs "have a small script that sends the request".
> Do you see how playing this game of writing iterative tests would actually provude slower learnings than prototyping a call to an API and receiving a result that would inform a series of tests that would be much more informed?
And do you see that in many examples just coding ahead without conaidering how to test the code later will in many cases leave you with code that is such a pain to test that you start avoiding the tests because "they take too much time".
If you start with the test the question of "how can this be made testable" is unavoidable.
I am not dogmatic here. If you are operating on the level of "I am happy if anything works at all" then starting with writing a test is probably a bad idea, better try things out first, scrap the whole thing once you understood what you wanna do in which way and then start writing the tests.
For a lot of adhoc code test driven development doesn't make too much sense, but if the stuff you write could ruin someones day (or life) maybe it is the way to go.
I think that while storing a TOTP in your password manager is less secure than using an external app, I also feel like this is missing a large portion of when I am storing a TOTP in Bitwarden - shared accounts.
Being able to store a TOTP in my password manager allows me to have a shared account still use 2FA - and provided all parties also have 2FA on their Bitwarden accounts I think this is a pretty secure system and much preferable to one party having TOTP and everyone else needing to email or message them to get the code. Especially considering that as the number of "Hey can you send me the code to log in real quick" messages the 2FA holder gets goes up, the likelihood they get complacent and just start automatically responding could also create a threat vector.
This must be regional because I have been using a chip-and-pin card for the last 5 years and I cannot for the life of me remember the last time I had to physically swipe the card. Tap support is definitely still spotty but that is something that is more of a convenience than a security issue
I also can't remember the last time I had to swipe a card where I am in the US. I also prefer using Apple Pay, and tbh, can't remember the last time I had to use my physical card.
It's still relatively common to have to swipe cards at gas stations in the US when you're buying gas. And a fair amount of the parking meters may still be on swipe (NYC meters outside of Manhattan come to mind). The places that haven't upgraded are ones with a lot of POS stations to upgrade.
Yep these two places are very common to be swipe only. I have to go a human teller at <massive and famous hospital> to pay for parking and the cc machine will still only read swipes.
This is something I have come to realize I unconsciously have gotten very dependent on - MacOS let's you swap virtual desktops for the monitor you are currently focused on without swapping any of the others. I never realized how intuitive this is until switching back to my XFCE linux installation and getting very frustrated with virtual desktops entirely. I might have to give dwm a try again on my linux machine if it supports this.
OS X has the same issue as a lot of other VMs. You can not simply have a single pool of workspaces and chose to view any N of them, where N is the number of monitors that you have. In OS X you can have workspaces on your left monitor, and workspaces on your right monitor, but you can't easily share the workspaces between the monitors without re-arranging them.
The only WM I have used that gets virtual desktops right for multi monitors is xmonad. Maybe dwm can work the same way, not sure.
In xmonad you can have 10 workspaces and 2 monitors, and pull up any workspace on any monitor. You can have hotkeys to cycle workspaces on either monitor independently and a key to swap the two monitors.
I would actually disagree - to me you can have "decent separation of concerns in your code" but still have only built the app to support a single entry point. "Modular monolith" to me is a system that is built with the view of being able to support multiple entry points, which is a bit more complex than just "separating concerns"
If your concerns are well separated in a monolith (in practice this means being able to call a given piece of functionality with high confidence that it will only talk to the data stores/external resources that you expect it will), adding new entry points is very easy.
Now, it's not trivial--going from, say, a do-everything webserver host to a separation of route-family-specific web servers, background job servers, report processing hosts, and cron job runners does require work no matter how you slice it--but it's a more or less a mechanical or "plumbing" problem if you start from a monolithic codebase that is already well behaved. Modularity is one significant part of said good behavior.
Oneleet is an all-in-one cybersecurity startup that has built its own Attack Surface Monitoring (ASM), Code Scanner, Device Monitoring, and Compliance Platform. We are growing at an unprecedented pace and working on some very exciting projects.
What we're looking for:
Strong problem solvers who can work independently in a remote environment - Security-minded professionals passionate about building robust, scalable systems - Comfortable working during Eastern Time
Tech stack: Go, TypeScript, React, Kubernetes
Open roles:
* Senior Software Engineer (Backend)
* Security Program Manager
* Internal Security Compliance Auditor
* Technical Sales (must have background in Computer Science or Cybersecurity)
* Invoicing Coordinator
We offer:
- Competitive salary - Equity in a fast growing cybersecurity startup - 100% remote work - Company offsites every quarter (past offsites have been in The Netherlands and Italy)
If you're interested in joining our team, please reach out to samuel<at>oneleet<dot>com with the subject line "HN: <Job Title>". If you have already applied but haven't heard back, feel free to follow up on the thread, things have been super busy!
Alternatively, you can also apply at https://www.ycombinator.com/companies/oneleet/jobs