Portfolio

Jobsin.co - Projeto WordPress | WPPoland

Jobsin.co é uma plataforma de empregos moderna, focada em publicar ofertas de trabalho para especialistas qualificados nas áreas de construção, mecânica e en...

#Websites
Jobsin.co - Projeto WordPress | WPPoland

#Uma candidatura é um estado, não um formulário enviado

Na maioria dos sites, um formulário termina quando a mensagem é enviada, e esse é todo o seu ciclo de vida. Num portal de emprego, uma candidatura é um objeto que vive semanas e atravessa estados: submetida, analisada, convocada para entrevista, recusada, encerrada com a vaga. Tratá-la como um correio eletrónico parece uma simplificação e gera dois problemas ao mesmo tempo.

O primeiro é o silêncio do lado do candidato. Quem enviou dez candidaturas e não sabe o que aconteceu a nenhuma delas abandona o portal mais depressa do que quem recebe recusas. Uma vista de estado e uma notificação a cada alteração não custam quase nada e decidem se a pessoa volta. O segundo é o trabalho do próprio recrutador: sem estados não é possível dizer quantas candidaturas estão à espera, nem produzir qualquer mapa que não seja contar mensagens numa caixa de entrada.

Os estados importam ainda para a conservação de dados. Uma candidatura contém dados pessoais e tem de ser eliminada ou anonimizada findo o prazo consentido. Sem um estado explícito e uma data, isso não se automatiza, e feito à mão significa que ao fim de um ano já ninguém o faz.

É por aqui que começa este texto porque é a parte que costuma ficar de fora das descrições de portais de emprego, embora seja a que determina se a plataforma continua a ser usada depois do terceiro mês.

#O que é o Jobsin.co

O Jobsin.co é um portal de emprego para especialistas técnicos qualificados das áreas da construção, mecânica, engenharia e setores industriais afins, que liga profissionais a empregadores em vários mercados nacionais. O projeto chegou em 2019 e a implementação demorou cerca de seis semanas. A disposição e a colocação dos elementos vieram do cliente, pelo que o tempo que noutros projetos se gasta em iterações de desenho foi aqui para as duas peças que decidem se um portal de emprego aguenta: a taxonomia de competências e o fluxo que move uma candidatura entre estados.

Os setores técnicos distinguem-se do resto do mercado de trabalho de formas que chegam até à arquitetura. Faltam especialistas à escala global, por isso é o candidato quem tem a posição forte e não preenche um formulário de vinte campos. Uma parte considerável das vagas pressupõe mudança para outro país, o que traz para o âmbito vistos, reconhecimento de qualificações e diferenças de direito laboral. Os requisitos são estreitos e uma proporção elevada do trabalho é por contrato e temporária, o que altera toda a lógica dos avisos: uma vaga aberta três semanas tem de chegar à pessoa certa nos primeiros dias.

#A taxonomia é o produto

Num portal generalista, a pesquisa por palavras-chave chega, porque candidato e empregador usam as mesmas palavras. No recrutamento técnico esse mecanismo falha de imediato, porque a mesma competência tem uma dúzia de nomes: uns são a designação comercial de um fabricante, outros uma abreviatura do setor, e outros dependem do país e de quem escreveu o anúncio.

Um soldador com certificação para um processo específico, um operador de uma máquina de determinado fabricante e um engenheiro que trabalha segundo uma norma em vigor apenas num país são três casos em que a pesquisa por texto devolve zero resultados ou várias centenas sem relação. A base desta plataforma não é, portanto, um motor de pesquisa, mas um vocabulário ordenado de competências: uma hierarquia em que cada competência tem categoria superior, ligações a competências afins, indicação de pré-requisitos e um nível que vai de básico a especialista.

Construir esse vocabulário é trabalho de domínio e não de programação, e é a parte mais consistentemente subestimada em projetos desta categoria. Código de correspondência escrito sobre um vocabulário ainda em movimento tem de ser reescrito sempre que uma categoria muda de nome. A ordem de trabalhos foi por isso a inversa da habitual: primeiro o vocabulário, depois a pesquisa e os avisos assentes nele. Na prática, acrescentar um setor depois do arranque é trabalho de dados e não de código.

#Um anúncio caduca numa data

Quase todo o conteúdo de um site envelhece devagar. Um anúncio de emprego não. Caduca num dia marcado e, a partir daí, faz mal: quem se candidata a uma vaga que já não existe perde o seu tempo, e o site perde credibilidade mais depressa do que perderia com qualquer falha técnica.

Daí saem três decisões. O estado do anúncio é um campo com valores fechados e tem ciclo de vida próprio, independente do texto. A caducidade não apaga o registo, altera-lhe o estado, porque o histórico de candidaturas tem de sobreviver ao anúncio a que diz respeito. E um anúncio caducado tem de deixar de estar visível para os motores de pesquisa, o que é trabalho autónomo e não um efeito secundário: uma página já indexada continua viva nos resultados durante semanas e continua a mandar visitas para uma vaga que não existe.

Os dados estruturados para anúncios de emprego não são aqui um enfeite, mas o principal canal de distribuição, porque os motores de pesquisa mostram vagas num módulo próprio. A marcação tem por isso de coincidir com o estado do registo ao dia, e essa é a única razão pela qual a data de validade vive nos dados e não num parágrafo escrito por um recrutador.

#Pesquisa, correspondência e o que a correspondência não promete

A pesquisa assenta nesse vocabulário e em atributos fechados: localização dividida em país, região e cidade, setor, nível de experiência, tipo de contrato, intervalo salarial e moeda, e regime remoto. A correspondência pondera a sobreposição de competências, o peso da preferência de localização, o nível de experiência e a expectativa salarial.

Vale a pena dizer com clareza o que este mecanismo não faz. Não avalia o candidato nem prevê se ele se sairá bem na função. Ordena uma lista pela coincidência entre aquilo que ambas as partes escreveram sobre si próprias, e nada mais. As plataformas desta classe são frequentemente descritas com uma linguagem que sugere mais, e a diferença conta, porque decide se o recrutador trata o resultado como sugestão ou como veredito. A percentagem ao lado de uma vaga é legível para o candidato e é ao mesmo tempo o elemento mais arriscado da interface, porque um número parece uma medição e é uma soma de pesos definidos à mão.

Do lado técnico, a pesquisa corre em Elasticsearch e não em consultas ao MySQL. A razão é prosaica: filtrar por uma dúzia de atributos ao mesmo tempo sobre dezenas de milhares de registos é, numa base relacional, uma consulta com muitas junções que responde de imediato numa instalação vazia e demora segundos contra um arquivo completo. O MySQL continua a ser a fonte de verdade, porque o índice de pesquisa é uma estrutura derivada e tem de poder ser reconstruído do zero.

#Avisos, ou o tráfego que se gera contra si próprio

Os avisos de novas vagas são o mecanismo de regresso de um portal de emprego e, ao mesmo tempo, a forma mais fácil de destruir a própria reputação como remetente. Um site que envia correio a todos os candidatos compatíveis sempre que publica um anúncio cai na pasta de lixo eletrónico ao fim de um mês e deixa de chegar mesmo a quem pediu os avisos.

A resposta tem três camadas. O envio passa por uma fila, pelo que publicar um anúncio cria tarefas processadas ao ritmo aceite pelo fornecedor de correio e não centenas de mensagens num instante. O candidato escolhe a frequência, imediata, diária ou semanal, ficando o resumo diário como valor por omissão, porque no recrutamento técnico uma vaga raramente exige reação dentro de uma hora. O agrupamento faz-se por relevância e não por data, para que uma mensagem traga algumas vagas que valha a pena abrir em vez de vinte arbitrárias.

A fila cumpre ainda uma função pouco mencionada: separa as operações pesadas do pedido do utilizador. Publicar um anúncio, recalcular o índice de pesquisa e enviar avisos são três tarefas distintas, e só a primeira tem de terminar antes de o recrutador ver uma confirmação.

#Os dados do candidato e a definição que decide tudo

Um perfil de candidato no recrutamento técnico é extenso: competências do vocabulário, certificados e licenças com datas de validade, historial profissional com descrição de projetos, línguas, preferências de localização incluindo disponibilidade para mudança, e expectativa salarial na moeda escolhida. A partir daí gera-se um documento de candidatura, podem guardar-se várias versões e candidatar-se a partir de um perfil pronto é uma única ação.

O mais importante nesta parte não é, porém, uma funcionalidade, mas um valor por omissão. Um profissional empregado que anda a ver o mercado não quer que a entidade patronal atual veja o seu perfil. A visibilidade do perfil, a candidatura anónima e a definição exata do que uma empresa vê antes do contacto estão por isso sob controlo do utilizador, e os valores iniciais são contidos. Um site que por omissão mostra tudo a todos reúne mais perfis no arranque e perde exatamente os profissionais mais procurados, porque são eles que têm mais a perder.

A proteção de dados deixa assim de ser um anexo legal e passa a ser produto: gestão de consentimentos, portabilidade, direito ao apagamento e armazenamento na União Europeia são os requisitos que decidem se um candidato chega sequer a criar conta.

#O lado do empregador e a honestidade dos anúncios

O recrutador dispõe de um editor de anúncios com lista estruturada de requisitos, várias localizações, intervalos salariais, prazos e uma biblioteca de modelos, e do lado dos candidatos um acompanhamento das candidaturas, comparação de perfis, marcação de entrevistas e modelos de comunicação. O acesso em equipa significa que várias pessoas trabalham sobre a mesma vaga, pelo que uma mudança de estado tem de ficar atribuída a uma pessoa e não à conta da empresa.

A confiança é um tema à parte. Em mercados internacionais, um anúncio falso é um perigo real para o candidato, porque envolve trabalho no estrangeiro, custos de mudança e por vezes pagamentos exigidos à cabeça. A verificação do empregador é por isso feita em várias etapas, os anúncios passam por moderação e as denúncias dos utilizadores vão para revisão manual. A deteção automática de padrões típicos de fraude é uma ajuda e não uma decisão: o último passo cabe a uma pessoa, porque o custo de um erro recai num sentido sobre o candidato e no outro sobre um empregador honesto cujo anúncio ficou retido.

#Conformidade sem a ficção de um regulamento único

Uma plataforma que opera em vários países encontra direito laboral distinto, exigências de dados distintas e regras distintas quanto à publicação de intervalos salariais. A pior resposta possível é um regulamento único escrito para a jurisdição mais permissiva, porque parece ordem e transfere na prática o risco para o utilizador.

Em vez disso, a camada de conformidade é modular: condições e cláusulas estão ligadas a um país, os dados são encaminhados para o local correto e as diferenças estão descritas como configuração e não como código. Acrescentar outro mercado passa então a ser completar um conjunto de regras e obter uma revisão jurídica para essa jurisdição, em vez de rever a aplicação inteira.

#Desempenho e tecnologia

A plataforma assenta em WordPress com tema próprio de portal de emprego, um motor de anúncios fortemente adaptado, um conjunto de extensões próprias e Advanced Custom Fields Pro. A camada de dados é MySQL com replicação, Redis para cache de sessão e de objetos, Elasticsearch para a pesquisa e um armazenamento separado para analítica. À volta ficam as integrações de distribuição e de dados estruturados, as plataformas de pagamento e os fornecedores de correio, sobre alojamento na nuvem com CDN, balanceamento, processos de fila e monitorização.

O trabalho de desempenho concentra-se nas listagens, porque são elas que suportam a maior parte do tráfego e são as mais caras de calcular. A cache guarda resultados para as combinações de filtros mais frequentes, os ficheiros estáticos saem da rede de distribuição e as consultas à base de dados foram revistas à procura das que crescem linearmente com o número de anúncios.

#Decurso da implementação

A implementação demorou cerca de seis semanas, do levantamento do âmbito ao arranque. A ordem dos trabalhos está descrita acima e decorreu de uma observação: os dois erros caros desta categoria, um vocabulário por fechar e um envio de avisos sem fila, só se manifestam com volume, pelo que têm de ser resolvidos antes do arranque e não depois do primeiro mês.

Os testes de carga correm contra uma cópia dos dados reais e não contra uma instalação vazia, porque uma consulta instantânea sobre um conjunto de demonstração comporta-se de outro modo sobre um arquivo de anúncios com anos de candidaturas associadas. Depois do arranque, o projeto passou a manutenção: cópias de segurança, atualizações de segurança, revisão periódica do desempenho e testes de carga antes dos períodos em que o volume de contratação sobe. A manutenção inclui ainda o controlo de qualidade dos anúncios e a moderação, que num portal de emprego não é trabalho editorial mas defesa direta da credibilidade do site.

#Conclusão

O Jobsin.co mostra que um portal de emprego no recrutamento técnico não é uma lista de vagas com uma caixa de pesquisa. É um vocabulário de competências, um mecanismo de avisos, uma camada de conformidade para vários mercados e um processo de verificação de empregadores, sendo a interface a última camada sobre tudo isto. Todas as decisões técnicas acima decorrem dessa ordem: o vocabulário antes da correspondência, o índice de pesquisa separado da fonte de verdade, a fila à frente do envio, valores de privacidade contidos por omissão e uma pessoa no último passo da moderação.

O que transita para a implementação seguinte é o método de trabalho. O vocabulário e as integrações não transitam, porque foram construídos para um mercado e para os dados de um cliente. O projeto seguinte começa por uma análise de âmbito, e o orçamento vem depois dela.

FAQ do artigo

Perguntas frequentes

Respostas práticas para aplicar o tema na execução real.

SEO-readyGEO-readyAEO-ready4 Q&A
Que âmbito teve o projeto Jobsin.co?#
Jobsin.co é um projeto da categoria Websites, entregue em 2025. Por detrás estão WordPress, Redis, MySQL e Elasticsearch.
Como correu a entrega de Jobsin.co?#
A construção durou cerca de seis semanas e entrou em produção em 2025. Assenta em WordPress, Redis, MySQL e Elasticsearch. O layout veio do cliente. Sobre ele construí os templates e o modelo de conteúdos, e testei os caminhos que carregam tráfego numa cópia de produção, não numa instalação vazia.
O que foi mais difícil tecnicamente em Jobsin.co?#
Manter WordPress, Redis, MySQL e Elasticsearch a trabalhar em conjunto foi o que exigiu mais cuidado. Conteúdo, configuração e código ficam em camadas separadas, por isso uma reversão após o lançamento mexe numa delas e não nas três. Os casos-limite aparecem numa cópia de produção, e é aí que correm os testes.
Que parte de Jobsin.co pode ser reaproveitada noutro projeto?#
A camada técnica transita: WordPress, Redis, MySQL e Elasticsearch. No projeto seguinte tem um aspeto parecido. O que não transita é o modelo de conteúdos e as integrações, escritos para os dados de um cliente e um briefing da categoria Websites. Um segundo projeto começa por uma análise de âmbito, e a proposta vem a seguir.

Precisa de FAQ adaptado ao setor e mercado? Criamos uma versão alinhada com os seus objetivos de negócio.

Fale connosco