I have had too much free time since my layoff last year, and after several attempts at bootstrapping other projects, web apps, an Elixir tool, and a BEAM book, I decided to build BEAM Devs:
The project aims to serve as a gateway to everything BEAM related, not as a replacement for something like this forum.
In a nutshell, I want to create a network where developers and companies using Elixir, Erlang, Gleam, and more can come together to share experiences, learn, build, find talent, and grow the BEAM ecosystem.
If the project is successful, it will give back to the community by sponsoring other Open Source BEAM projects and encouraging companies and individuals to do the same:
If this project resonates with you, please visit the website and subscribe for updates to encourage me to continue building it.
My target is 1,000 subscribers by the end of March. Otherwise, I will assume the community doesn’t have enough interest in the project. So if you want it to become a reality, just hit that subscribe button!
Feel free to ask any questions, give feedback and make suggestions
For the future jobs board at BEAM Devs, the aim is to have job descriptions made up of bullet points that are easy to read, without the need to parse the fluffy text we usually see in job descriptions.
This approach will also enable both candidates and companies to specify filters to refine their search criteria, saving time for everyone involved by providing more relevant results for what they are looking for.
Job seeking ends up becoming a full-time job for unemployed people, and I have been experiencing this since my layoff. I quickly got tired of boring job descriptions full of fluff designed to sell the company and the role, making it hard for me to spot at a glance whether the role aligns with my experience and what I am looking for.
To me, job descriptions should focus on what matters and be presented as a list of bullet points to make it easier to find, but not limited to, the following:
Clear and specific job title: Elixir Backend Software Engineer instead of just Software Engineer or something vague.
Career Level: Principal, Staff, Senior, Mid-level, Junior, Graduate, Apprentice
Remote, Hybrid or on-site
Skills required, desired and optional, including proficiency levels and how they will be used in the role.
Business scope of the role in a few words: e.g., Working on the backend of a B2B fintech app.
List up to five reasons why a candidate should apply to this role and company in very short sentences (up to 80 characters).
Links to relevant company pages: About, Careers, Values, Mission, Job Description, Handbook and Social Networks.
Salary range with a realistic lower and upper band.
Number of hours per week.
Work week length: Four or five days.
Flexible or fixed working hours.
Synchronous or asynchronous working methodology.
Holidays: Flexible (from 20 to 90 days) or a fixed number of paid time off (PTO) days. Unlimited PTO is a lie.
Clearly defined expectations for the candidate after 1 month, 3 months, and 6 months in the role.
Performance reviews frequency.
Salary reviews frequency and if they are attached to performance reviews.
Probation period duration.
Termination notice in days for both the company and employee during probation and after it.
Benefits, both legally required and optional.
Perks.
This isn’t an exhaustive list, and I welcome feedback on it with suggestions to improve it.
Visit the website and subscribe to updates for early access as Alpha and Beta tester:
I completely agree with such a rigid system, however I suppose you (or someone else) will be the one that will have to enforce it, as a lot of HRs/managers who hire cannot be bothered to respect a clear format.
It will be enforced at the time they fill out the form to create the job description on the app.
The same will apply when creating developer, company, and recruiter profiles.
To be clear, the form fields for free text will be very few and very limited in size. When they do exist, it will be to add additional context to a form field, such as explaining how a required skill will be used in the role.
I applaud your initiative, man. I am just fearful that a lot of HR and generally recruiting personnel prefer to keep things obscure. Hopefully that does not turn out to be true. Hopefully I am wrong.
Because otherwise it would be an amazing progress in the area – after an ATS system is added on top as well, that is.
Thanks for the feedback. You made some good points.
The intention is to use rigid form fields with a selection of predefined options for each field, which will allow to build a simple ATS for developers, companies, and recruiters. Everyone will be playing more or less on the same field.
Applying to a job will also be straightforward, with no need for cover letters or CVs, as candidates will already have profiles that employers can consult. Due to the structured nature of both profiles and job descriptions, a compatibility score between the candidate and the role can be provided to both parties.
If the entire community embraces the project, both developers and companies, the pool of profiles for finding talent and opportunities will become too significant to be ignored by developers, companies, and recruiters alike.
I expect the biggest resistance to come from recruiters and companies in adopting the rigid job description fields. However, if they realise that the candidate pool is worth the effort, they will eventually change their minds,hopefully!
