Sorry for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks.
I shared the root cause in a sibling comment and am forwarding it here:
Below are more details---
Issue 1. Table with a link overlay in every cell I initially used an off shelf table component to move fast and didn't take a closer look at the implementation. It turned out this component renders a link overlay in every cell to allow user to click table row to be taken to the job link. So 400 jobs with 6 rows end up rendering 2400 link overlays.
The reason it attaches a link overlay to a cell instead of a row is due to a well known bug with Safari, where you can't use `position: relative` in table row `tr` https://bugs.webkit.org/show_bug.cgi?id=240961. Attaching it to each cell works for small number of rows but causes performance issues with large number of rows.
I fixed it by rolling out my own table with css grid instead. It is not as semantic as it no longer uses table, thead, th, tr, td, but thanks to Safari, it is a tradeoff I am okay with.
Bug 2. Unnecessary re-render on Zustand store rehydrate I used Zustand store to filters preference and save it to browser's local storage. On page load, it fetches from local storage to update the state or store rehydrate . I didn't use shallow comparison initially and caused the table to render even if the prev and new state is an empty array due to comparison by reference. Using shallow comparison minimize an unnecessary render.
Sorry again for the lag. I just fixed 2 bugs (table and store hydration) that should massively improve it if you would like to try again. Thanks
The animation stops because it gets blocked and appears to be locked up due to an issue with the table taking too long to render and another bug causing the table to re-render again.
Thanks again for your note! You are totally right that something is wrong. I took a closer look and fixed 2 issues that should massively improve the performance now if you would like to try again.
Below are more details---
Issue 1. Table with a link overlay in every cell
I initially used an off shelf table component to move fast and didn't take a closer look at the implementation. It turned out this component renders a link overlay in every cell to allow user to click table row to be taken to the job link. So 400 jobs with 6 rows end up rendering 2400 link overlays.
The reason it attaches a link overlay to a cell instead of a row is due to a well known bug with Safari, where you can't use `position: relative` in table row `tr` https://bugs.webkit.org/show_bug.cgi?id=240961. Attaching it to each cell works for small number of rows but causes performance issues with large number of rows.
I fixed it by rolling out my own table with css grid instead. It is not as semantic as it no longer uses table, thead, th, tr, td, but thanks to Safari, it is a tradeoff I am okay with.
Bug 2. Unnecessary re-render on Zustand store rehydrate
I used Zustand store to filters preference and save it to browser's local storage. On page load, it fetches from local storage to update the state or store rehydrate . I didn't use shallow comparison initially and caused the table to render even if the prev and new state is an empty array due to comparison by reference. Using shallow comparison minimize an uncessary render.
I guess it increases your shots if the company is actively hiring. I can't speak to others, but that is actually how I and some of my friends land remote jobs, just by cold applying. And you get more chance if you apply early as soon as the post is up the first day or two.
Of course, as you said, it is more effective if you have connections or have gotten cold outreach by recruiters. But my point is that cold applying still works and quite some folks land their jobs this way.
Sorry for the lag. I just fixed 2 bugs that should massively improve it if you would like to try again. Look forward to any feedback/suggestion you might have. Thanks
Sorry for the lag. I just fixed 2 bugs that should massively improve it if you would like to try again. Look forward to any feedback/suggestion you might have. Thanks
Yes, different companies define levels differently. Microsoft's principal and Linkedin's staff can be a senior in another company, hence why I include the yoe as it says more about the requirements. Also, Microsoft's salary is in the low end compared to other companies in similar role and yoe, but salary is only one factor I suppose. They historically offer better wlb in general, though this might vary teams from teams.
Thanks for your kind words! I haven't offered any public feed/api yet. Your project looks very cool. Will look more into it and circle back if I open up integration.
Do you work in a tech company or non-tech company?
I have a related question and answer in the FAQ page and am attaching it here:
---
3. What does “best paying” mean?
Different types of company pay software engineer at different bands. The best paying companies are usually tech companies, where tech is the core competency of the business and software engineers are first class citizens who play a key role in building the core products, e.g. FAANG, Dropbox, Pinterest, etc. These companies pay top of market to attract top talents and build high quality software.
This differs from non-tech companies whose core competencies aren’t necessary tech but other areas. For example, a newspaper company like NY Times values editorial content over software, and an information provider like WebMD values medical expertise more.
Tech companies pay 2-3x more than non-tech companies for similar roles, and they are the focus of the RemoteSWE.fyi listing.
To learn more about compensation differences across the industry, Gergely Orosz’s Trimodal Nature of Tech Compensation is a great resource.
A key goal of the job board is to allow candidates to see which companies are hiring and which positions are open. This is the most important thing to start with.
What strategy a person use to apply would vary. An experience individual would reach out to their contacts who work in those companies for a referral or find ways to reach out the hiring recruiter or manager to increase their odds of success/interview for reasons you said due to high competitions and candidate pools. On the other hand, for companies actively hiring and with many openings, e.g. Coinbase at the moment, a simple cold apply works just fine to get you to the door of interview.
Some remote companies such as Atlassian, Affirm, Dropbox have different pay zones to offset the cost of living in various places.
For example, in Atlassian https://www.atlassian.com/company/careers/resources/intervie..., the 3 pay zones are
- Zone A: SF
- Zone B: Boston, LA, NYC, Sacramento, San Diego, Seattle, Washington D.C.
- Zone C: all others
Zone B is 90% of Zone A's pay and Zone C is ~82% of Zone A's pay.
Agree that company willing to accept remote work has a broader talent supply and can be an advantage in hiring talents not in the big tech cities. I am not sure if it necessarily lead to lower labor cost due to competitions with other remote companies also hiring in those regions. Competitions would help keep the labor cost up.
Thanks for sharing the industry insights! Very cool to learn about CPC job distribution, etc.
I have also read the LinkedIn vs. hiQ Labs lawsuit. The ruling is significant because the court finds that scraping public data did not violate the CFAA, though it violated LinkedIn's tos. LinkedIn ultimately wins at the end because hiQ was bankrupted. One of my take away is to scrape responsibly by rate limiting the requests and not overloading the server, etc
The goal of the companies and recruiters is to fill open positions with qualified candidate asap, hence why some would even pay job boards to promote their jobs or offer referral bonus. So my take is that companies would love job boards like this to freely advertise their positions to folks who might not otherwise come across these positions and increase their top of funnels. So in this case, the incentive of aggregators and companies are aligned and it is a win-win situation for both.
I don't know why a company might not want to partake in this, but would be happy to take it down upon their request if they like to make it more difficult for candidates to stump upon their openings.
Thanks for the feedback. I was deciding between SWE and dev and went with SWE after consulting with ChatGPT as SWE fits the job setting better
> SWE (Software Engineer) vs. Dev (Developer)
> SWE: Typically more formal; often implies engineering discipline like system design, scalability, testing. Broader + deeper in scope
> Dev: Informal short form of “developer”; can refer to any kind of coder. More general or casual.
> "Software Engineer (SWE)" → Signals higher-quality, well-compensated roles, especially to experienced professionals. Many top-paying U.S. companies prefer this title.
I am not too familiar with Europe, but a remote job usually ties to a specific country, likely due to tax or some regulations. Another reason is that different country in the same continent has different cost of living and salary band, etc.
For some of these reasons, it might explain why while there is remote job in US or Canada or Mexico, there is no remote job for North America, the continent for these 3 countries. This might help explain why there isn't a remote job for Europe as it is a continent.
Haven't said this, it seems to be a great advantage for companies who can overcome the challenge and offer remote for Europe if it is an appealing offer.