Administrator

Cinco dicas para dominar uma entrevista tech

Muitos candidatos não têm a mínima ideia do que podem esperar numa primeira entrevista tech. Entre as várias questões que podem surgir, é comum perguntarem-se: “vai ser focada nos skills técnicos? Nas soft skills? Ambos?” Um desafio exigente tanto para o recrutador como para o/a candidato/a que normalmente numa primeira entrevista acabam por não conseguir tirar o máximo partido da mesma.

Tendo a noção desta realidade, decidi partilhar cinco dicas para dominar uma entrevista tech, trazendo umas luzes sobre o que nós Talent Recruiters mais valorizamos e o tipo de perguntas que podes esperar, tendo em conta a minha experiência na Xpand IT. O meu objetivo é simplificar e tornar mais transparente aquilo que pode ser um processo de recrutamento numa área profissional de TI e ajudar-te com alguns dos meus conselhos. Vamos a isto!

1 – Não fiques nervoso/a. Não mordemos!

Não é uma piada. É comum haver candidatos tímidos e, por isso, quando vamos ter contigo à porta já vamos determinados em pôr-te à vontade. Ao conhecer o/a  candidato/a, normalmente fazemos a mesma primeira questão: “Encontraste-nos (o office) facilmente?” – Porque perguntamos isto? Bem, em Lisboa temos três espaços de escritório (e só num existe uma recepção), num edifício que pode ser um verdadeiro labirinto. A resposta mais comum de quem não conhece o espaço é “o edifício sim, a porta nem por isso”. (riso embaraçado). Ao que esclarecemos (com um sorriso) que é habitual acontecer e que, no fundo, esse é primeiro grande desafio para os candidatos. (é uma piada). Quase sempre esta situação resulta em duas pessoas que já vão para a sala da entrevista com outro mood, o que torna tudo mais simples. Facto engraçado: por mais do que uma vez já tive de ir buscar o candidato lá fora. True story. Perceber onde é a nossa recepção não é tarefa fácil.

2 – Prepara-te para falares sobre ti e sobre as tuas experiências

É isso mesmo. Muitos candidatos não percebem esta parte da entrevista. Se não partilhares connosco detalhes sobre a tua experiência e aquilo que já fizeste, torna-se difícil fazer uma avaliação correta, concordas? Para facilitar, utilizamos uma abordagem que normalmente põe as pessoas mais à vontade e que consiste em perguntar-te sobre o projeto mais desafiante em que estiveste envolvido – a ideia é que o expliques com um whiteboard e uma caneta. Desta forma, podes mostrar-nos algo que verdadeiramente gostaste de fazer ao mesmo tempo que conseguimos avaliar inúmeras coisas:

  • Se estás efetivamente confortável com o projeto em questão e se te sentes à vontade para explicar o mesmo (o tipo de raciocínio e lógica que implementaste/utilizaste);
  • O teu grau de experiência com a tecnologia (Sim, é verdade – nós conseguimos compreender-te. Não acreditas? Desafia-nos);
  • As tuas skills de pensamento criativo e capacidade de resolver problemas (podemos perguntar-te, por exemplo, como terias feito o mesmo de diferentes maneiras;
  • Skills de comunicação;
  • A tua capacidade para trabalhar em equipa;
  • Metodologias de trabalho;
  • Capacidades de desenho(estou a brincar, não é assim tão importante, talvez só um bocadinho, quem sabe.)

Como vês, com um simples exercício podemos aprender muito sobre ti e perceber se podes fazer fit nas nossas equipas. Então, fala connosco, deixa-nos surpreender-te.

3 – Sê confiante sobre aquilo que queres, mas não em demasia

Confuso, certo? Concordo. Mas deixa-me explicar. Quando chegamos à primeira entrevista, 90% das vezes os candidatos candidataram-se ou mostraram interesse numa oportunidade específica. Logo, precisas de mostrar que é este o desafio que queres e que és a pessoa certa para o lugar. Utiliza todas as tuas armas!

Se te candidatares a uma oportunidade de Javascript Fullstack developer, prepara-te para explicar por que razão no teu projeto anterior utilizaste Vue em vez de Angular ou React, por exemplo. Se não conseguires explicar o porquê de teres utilizado determinada tecnologia ou até mesmo falar sobre o projeto em si, estarás assim tão “in love” com o que fizeste e com aquilo que será o teu desafio no futuro? Ao mesmo tempo, deves estar aberto ouvir falar sobre novas funções que possam de facto preencher-te e que no fundo respondam àquilo que te faz estar agora à procura de um novo desafio profissional. Nós fazemos de tudo aqui. Por isso, há à tua espera de certeza algo que podes ainda não ter considerado, mas que no momento atual em que te encontras faz muito mais sentido. Não deves ser intransigente. Escuta o que temos para te propor. Não seria a primeira vez que criávamos uma função específica para determinado perfil técnico.

4 – Partilha tudo aquilo que quiseres. Não vás embora com arrependimentos.

Esta é fácil. Vamos pedir-te para falares sobre o teu projeto mais desafiante. Mas de maneira nenhuma queremos impedir-te de falar sobre algo que seja relevante para ti ou sobre a tua experiência.

Se vires que não vamos fazer mais perguntas… chega-te à frente:

[Candidato/a]: Hey! [nome do recrutador] posso dizer uma coisa?

[Candidato/a]: Há um projeto/skill sobre o qual gostaria de falar.

[Recrutador]: Isso é interessante! Conta-me tudo!

Assim, podemos falar sobre o tema durante o tempo que for necessário, enquanto estiver tudo bem para ti. Comigo não há um limite de tempo para as entrevistas. Porque verdadeiramente queremos conhecer-te.

5 – Sê curioso/a. Queremos explicar-te tudo!

E, finalmente, claro, sente-te livre para perguntar tudo aquilo que quiseres. Se pesquisaste sobre nós para te preparares para a entrevista tech e tens algumas questões, dúvidas ou curiosidades, pergunta-nos. Teremos todo o gosto em esclarecer-te. E mesmo que não tenhas lido nada sobre nós, se tiveres ficado com alguma curiosidade durante a entrevista (ou sobre a entrevista em si), diz-nos. Não existem perguntas “más”. Desde o IRS aos projetos com clientes, passando pelas nossas metodologias e cultura, estamos habituados a todos os tipos de questões e damos as boas vindas a isso. Gostamos de uma boa conversa e de partilhar o que fazemos e quem somos.

Conclusões sobre como dominar uma entrevista tech

Apercebi-me agora de que escrevi muito, não foi? Fiquei entusiasmado! Vamos lá resumir o essencial sobre as cinco dicas para dominar uma entrevista tech:

  1. Relaxa, somos pessoas como todas as outras, mas ainda assim especiais. Sê tu próprio;
  2. Prepara-te para explicar o que fazes;
  3. Sê confiante e mantém a mente aberta;
  4. Sem arrependimentos. Conta-nos tudo;
  5. Sê curioso

Seja como for, termino este artigo dizendo que espero que estas cinco dicas para dominar uma entrevista tech sejam úteis na tua vida profissional futura e que na próxima vez que tenhas uma entrevista, te lembres delas. Espero que mais cedo ou mais tarde encontres o teu dream job. E, quem sabe, talvez nos possamos encontrar um dia?

AdministratorCinco dicas para dominar uma entrevista tech
read more

Middleware as code with Ballerina

Let’s assume that we need to facilitate the integration of several systems. What options do we have?

There are quite a few options for performing our integration, such as Enterprise Service Bus (ESB) or other frameworks like Spring and NodeJS.

Existing approaches

Enterprise Service Bus

Let’s start by looking at the ESB, one of the ways of integrating systems. ESB provides a range of services using a standard method of communication such as REST or SOAP.

It also helps monitor all the messages passing through it and ensures they are delivered to the right place by controlling the routing of each message.

You can use code to create the service logic, but service configuration (routing, users and passwords) doesn’t need to be hard coded, because the ESB provides ways to configure services outside the code. It also helps control deployments and versioning of services.

You need to take into account that this approach has a single point of failure and requires high configuration and maintenance.

Some approaches appear to have ESBs in containers, in order to be more ‘cloud-native’, but they still require a lot of configuration, not being very agile.

Spring and NodeJS frameworks

To achieve a more agile approach, we can use frameworks such as NodeJS or Spring to create our integration, however, to work with communication (endpoints, messages and payloads data) they require libraries and plugins and a lot of boilerplate code to deal with the payload type and make simple calls to services.

There is a new language dancing around to try to mitigate these problems between ESBs and frameworks like Spring and NodeJS. Let’s take a look at Ballerina.

Ballerina

Ballerina is a new language that is being created with the communication paradigm in mind. Ballerina allows concurrent work to be done and has transactional functions where the data is either all successfully altered or none of it is.

It has both a graphical syntax as well as a textual one. So, if you write the code with the textual syntax, you are helped by the graphical information generated afterwards. This graphical information can also be used as documentation, because it represents the flow of messages and intervenients in the service. You can check a comparison of the syntaxes in the following image (in the left the textual syntax and in the right the graphical syntax):

Since Ballerina is constructed with communication in mind, you can count on network data types to be fully supported. This way you don’t need to add libraries to manipulate json or xml.

Ballerina is built upon integration patterns, providing a QoS where the communication is resilient, transactional, secure and observable.

To get a better idea of how Ballerina works you can check the following page https://ballerina.io/philosophy/

Service and proxy example

If you want to try the following example in your machine, please follow the guide on how to install Ballerina on your computer under the next link: https://ballerina.io/learn/getting-started/#download-the-ballerina-distribution .

In this example we will check how to create two services. One will work as a resource provider, and the other as a proxy that will convert the resources from xml to json.

Let’s start with the first service and call it service1.

Service 1

To create the service, first we create a file named service1.bal and write the following code:

import ballerina/http;
import ballerina/log;
service service1 on new http:Listener(9090) {
    resource function getCars(http:Caller caller, http:Request req) {
        var page = xml `<response>
        <cars>
            <car>
                <model>Leaf</model>
                <plate-number>AB-12-CD</plate-number>
                <plate-date>2019-01-01</plate-date>
                <serial-number>AS6F4GR8154E5G841DF548R4G1WW</serial-number>
            </car>
            <car>
                <model>Yaris</model>
                <plate-number>AB-13-CD</plate-number>
                <plate-date>2019-04-03</plate-date>
                <serial-number>ESD5GFN2RG5H451SEWFDBGR3544D</serial-number>
            </car>
        </cars>
        </response>`;
        http:Response res = new;
        res.setPayload(page);
        var result = caller->respond(res);
        if (result is error) {
            log:printError("Error sending response", err = result);
        }
    }
}

In this service we have the function getCars with our logic: first we start to create the response as an xml and set it in the response payload. Evetually we respond to the caller, checking if there is an error responding.

To run the service we use the following command:

ballerina run service1.bal

 

This will create the service in port 9090 with the function getCars. We can check the response of the function in the address http://localhost:9090/service1/getCars in the browser or using curl.

Proxy

Now let’s create the proxy!

First we create another file with the name proxy.bal and then we write the following code:

import ballerina/http;
import ballerina/io;
import ballerina/log;
http:Client clientEndpoint = new("http://localhost:9090/service1");
service proxy on new http:Listener(9091) {
    resource function getCars(http:Caller caller, http:Request req) {
        //Get the xml response from getCars
        var responseGetCars = clientEndpoint->get("/getCars");
        
        if (responseGetCars is http:Response) {
            var msg = responseGetCars.getXmlPayload();
            if (msg is xml) {
                var responseJson = msg.toJSON({});
                //Create the response for this service
                http:Response res = new;
                res.setPayload(untaint responseJson);
                
                var result = caller->respond(res);
                if (result is error) {
                    log:printError("Error sending response", err = result);
                }
            else {
                io:println("Invalid payload received:" , msg.reason());
            }
        else {
            io:println("Error when calling the backend: ", responseGetCars.reason());
        }
    }
}

In the code you can see that we’ve created a service named proxy on port 9091 using a function called getCars. We have an endpoint for service1 (no plugins or libraries ), and in the function getCars, the first thing we do is call the function getCars from service1. Afterwards, we check whether the payload from the response of service1 is an xml; and if it is, we convert it to json using just one function! In the end we respond to the caller usng the json from the conversion.

To test the proxy we can use curl or to have a visual of the json, use your browser and the following address: http://localhost:9091/proxy/getCars

You can compare the output from service1 and the proxy and check that the information is the same in both.

Conclusion

In conclusion we can see that Ballerina is shaping quite well to be a promising language the integration of services, with an agile approach and less boilerplate code required for handling communication between services.

But do proceed with caution, because it hasn’t yet achieved a stable release, so syntax and semantics are still subject to change. The first stable release is expected at the end of this year.

AdministratorMiddleware as code with Ballerina
read more

Apache Spark: como criar um processamento distribuído eficiente?

No dia 30 de maio a XTech Community promoveu uma sessão hands-on para explicar à comunidade como criar um processamento distribuído eficiente com Spark, demonstrando as suas vantagens em relação a Hadoop MapReduce.

Mas antes de mais, o que é Spark? É uma framework de processamento paralelo e distribuído, que nos últimos anos tem sido um dos projetos mais ativos na área de Big Data, tanto na utilização como contribuição pela comunidade open source.

As Funcionalidades de Apache Spark

Como principais vantagens em relação ao Hadoop MapReduce foram apresentadas a facilidade da escrita de jobs compostos por múltiplos passos, através da API de Spark baseada em programação funcional bem como a capacidade de guardar os dados intermédios em memória.

Apache Spark

As funcionalidades oferecidas pelo Apache Spark foram introduzidas através das suas bibliotecas embutidas, implementadas por cima do Spark Core Engine, e pela possibilidade de usar bibliotecas externas disponíveis no repositório de Spark Packages.

Apache Spark

Conceitos de Spark Core

Após à introdução, o foco da apresentação passou para os conceitos importantes de Spark Core, tendo-se explicado:

  • em que consiste o programa Driver escrito pelos developers,
  • a abstração de RDD que permite paralelizar a execução de operações sobre datasets distribuídos
  • os tipos de operações aplicáveis sobre os RDDs: actions e

Através de um exemplo de word count em Spark, demonstrou-se a facilidade da escrita de um primeiro job e quais os componentes envolvidos.

Apache Spark

Foi também apresentado o resultado da execução do word count na Spark UI –  interface web disponibilizada para monitorizar a execução de aplicações Spark, que permitiu explicar o significado das unidades de execução física em quais uma aplicação de Spark se divide: Job, Stage e Task.

Apache Spark

Particionamento

O seguinte tópico abordado no meetup Spark Intro and Beyond foi o particionamento do Apache Spark. O número de partições de um RDD depende diretamente do particionamento dos dados na origem e de algumas possíveis parametrizações.

É importante perceber como funciona o particionamento uma vez que o número de partições de um RDD determina o paralelismo da execução das operações distribuídas e o seu controlo permite escrever aplicações mais eficientes, utilizando da melhor forma maneira os recursos do cluster.

Apache Spark

Abordámos quatro técnicas para aumentar o paralelismo da execução:

  • Através do 2º parâmetro da função sc.textFile(“hdfs://…”, 120)
  • Aumentando o número de partições do tópico de Kafka lido
  • Através do 2º parâmetro das wide transformations, e.g rdd.reduceByKey(_ + _, 100)
  • Através da função rdd.repartition(120)

Redução do Shuffle Data

Por fim, mostrámos 3 técnicas que minimizam a quantidade de dados que são enviados entre dois Stages de um Job, que se designa por shuffle data, e permite aumentar a desempenho da aplicação.

Shuffles em Spark são muito pesados porque os dados são enviados em rede entre os Executors de Spark que residem em diferentes nós do cluster, e escritos para e lidos de disco pelos Executors do mesmo nó.

As técnicas apresentadas para reduzir shuffle data foram:

  • Uso de operações com pré-agregação, e.g reduceByKey vs groupByKey
  • Aplicar operações sobre RDDs previamente particionados e cached
  • Broadcast Joins

Conclusões

No final, para além de serem esclarecidas algumas dúvidas sobre a apresentação, foram também discutidos vários pontos relevantes como:

  • Data locality e a integração do Spark em clusters Hadoop
  • Cenários nos quais faz sentido aplicar processamento em Spark
  • Possíveis razões de um Spark job ter um elevado tempo de execução e como diagnosticar através da Spark UI

Mais informações sobre o meetup Spark Intro and Beyond.

Andriy Zabolotnyy

Big Data expert, Xpand IT

AdministratorApache Spark: como criar um processamento distribuído eficiente?
read more

DevOps não é Dev & Ops – O que eu não sabia acerca de DevOps

Já há muito tempo que ouço falar de DevOps, mas estava profundamente convencida que era demasiado “techy” para mim. Eu pensava que DevOps era sobre Continuous Integration, Automação, e uns tipos fantásticos que se auto-intutulavam de DevOps e que sabiam quer de desenvolvimento de software quer de gestão de sistemas.

Agora, entendo que estava completamente enganada… DevOps não é igual a Dev & Ops a trabalharem juntas, mas antes a uma organização inteira a trabalhar em conjunto, a colaborar, mas colaborar à séria.

Claro que necessitamos de Automação, claro que necessitamos de soluções para Continous Integration, mas não só.

Numa cultura DevOps, devemos seguir estes princípios:

  • “Know the Flow” (Conheça o seu fluxo) = perceber como é que algo vai de “por fazer” a “feito”.
  • Trabalhar de forma aberta e visível = em vez de trabalhar em equipas isoladas, que apenas se preocupam com o SEU trabalho, toda organização trabalha em conjunto para atingir um propósito.
  • Aprender todos os dias & melhorar = Não perca tempo, se algo precisa de ser melhorado, melhore. Aprenda com as falhas e dissemine o conhecimento por toda a organização.

Mas como podemos transformar uma organização inteira? Em baixo, partilho alguns exemplos práticos:

  • Torne o seu trabalho visível para todos, não se preocupe sobre o que é que os outros vão pensar das suas falhas e sucessos.
  • Mude o “mindset”, deixe-me partilhar esta história que uma vez ouvi..

JFK, antigo presidente dos EUA, em visita à NASA, viu um empregado de limpeza e perguntou-lhe: “O que está a fazer?”. Ele esperava uma resposta, como: “Estou a limpar o chão”, mas antes, o empregado de limpeza respondeu: “ Estou a ajudar o homem a chegar à lua”.

  • Adicione o propósito às suas “user stories”, não desenvolva algo para fazer outra coisa, mas porque o que vai desenvolver vai gerar valor, como por exemplo, aumentar a satisfação do cliente em 80%.
  • Colabore, colabore e colabore um pouco mais… Nenhum homem é uma ilha, portanto não trabalhe como estando numa.

As ferramentas não são o mais importante, mas com certeza que ajudam. As sapatilhas de corrida, não fazem de si um corredor, mas vão de facto ajudar a correr melhor.

Se se encontra à procura de ferramentas que o possam ajudar a compreender o fluxo de trabalho, tornam o trabalho da sua organização visível e ajudam a colaborar melhor como equipa, espreite o Jira, que permite às equipas capturar e organizar o trabalho e o mais importante de tudo, colaborar.

Sofia Neto

Collaboration & Development Solutions Manager, Xpand IT

AdministratorDevOps não é Dev & Ops – O que eu não sabia acerca de DevOps
read more

As últimas novidades do Atlassian Summit

Mais de 3.500 participantes, 100 parceiros e um universo superior a 90.000 clientes ávidos por conhecer as últimas novidades do universo Atlassian. São estes os impressionantes números do Atlassian Summit, o principal evento mundial da empresa líder em Enterprise Agile Planning Tools no Gartner’s Magic Quadrant 2017, realizado no início de Setembro, em San José, Califórnia.

AdministratorAs últimas novidades do Atlassian Summit
read more