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!
@sheerlox is building a rather feature-complete skills normalization API with Elixir to be consumed by ATS systems and recruitment agencies. I’m not affiliated to his project but maybe it could be of interest to you ?
Your site is using relative oklch colors, which is not supported until safari 18. I purposely keep my Mackbook at Catalina to evade gatekeeper, therefore, almost no color with safari
When use with reasonably updated Firefox or Chrome (tested on both MacOS and Windows). the box to input email is black text on black background, which is very confusing.
The mail sending service you use, mlsend.com, is taking a very long time to send the confirmation email, newly 10 minutes in my case. I run my own SMTP server so all delay must be caused by the sender.
Thanks for your feedback, I really appreciate people taking the time to give it
Your site is using relative oklch colors, which is not supported until safari 18. I purposely keep my Mackbook at Catalina to evade gatekeeper, therefore, almost no color with safari
When use with reasonably updated Firefox or Chrome (tested on both MacOS and Windows). the box to input email is black text on black background, which is very confusing.
I am on Linux, no access to MAC, but access to my wife Windows dekstop. I need to figure out a fix. Thanks for reporting.
The mail sending service you use, mlsend.com, is taking a very long time to send the confirmation email, newly 10 minutes in my case. I run my own SMTP server so all delay must be caused by the sender.
I use MailerLite and their status page indicates everything is operational. In my tests it has been very fast to send the confirmation email. Maybe it was a temporary issue when you have a subscribed
It sounds like your project aims to provide an interface for talent and employers. To be successful you will need to attract both. People are generally going to act like electricity – follow the path of least resistance. As such I would think your goal should be lowering the resistance for both parties. This may be too big of a problem to take on, but ideally your app would include a tool to take in whatever format the recruiters submit and parse it/transcribe it to match the standardized format then present that sanitized version to the submitter before publishing it. I think if you expect recruiters to have a special format for your service when they can submit their familiar format to a dozen other job sites you’ll find few takers.
As someone looking for a new role for months, I can say the current state of job boards is a mess and makes everyone’s life looking for a role more difficult than needed. Too much text to parse just to understand if the job may be of interest or not, and this is exactly what I want to change.
I am aware that most resistance will come from recruiters and employers filling out the form.
I thought of two options: an API to add the job specs with the BEAM Devs structured format and a tool to publish their job spec to other portals to alleviate or eliminate their resistance to using the BEAM Devs format.
Parsing a free text format isn’t something I am inclined to pursue because that is too complex and will miss a lot of the things I want to achieve.
I understand that this will impact adoption, but I am willing to take the risk and bet on the BEAM community to create their profile at BEAM Devs to make the app the go-to place to find talent and network in the BEAM world, thus forcing recruiters and employers to adopt the BEAM Devs format to find the best talent they are looking for.
It’s a long shot but achievable if the majority of the BEAM community creates their professional profile in the BEAM Devs app.
Currently I am at 100 subscribers for early access and updates, and if I arrive 1000 subscribers I will be willing to take the risk.
I agree with this but I can’t say that this is strictly related to the format of the job posting. The last 3 years I’ve applied to a huge amount of elixir jobs and I can say that it is very rare that the initial description of the job, no matter the format, conveys anything useful or reflects the truth about what is happening in that company. Most of them are made by managers that have vague idea about the development process or they hide it on propose to not scare people off.
My approach was to try to secure a 5 minute call where I can ask all the questions that I know will surface the red flags I am looking to avoid. Nowadays, either because of automated spam of applications or just so many folk trying to apply for a job this is not working out, which is pretty sad, because I find that to be one of the most effective method for both parties.
Pretty much a mix of those, highly depending on the situation, project, role etc.
The questions in my case aim to align with my personal goals for a job for example:
clear responsibilities - this one got me by surprise at my last job, where I was forced to do things starting from jira integrations to making deploy and CI pipelines from scratch as an elixir developer (especially since I was paid a mediocre salary to begin with). Your best bet about finding this stuff is actually talking with a developer that no longer works with that company, as getting straight answers out of them directly might be difficult;
no micromanagement - here you can ask about the amount of meetings and if async communication is favored over sync, this kind of question also surfaces projects that are in terrible state, as those tend to lean heavily on calls where somebody else explains things to you all day long;
the level of ownership - asking about their delivery process, especially who makes the last decision when it comes to estimates and what should be focused on. Companies that hire good developers and trust them, leave up to developers to take the decision where corners should be cut and where this is not acceptable.
And the list goes on. For me for example, places that allow time to implement good software and do code improvements and refactors are more important than places that pay a high salary but demand you to develop at the edge of your capabilities, where that codebase is in such a horrible state, that you stay and debug for hours on deployed systems. I would gladly accept a lower salary, as in the long-term that option is more sustainable.
I would even go as far as to say that every step in the nowadays hiring of a developer is beyond broken. I can say without a doubt that passing a interview for an elixir job is harder than the actual job in 90% of cases, which is an extremely sad state of affairs.
BTW there is elixirdevs.com that was released a few years ago.
I am not sure about its current status, but I’ve received exactly zero messages after registering my developer profile there shortly after its release.
Maybe you could contact them to get insight on what is going on?
I debug a bit on the color problem in Safari 15.6. You are using Tailwind 4. Tailwind 4 chooses to specify colors as oklch(.967 .003 264.542) This is legal according to the live W3C spec. However, Safari 15.6 only supports oklch notation like oklch(96.7% .003 264.542). Luminance has to be specified in percentage. This subtle difference is not even documented on caniuse.com
I have a computer with older Firefox from early 2023, it also behaves this way. So I don’t think it is a Safari only problem. The spec moves.
RANT: I am glad that I gave up on Tailwind long time ago.
