josecodea

SEEKING WORK | Remote | WORLDWIDE

Freelance Web Developer. Full-stack. With a decade of experience as SDE.

Location: Costa Rica (LATAM).

Remote: Yes, any timezone (I reside in CT/UTC-6, EST/CST timezones).

Languages: Spanish, English.

Programming: TypeScript, Rust, Elixir, Clojure, NixOS, AWS, Docker, NodeJS, Deno, ReactJS. SolidJS & SolidStart to a high degree.

Portfolio: https://www.josecodea.com

Email: Refer to the bottom of my portfolio.

Proof of work with Elixir:

- My portfolio includes Open Source contributions.

Proof of work with Rust, NixOS and Docker:

- My portfolio includes two blog posts, each include a small Rust app that I made to turn on/off an EC2 server with a Discord bot.

I also have this question, ads for remote should include either timezone requirements or geographical requirements, otherwise everyone wastes their time

SEEKING WORK | Remote | WORLDWIDE

Freelance Web Developer. Full-stack. With a decade of experience as SDE.

Location: Costa Rica (LATAM).

Remote: Yes, any timezone (I reside in CT/UTC-6, EST/CST timezones).

Languages: Spanish, English.

Programming: TypeScript, Rust, Elixir, Clojure, NixOS, AWS, Docker, NodeJS, Deno, ReactJS. SolidJS & SolidStart to a high degree.

Portfolio: https://www.josecodea.com

Email: Refer to the bottom of my portfolio.

Proof of work with Elixir:

- My portfolio includes Open Source contributions.

Proof of work with Rust, NixOS and Docker:

- My portfolio includes two blog posts, each include a small Rust app that I made to turn on/off an EC2 server with a Discord bot.

SEEKING WORK | Remote | WORLDWIDE

Freelance Web Developer. Full-stack. With a decade of experience as SDE.

Location: Costa Rica (LATAM).

Remote: Yes, any timezone (I reside in CT/UTC-6, EST/CST timezones).

Languages: Spanish, English.

Programming: TypeScript, Rust, Elixir, Clojure, NixOS, AWS, Docker, NodeJS, Deno, ReactJS.

Portfolio: https://www.josecodea.com

Email: Refer to the bottom of my portfolio.

Proof of work with Elixir:

- My portfolio includes Open Source contributions.

Proof of work with Rust, NixOS and Docker:

- My portfolio includes two blog posts, each include a small Rust app that I made to turn on/off an EC2 server with a Discord bot.

SEEKING WORK | Remote | WORLDWIDE

Freelance Web Developer. Full-stack. With a decade of experience as SDE.

Location: Costa Rica (LATAM).

Remote: Yes, any timezone (I reside in CT/UTC-6, EST/CST timezones).

Languages: Spanish, English.

Programming: TypeScript, Rust, Elixir, Clojure, NixOS, AWS, Docker, NodeJS, Deno, ReactJS.

Portfolio: https://www.josecodea.com

Email: Refer to the bottom of my portfolio.

Proof of work with Elixir:

- My portfolio includes Open Source contributions.

Proof of work with Rust, NixOS and Docker:

- My portfolio includes two blog posts, each include a small Rust app that I made to turn on/off an EC2 server with a Discord bot.

I am sorry to hear that. It is high time that us engineers learn the lesson and refuse to work with any company that asks for unpaid work. There is no other way, but this only works if we are brave enough to act as activists, so that other engineers become aware of the abuse and circumvent it successfully.

The few that benefit from the abuse also benefit from keeping it hush hush. This is no different from obscuring the pay-bands for employees so that they can get away with underpaying the most vulnerable workers.

It seems like half of the commenters here believe they could implement a Golang TUI that sends and receives emails in less than 2 hours. Clearly they have never tried to build a TUI, let alone consider any kind of the issues that might occur between different terminal emulators (OS, Terminal emulator, Shell). The web is king for a reason.

The only explanation I can presume is that these people are mistaking TUI for a CLI app, which would be a fatal mistake.

> even fixed-width font and compact layout would likely be enough

Your assumption is that a better font-choice and some CSS would have made the difference for a back-end role.

Yes, no one took the time to talk with me on a call.

> lack of respect for the power dynamics is appalling.

Yes! That's exactly it.

It is mighty convenient for interviewers to feign ignorance of the power dynamics at play.

> If your app can’t be spun up and tested with a simple "docker compose up —build", then you are doing something wrong.

It can be spun with a simple "make live", I mention this in the first line of the README. ¯\_(ツ)_/¯

They asked for too much, and I am at fault for delivering? C'mon.

Postmark is a real SMTP provider, what are you saying?

I hadn't thought about this, but you are 100% correct.

To me, it is difficult to concoct a plausible explanation for the behavior from this recruiting manager. Assuming that the manager is not a technical professional and is therefore clueless about my emails is one of the few explanations that make sense. Thanks for bringing it up.

> suss out what a stakeholder actually wants, but isn't saying due to incomplete information and/or office politics

What you are saying sounds a lot like this:

"it is common for engineers to communicate properly, but people above them prefer to be vague, because plausible deniability is a political advantage to them at the detriment of the engineer"

This is very speculative so I left it out of the blog post. But... 'market research' is typical endeavour for companies breaking into an unknown space, the decent ones will carry out focus groups with experienced professionals and pay for people's time.

This kind of "do something for X but we won't tell you how!" looks a whole lot like market research disguised as an interview, that way they can do the research for free.

My brother on Earth, if I wanted to work on a new hobby... unpaid coding for a company wouldn't be on the list even if I had to think of a thousand hobbies.

You might not know this, but implementing Templ with PocketBase is non-trivial. It is actually impossible to do so unless you can read the source code for PocketBase yourself. Pocketbase is a golang framework that doubles as a library, PocketBase implements an entire backend, it is a very real project by an extremely adept author. You would be lucky to work on a Golang repo as featureful as PocketBase.

I built an email client, it sent emails, it also received emails, it had an intuitive and speedy user interface, and it touched on fundamental topics for a web-application with users, quintessential topics for a back-end engineering role.

Somehow the only criticism I got is that it was not simple enough.

Perhaps the moral of the story is that many managers have no idea what the word "simple" implies in terms of software.

This is a classic situation:

Engineer gets asked to implement the "do what I mean" button by some manager, this is a magic button that when pressed will do whatever the manager wants at that moment. The manager acts shocked when they are told that this is not a simple request to fulfill. The manager thinks: "I am being tricked! I merely asked for a single button!"

Imagine your Jira card at the job:

- Title: Make something fun for the customer.

Then your performance review:

- Manager: We cannot tell you why, but you failed at your job.

Exactly! You are actually considering all the possible ways in which your approach might be wrong and in which the time would be wasted. You are assessing risk before you take action. You are analyzing the subtleties in communication, you determined that the wording relied on a lot of subjective vocabulary and you know that this leads towards misunderstandings. This is, in my humble opinion, the professional way of making decisions as a software engineer.

From reading the other comments, it seems like there are a lot of mind-readers among us. ¯\_(ツ)_/¯

Reading your comment felt more tedious than writing my blog post.

> Anyway in 2 hours I’m pretty sure I can write some Go code that would get me an offer. This is not about the amount of features, it’s about giving them what they want.

Please do it, get the offer that I didn't, maybe you could even write a blog post about how easy it is and how wrong I am! ;)

> They didn't care as much about the details of the submittal as they did about seeing what the candidate would do without specific requirements.

This would be acceptable in a world where time is infinite. The reality is that they are going to churn through -who knows- how many candidates, as if it was worthless, as if it was a game.

If they really wanted people to spend little time on the solution, they could include that bit of info in their instructions. Clearly, they omit that bit on purpose. Obviously this is not their first rodeo, they must have done this for a long amount of time now.

> Sure, it would be possible

I have to be blunt, you have no idea what you are talking about. I am just going to say this: A terminal app is completely at odds with an online web client. If the interviewer is as clueless as you are, that explains two things:

- I was never going to pass the interview in the first place

- I was never going to get a reasonable conversation from this person, no amount of communication is going to solve incompetence from the interviewer's side

Corollary:

- Gross negligence from the company for assigning this interviewer

I deployed the app to my own domain and the functionality was without flaws. It took me forever. Included extra features typical of a backend role such as authentication and Infrastructure as Code. My efforts led to an empty rejection email.

And you are telling me that I should have spent extra time on my code comments?

I have to disagree with your point.

hi :)

> To him, submitting a long design doc where you go "I am going to use Galactor. I will make sure the project is florp-ready. I will fleem." is the exact opposite of cool.

Am I supposed to guess this much?

Do they expect me to creep on their social media to figure this out or something?

Finally, I made it abundantly clear that I am uncool, so giving me the "go ahead", simply to satisfy their curiosity... I hope they are treated the same as they treat other people.

No ill will against you, if anything you are giving me a plausible explanation where I have none. I just wish I had come across a post like mine earlier, and I hope that we, as a collective, start categorizing any job with a "take-home" as a job for the "cool kids". That way, all of us boring and experienced engineers may force companies to adapt if they actually want our labor. And those that do not adapt, we can infer the type of company that "offers" the role.

Should we feel bad about the hiring managers?

Hiring manager:

- Gets paid to perform the interviews

- Spends a 15 minutes answering emails and reviewing the solutions

Candidate(s):

- Does not get paid for their time

- Spends anywhere between 4 to 20 hours (or more) creating the solution

> As someone who works at a university this is very reminiscent of students who don't understand the assignment then complain when they get an unexpected mark.

This is such a lazy and convenient conclusion for someone that is giving out instructions.

Another valid reason that the students might misunderstand an assignment is because they cannot read minds and the instructions are poorly written.

Good teachers are the ones that make themselves understood by the largest amount of students. Bad teachers are the opposite.

With my best teachers, I never had to question their grading, because it was transparent from the start. So if you are getting a lot of confused students, you might be the common denominator.

Buddhist monks learn by solving riddles and guessing the messages of cryptic messages called Koans. Lets agree that students at a faculty, literally paying for tuition, should not be subject to the same practice.