En este vídeo vamos a ver un simulacro de prueba técnica para conseguir trabajo en remoto en Estados Unidos
utilizando la plataforma de ARK.def.
La entrevista es completamente en inglés, así que si no entiendes inglés,
te recomiendo que actives al menos los subtítulos automáticos.
La entrevista dura más o menos una hora y empezamos con un live coding con código en vivo
y luego continuamos con algunas preguntas técnicas.
La prueba, como verás, no fue preparada y por eso me puedes ver un poco nerviosillo,
pero creo que aún así es muy útil, te puede ayudar un montón en tus próximos procesos
y espero que lo disfrutes.
Si te gusta, ya sabes, machaca el like para que me anime a hacer este tipo de contenido.
¡A disfrutarlo!
Ok, espero que sea, espero que sea.
Creo que será divertido.
No sé, ¿quieres empezar o quieres compartir alguna información?
Sí, no sé cuánto información has compartido antes de entrar.
Sé que yo entré y escuché a ti un poco sobre eso, pero para aquellos de ustedes que no se conocen,
quizás yo solo rehaciendo cosas a este punto.
Ah, ok, ARK website.
¡Gracias!
Sí, sí, somos una plataforma para que te ayuden a encontrar un rol, últimamente.
Hay muchas diferentes programas, per se, que tenemos para que te ayuden a encontrar.
Hay formas para las empresas aplicar a ti, hay formas para ti aplicar a las empresas muy tradicionales.
No quiero entrar demasiado en el nít y grít y para esos detalles.
Por supuesto, puedes ir a ARK.deb y aprender todo sobre eso.
Pero realmente, estamos aquí para ayudarte a encontrar un rol.
Estamos internacionales, tenemos gente que estábamos en todo el mundo y estos roles son remotos.
Y sí, no quiero hablar demasiado sobre esto, porque sé que la gente está aquí para mirar a Miguel a un poco.
Y, para ser claro, la entrevista de tech que vamos a hacer hoy es como esta, para obtener un rol en las empresas y lanzar un trabajo remoto en 14 días.
Sí, sí, parto de la appeal de ARK es que todos los que vienen aquí como un developer, queremos asegurarse que siguen a través de este proceso que tenemos.
Así que, nosotros aseguramos que los clientes que vienen a ser confortable y confidentes que los developers que se encuentran en ARK son los de alta calidad, ¿verdad?
Y alta calidad es un termo muy genérico, pero, finalmente, tenemos dos cosas aquí en ARK.
Tienes que ser un buen comunicador y tener un buen comunicador y tener un gran talento de expertise, ¿verdad?
Y no es como que tienes que ser 100% muy fuerte en comunicación, 100% strong con los tecnologías de suerte.
Parto de la vetación es que, uno, queremos asegurarse que tú eres una persona que se convirtió a trabajar con clientes, ¿verdad?
Eso es la primera pieza.
Y la segunda pieza es que, mientras que estamos hablando con vosotros, por lo que estamos hablando con vosotros,
no estoy aquí no voy a decir, ¿qué, Miguel dice lo malo?
Oh, es un fail, ¿verdad?
No estoy tratando de actuar con personas.
Estoy tratando de entender lo que sus strengths son, así que también podemos entender que Miguel, el developer,
es muy fuerte con estas tecnologías, tiene acceso a estas cosas,
así que si hay un cliente que necesitas strengths en la ladder, tal vez que no es el mejor fito,
pero también es muy bueno a explicar las cosas en este detalle.
Así que si necesitas una persona que es más senior, trabajando con otros individuos,
tal vez que es un buen fito para eso, ¿verdad?
Así que esto no es una dirección, no estoy aquí tratando de tomar información de ti y bailar a ti.
Estoy tratando de hacer esto bidireccional, donde yo intento entender a ti y al mismo tiempo,
y espero que también aprenda un poco sobre el proceso de ARC a través de la manera.
Ok, gracias por la introducción, porque creo que eso cerraba eso.
Entonces, vamos a empezar, Justin, con vosotros.
Ok, cool, así que lo que esto va a funcionar es que vamos a empezar con el ejercicio de la codicia.
Ok.
Y vamos a pasar un poco de 30 minutos en esto.
Es ok si terminamos tarde, eso es todo bien.
Si terminamos 30 minutos, voy a cerrar con un poco de tiempo para otras preguntas.
Después de eso, vamos a ir a ver algunas preguntas de Q&A que no involucra ningún tipo de programación,
solo para ver dónde sus strengths están.
Y estos son muy open-endidos, no hay respuesta correcta.
Ok, perfecto.
Cool, si no te preocupes de empezar a compartir una pantalla con tu espacio de desarrollo de tu escenario,
y puedes usar cualquier lenguaje que quieras usar, y mientras que estoy haciendo eso,
voy a enviar un poco de data que te enviaré un poco de datos.
Ok, ¿es este el escenario que te va a usar?
Sí, esto es algo que se llama RANDS, es como un juego de Playground con Davascript,
y puedes poner a la izquierda un poco de datos y tienes el resultado en la izquierda.
Cool, alright, so private chat es ok, right?
Like, sending a message through that, truncated it.
Ok, perfect.
Ok, so this looks kind of daunting.
Let me just give you a quick overview, right?
Ok, so this is a bunch of data.
The top one is a directory of people, right?
We have people's names, their ages.
You can think of this as a phone book or your contacts list on your phone.
The second piece, the second array is a bunch of registrations.
So you can imagine maybe you are hosting an event and some people came in
and they put their names down on here.
Ok, so what we want to do today is we want to write a function
that will perform a join, inner join.
So just a quick check.
Are you familiar with what inner joins are with MySQL and so forth?
Yeah.
Ok, great.
So we want to perform a join and ultimately have this return an output
that has the join parameters that we want.
So let's say I take these.
For this function, we want to pass in three parameters.
We want to pass in one list of objects, which would be the directory.
We want to pass in a second list of objects, which would be the registrations.
And we want to pass in some kind of key.
So this would be a string.
And that key would be correlated to the field name that we want to perform the join on.
And for simplicity's sake, we can just assume that whatever we're returning in this join
is going to pretty much look exactly what we have here.
I know that the bottom registrations has a conditional field,
but you can just assume it's a flat object with just key value pairs.
There's not going to be anything nested, nothing complicated there.
Okay.
Cool.
All right.
So I'll just give you a key.
Okay, so that's the prompt.
But before we dive in, I'm just going to give you a few prefaces.
Okay, so performance is nice, but it's not important.
We don't have to worry about that right now.
We can talk about that later, right?
So just whatever approach makes the most sense to you, we can just go with that approach, right?
And we can make this as collaborative as we need it to be.
So if you're the type of person who performs to code like heads down, that's fine.
I'm not going to talk to you and interrupt your train of thought.
But if you have questions, feel free to ask.
And if you need to look up syntax or anything, that's totally fine.
My ask is just don't go on Google and type, oh, how do I perform in a joint with JavaScript?
Something like that, right?
Can I use GeekHackerPilot?
I'm joking.
I'm joking.
I was like, I don't want to say no.
Yeah, right.
Okay.
Okay.
Okay.
Anything else about something that I should keep it in mind?
No, I think it's, this is very open-ended, like feel free to do whatever it is that makes
you most comfortable, right?
Like if you're the type of person that writes tests, if you're the person that likes to like
run through debuggers, we want to make this as close to a environment where you would
be realistically working in as much as possible.
So just I'll have you take it away and I'm right here.
Questions, anything like that.
Like I want to be able to like help you as well.
Right?
Okay.
Well, okay.
Perfect.
So inner join with JavaScript.
Let's think about it.
Could I write like a simpler example of it in order to try it with?
Absolutely.
Okay.
So maybe it take a while, but I think maybe it's worth it.
Like having it be, I think it's simpler.
And what I'm going to do is having like a simpler one in order to be sure that this is working
as expected.
So we have like, if I remember correctly, the inner join should not like, if in this example,
I don't know if it's this correct.
I don't remember quite, but I think that if this ID is not here, it shouldn't be in the
result.
Is that right?
Yeah.
So this one might be a little funky just because we have different notions of ID here.
For simplicity's sake, if we're going to condense this, maybe we can instead of calling an ID
in the second list, we can call it something else.
Unless you're performing, oh, you're performing the join on there.
Sorry.
Yeah.
So I think that the expected output would be something like, sorry, like this with the correct
name here.
Because we don't have this in the B and we don't have this in the A. So the expected
output should be something like this.
So let's make that for, sorry, I'm pointing here.
For the second list, let's make that ID for Miguel's email as zero.
And then the ID for the response as zero.
Because ID will be our join column here.
Yeah.
Sorry.
So if you say, okay, perform a join on parameters A, parameter B and string with ID, this will
be the exact response that we want.
Okay.
Perfect.
Perfect.
Perfect.
Okay.
So let's create the function and we have the left array.
Sorry.
Sorry.
I'm going to go to the discord because it's giving me some notification.
Yeah.
We have this.
I'm going to import assert strict and the idea would be that we have the left array B and
the key would be ID and insert inner join this function should be expected.
Okay.
So we have the error here.
Check that this is working as expected.
It's not working as expected.
I'm sorry.
Okay.
Perfect.
Let's begin.
Nice.
Nice.
So, um, the first thing, uh, in order to, to be, because the first thing that I'm thinking
about is about the, the most usual one about, uh, an estate loop, you know, a loop and inside
another loop that would be like the, maybe the easier one, but something that I think that
could be interesting here.
Yeah.
I'm sorry.
But if we, if we have here that, like this email here, it should be like with the ID2 for
the expected output.
Okay.
Okay.
Uh, but I think that maybe, uh, one idea could be to have some kind of map, um, for the first
one.
And we could, uh, the left array iterated over with a for each, and for each item, I would
create like, um, a new, uh, item in the map with this ID, the ID that we have here.
Not the ID, but the key that we want to use from the parameter that will be the ID.
And I'm going to save the item and I'm doing this in order to avoid, like having, having
nested loops in order to be more clear how to get this item from the, from this array in
order to find and find, I'm going to just, uh, simplify, like having a map in order to check.
Yeah.
Makes sense.
Okay.
And then maybe we could improve the code, but for now I'm going to just create, uh, the join
and empty empty array and know that maybe the most, uh, I dunno, the senior way would be
to use reduce, I'm not a big fan of reduce because sometimes it's a bit complicated.
The reliability of it, uh, maybe it's like, I dunno, uh, I have like 15 years of experience
and I have to, uh, read twice the reduce.
It's not as maintainable sometimes it's hard to read makes perfect sense.
Right?
So I'm going to use another for each, uh, I could use another thing, but for now in
order to be clear and try to, to get it working, I have here the right item.
So the idea now would be to, from the right item to get the data from the left, from this
map.
So let's try to get from right item key.
That should be the same ID.
Yeah, that would be, I'm trying to grab the information of, uh,
of this ID from the left.
Um, what I'm going to do is if the left left item is undefined, I'm going to just return.
I'm not going to do anything else because, because I don't want to, to put it.
I'm not going to put the, this information, for example, we have this one, the two is going
to be, I'm going to try to get the info from the, this two, I'm not going to retrieve
it because it's not here.
Uh, so I'm going to return it.
Um, and now what I have to do is push, I'm going to push the left item that I suppose
I have and the rest of the right item.
Okay.
Okay.
Okay.
And I have to return this because if not, it's not going to work.
Okay.
This seems to work for now, at least for this example.
Nice.
Okay.
The inner joint, left array, I think this is correct.
For example, if I put here an A, okay, this is not working as I expect.
Okay.
And if I change this, okay, this is not working.
Perfect.
Uh, at least it's working.
I think it's working.
I'm going to try to use this one, this example that seems to be a bit more complicated.
Do you mind just like console outing the output from the example we have right now?
I just, I just like to see it.
Yeah.
Yeah.
It's me, uh, like, uh, confident about the deep streak equal, but.
Yeah.
Oh, that's beautiful.
Okay.
Yeah.
So this is the, the, the output.
Yeah.
The, the good thing about the run JS playground is that, like, you see here the line number
of the console log and then you have exactly the line number.
Oh, that's very useful.
Yeah.
Super useful.
It's very nice.
You have that blank space because they want to just put in, in the right spot.
Right.
That's very interesting.
Okay.
Okay.
So let's try with the directory.
Yeah.
So for that one, um, I'll let you get that set up, but I think we can do a join on the name.
Um, the idea might be a little funky.
I think the name will, will be a good join parameter.
I intentionally use like the same like names consistently.
Perfect.
Hmm.
Okay.
Name for Maggie.
Okay.
Because I see that there is some, uh, uh, duplicated properties.
Yeah.
But I don't think we can look at the phone and the confirmed fields as the ones that would
be joined across the two.
Hmm.
Yeah.
I see that now the problem is that, yeah, the ID is not the same.
Yeah.
Yeah.
For example, our own, we have like an ID with seven and here we have the ID with three.
Uh, I don't know.
Glad you noticed that.
Um, that's why I recommended joining on a name because this table here, it's kind of,
um, the ID would be for the, if we imagine these as like database tables, right?
The ID would be for the actual table itself, not for the person necessarily.
So in our case here, let's not worry about that.
We'll just take whatever ID is being put in.
We don't have to do a, uh, merge or reconciliation for that.
Cause in a normal case we'd want to rename them.
So it's like registration ID, but for our purposes right now, it's not necessary.
Yeah.
Yeah.
We could, uh, like, like one, we could use object keys in order to check all the keys in
order to avoid like the collision and rename with the, well, the tricky part would be the
renaming because we don't have, we could like left ID, right ID.
Right.
Uh, that would some, something that we could do.
Um, but for the rest, I would say that is what we expect.
Yeah.
Yeah.
I think this looks great.
Okay.
So normally I would have asked you about how you would handle this ID, but you started
talking about it yourself.
So I think, I think that's great.
Right.
Um, we, I don't want us to write any code for it.
It's a little bit, it's, it's not as simple as this.
Cause you have to like start jumbling around with your code, but, um, it's just something
I like to talk about.
Right.
So I think this looks really good.
I really like it.
Um, let's take this and let's talk about it.
Right.
We don't have to write any code, but let's imagine we take this function and maybe it becomes
part of a rest API.
So possibly we, we stick this behind node express.
Now that there's this, there's this API end point.
You can pass in these, this JSON object where you can specify left array, you can specify
right array, you can specify the key.
So as a property of being a restful API endpoint, we could have a lot of concurrent requests,
right?
So you can imagine a lot of people are calling this and doing joins on their data sets.
So because of that, you can imagine we can have like 300, 400 requests per second and
so forth.
So if that is the context that we have to solve for, what are your thoughts about how you would
make this function be able to handle that, right?
Either what you would do in the code or how you would deploy the code in order to handle
that type of load that's coming in.
Okay.
Wow.
That's a great question.
Just so you know, there's no wrong answer.
They're very open-ended.
So yeah, with a lot of layers, uh, first of all, something that I would consider is,
uh, is trying to avoid to, uh, to, I, I don't know how to say in English, but, uh,
you know, to mess with the event loop, because, uh, if we mess with the event loop and we have
loops, like with the for each, if we do something inside the loops that is blocking the event loop,
that is something that is going to cost a lot of performance and problems for sure.
Because we, if we have some, a lot of concurrency, we are going to suffer, uh, even timeouts at the end.
So something that I would have, uh, very care would be trying to avoid blocking the event loop.
And for that, I would check, obviously this example is not going to block the event loop.
It's going to block something, but not something to, to consider.
But maybe if we evolve this method to do some kind of operations inside, I would be careful with that.
After that, uh, thinking about having a rest API for it.
I think, I think that's something that would be great in order to scale, not in terms of code,
but in terms of infrastructure would be to use like edge functions, something like cloud for workers.
Uh, first, because you have the possibility of deploy the edge function very near the user.
And then you are not gonna to, the user is not gonna pay the, the latency when using this, this function.
And something that would be great is that edge functions from, for example, cloud for workers, you have some kind of redis.
And maybe we could consider in to cache some kind of operations, not in this method, because we're not querying the database,
but I'm guessing that you are asking more about the concurrency of database.
And maybe we could try to like move some kind of, uh, work in order to be cached from the two redis.
Or the key value database from cloud for workers or something similar to try to avoid that.
And the good thing with the edge functions would be that they scale like very easy, very cheap and indefinitely.
So that would be the, be a problem anymore.
Besides that, for sure, we should be careful about the join because join is a very expensive operation.
And in terms of database, we should consider which database we are going to use.
If we are going to use joins, um, maybe we should consider using a no SQL because, um,
if we are doing a lot of operations, uh, the problem with SQL is that they don't scale that very, very, very good.
You know, they scale like vertically, you have to improve your machine or you have to do sharding or something like that.
And it's not, uh, something good, you know, in terms of performance.
So yeah, that's yeah.
I don't know.
It's fine.
It's like, I can say something from the code in the note, uh, something from the infrastructure of deploying the code for the rest API.
And in terms of database, but while it's very soon to, to know about the database.
Yeah.
Yeah, absolutely.
So, um, let's talk about the caching piece, right?
So you talked about possibly caching.
Um, if we're looking at the example that we have here, so we can ignore using like a database internally for the, for just like feature wise, right?
Maybe we want a database for caching, but if this is what we have and this is what we're supporting, um, what are some caveats with caching, right?
Because caching is very useful, but there are some trade-offs and there's something like gotchas that come into play.
So I'm looking at this.
I see possibly some things that could go wrong, but also things that could work really well.
So what are your thoughts about like the trade-offs there?
Yeah, that's great because you know that they say that there are two things very difficult.
The most difficult things in programming is, uh, caching and naming variables.
And that's true.
And the problems, obviously if we only have this set of data, I, I, it's, it doesn't matter to, to cache.
I mean, it's not worth it, but, uh, the problem with caching is to, to have in sync with the database.
So we have to be careful because obviously if you cache some data, how do you handle the, um,
variation, no, the, when you want to, to refresh the cache, you have to be careful with every time that the, I don't know, Maggi is updating the phone on the database.
Then you have to like have some kind of process in order to be sure that the cache is not with stale data.
And if we have a lot of operations, like a lot of operations of updating and writing.
This is going, uh, this is going to be a problem.
Um, even not with the ideas for sure, but for example, we have here the registrations.
Imagine that we are catching the registrations and we have a cache with of one hour.
The problem with that is that maybe Elizabeth is confirming after five minutes and we are not going to see this result.
So we have to be careful with that, with the, um, I don't know the, the name.
I have the name in the, in the tongue, but I don't know.
Uh, when you want to refresh, there's a verb for that.
And I, and I don't remember now.
Oh, like, uh, well, man, now I'm forgetting it too.
Yeah.
Like invalidate the cache?
Invalidate the cache.
Yeah.
Thank you.
It's an easy one.
I forget about it.
Update.
Yeah.
The, the chat is telling me some secret.
Right.
Yeah.
Okay.
Invalidate is the.
You've got a team behind you.
Invalidating is the most challenge with the cache.
Right.
And we have to be careful with that.
I mean, the idea of the cache would be, for example, in this kind of data set,
maybe it's not worth it, but I don't know.
Maybe if we have some data that is huge, uh, from the directory, maybe we have like the,
the, the, the address of the user, not only the phone and the phone, the address, maybe
that's not data that is going to change that much.
And maybe we could have, uh, like a cache of 30 minutes, one hour, and maybe it's not
that critical.
So I would say like, we have to be careful, like with this flag of the confirm, but it
seems to be very important.
And it's something that it seems that we could change very easy.
Right.
But the phone is not something that the people is changing every hour.
You know?
Absolutely.
Yeah.
So that's, that's really good that you're looking at the data model itself.
Great.
Awesome.
So I'm going to throw one more curveball at you for, for this problem.
Right.
So again, no code needed, but you brought up a great point about big, like large sets of
data.
So this is the rest API.
You can pass in data with the Jason body.
Now let's imagine that some guy got really bored and he took the U S census data, which is lots
of people.
And he started sending this into the API.
Um, I don't even know how much, how many rows that is, but you can assume it's millions
of rows of data.
Right.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
I don't know how many rows that is, but you can assume it's millions of rows of data.
So size wise that's, that's pretty big.
Right.
So what are your thoughts on that?
Like, um, do we want to support it?
Like just if, if, if, if you're, if you built this API, right then the project manager
says, we go, we have a problem.
We we're seeing this type of data come in.
What's, what's your like initial response?
What's your thought process?
Well, my initial response would be, why do you need to do that?
I mean I need to understand the challenge of the problem that is facing or why is doing that and why the normal way to do or maybe why do you need that and what the amount of data you need to send and what could we do in order to avoid if we are facing some kind of problems of costs or maybe of scaling in order to know if well it's something that you are going to do maybe once a week
or once a month once a year or are you going to do this every two minutes in order to to understand if it's something that is going to be once a year maybe we don't have a problem what we could do is create some kind of side process besides the REST API in order to have a way to insert the data maybe in the database with another different process more low level but maybe that we don't need this kind of API
but if if something that is going to be very useful I maybe maybe instead of using the same API as some user maybe we should create a new endpoint that could be more prepared for bulk data in order to avoid this kind of scaling problems and to be sure that we could validate like a huge amount of data instead of using the same one by one request
or trying to be sure that that is going to be quick that is not going to interfere with the rest of the API and that is going to solve the problem that they have
absolutely yeah I think those are all those are all great ideas and frankly like a lot of these are things that people do in the real world right
like if something like this comes in that's a pretty big data set like the code we have here probably won't work on a single node you might have to like scale it with like big data solutions or something right
so I think you're spot on there you know the the thing is that I experienced that in my work we had this problem you know that some sometimes when you are when you are working in a large company
so people from marketing or maybe another different department from development so they see that they have like available an endpoint and they see I have a way to insert some data I'm gonna use it I'm gonna write a small script and I'm gonna insert million of of I don't know the the
the points of interest in my case in my company it's a real estate agency and they wanted to add like point of interest in a map and they wanted to add like millions of it
uh and they didn't they didn't they didn't ask they just do it oh no yeah and it's it's different when you are creating a name point for from a user perspective that you are gonna insert one point point of interest or two or maybe five but you are not gonna put one million
and suddenly in Datadog we started seeing like the the amount of time yeah the amount of time that the request needed in order to to put data it was like and it was like doing timeouts and that was a problem because people couldn't use the map because the database was like stuck
and and the thing was and the thing was and the thing was and the thing was why are you doing that huh well I saw a rest api to insert a point of interest and I use it and yeah we have sometimes to like we have to be to be sure that the the app endpoint you could do that to insert some data but it's not like the same when you are insert inserting one data or one one one row or you are trying to insert like hundreds of it
so yeah it's interesting in order to explain that yeah yeah yeah that's when all like defensive programming comes in and I've I've been in the same boat right but not that exact same situation but someone finds your stuff they start using it abusing it you could do like api keys to lock down and like rate limit it based off of that there's so many options but it's it's a common problem so it's great that you've encountered it yeah
yeah obviously in our case we have rate limit and the thing is that we have a rate limit a simple rate limit with express and they they hit it but what they did was to to try to to jump over it yeah using our services you know like amazon and vpns with different machines like adding data
with uh some some clouds so it was it was funny right we were attacking ourselves yeah yeah that's um yeah absolutely that's great i mean not great but you know what i mean yeah it's a good experience to live yeah great um so this is good um i think we can wrap up the coding portion but i just wanted to call something out really quick so if you don't mind scrolling down a little bit the code you have um i don't normally do this
but so from line like 42 to 54 so here when you're writing this you talked about using for each and not using something complicated like reduced i think this is really good um to me it's a sign of seniority when someone's able to like justify the decisions they're trying to do in a way that makes the most sense and the justification here is that depending on who is supporting this code who's looking at this code
you might not want to use something that's a little bit harder to read harder to digest right because
the reality is not everyone who's coding in javascript or even in general is as familiar with functional paradigms
right so here you're just using for each it's simple it gets straight to the point um and it works really well
so i talk to people sometimes who get who kind of freeze a little bit because they want to do something really fancy they want to impress me
but frankly as the interviewer i'm not impressed by you using like fancy functional programming fancy like
constructs of your language i want to see that you're doing something that makes no sense and you can justify
your decision so i just wanted to say like i really like when you did that there thank you so much yeah
sometimes it's it's like the same i do interviews in my company and they try to use reduce and even
they sometimes they struggle trying to use it or understanding and it's like uh for me the most
important thing first when i wrote the code was i'm i'm going to try to understand the code me
for the beginning no and also trying to to think about if not only you but the people from the chat you
know they are checking the code and in order to understand as soon as possible so for example for
me i mean i had my times of thinking about functional programming trying to not mutate anything and
sometimes it's even worse you know for example in this case about creating this variable so sometimes
there are people that are like afraid of creating a variable because of optimizations and so on and
they do something like i don't know with their reduce they try something like that it's pseudo code but
they do for the accumulator they do something like this like like this join and then this and this code
that seems to be that's beautiful yeah it's beautiful but the problem is that you are like
recreating a new array in each iteration and it's expensive you know it seems to be great
but it's because you are not like creating it's it's beautiful because you are returning this the
the join directly but the problem is with this and you have to be careful with this because
then what you are trying to avoid about talking about optimizations complexity not not only about time
but space complexity and then suddenly it's it's it's worse so sometimes if if the variables it's
real it's very near the method i don't care about creating a method and mutating directly if it's like
four or five lines away if it's like 100 lines away i would be a more i don't know like concerned you
know but in this case i i think it's more reboot readable for the people and for me
yeah i i agree with yeah it's a common thing right like things kind of work in like small sandboxes and
unfortunately when people are using things like this they don't always understand how it works internally
and yeah if i had followed up with the scaling question and you had wrote it that would be like
i might have to rewrite this whole thing so yeah this looks good so let's let's stop the screen share
here and we can move over to some general like q a type of questions okay perfect cool so uh you
mentioned mongodb earlier uh and as well as the context of databases right relational databases
specifically so i just want to ask you a little bit about your thoughts between uh when you would make
the decision to choose using a no relational database such as mongodb versus using a traditional
relational database like postgres mysql so you can imagine maybe you're coming in to build a new
project for a client it's going to be maybe kind of a big project right so like what's your what's your
thought process behind that well it's uh sometimes it's a it's a complicated decisions decision i have to
be honest i mean i'm not a database expert but i had to work with databases uh in my times for me if if
you you you know for sure that is going to be a huge project and you have a lot of read and writes and
it's something that needs to be scaled fast you need usually you need no sql because you could scale
horizontally and it's easier it's cheaper it's faster in terms of scaling and even something that is not
necessarily good about the document model because it's not like it's not forcing you an schema
but in terms of the beginning of a huge project or something that you know that could be big it's
something good not having this kind of a schema because it's something that it lets you to go
faster and adapt to the changes for example imagine that you are creating twitter and you have like uh
you are not exactly you don't know if you need likes if you like some comments or or down votes and then
if you have a schema adapted to those changes quickly is going to cost um not only a little time to move
yeah yeah not only cost money but it gonna cost a lot of hours in order to be sure that the schema is
updated in a lot of things but with no sql you could just update the document you could even have some
documents that are not following the same schema that is something that could be dangerous sometimes yeah
but it lets you go faster but not always going to no sql could be the solution for example when you have
like a small startup you are not you are not sure about if you all need or you don't have still the
problem of scaling you know but you know you need the problem you have the problem with being sure that
everybody knows the logic business the schema the schema should be very rigid maybe it makes sense in
order to to have a sql and sometimes even you could try to bootstrap some ideas with sql lite i started a
lot of ideas with sql lite and after that you could move to postgreSQL it's pretty easy and right now
there are some great solutions like prisma that you could create some kind of abstraction of your
database you could start with sql lite and then when you want to deploy that it makes sense for example
for something that could be a block you know the structure is not gonna change that much it's not
going something that it's very easy to cache so you don't need the grades when the right operations
are not that usual and the read could be cached so it could make sense uh sql like postgre or mysql
and that's why wordpress they have mysql because it makes sense but if you have a facebook twitter youtube
uh i think it's a better idea having a no sql the only thing uh i remember some experiences you know
about no sql and it's the problem with the integrity of the data you know and that's something that a
lot of times happens and it's not that important but if that it's important for you
you have to go to sql for example you sometimes you could go to a video of youtube and you see
that you they have like one 100 views and 200 likes and you are like that's not possible right could
how could be that you have more likes than views and that's because they are using some kind of no
sql and the data sometimes is the integrity of the data sometimes it's not exactly the same
in terms of because maybe the documents are in different bases so you have to be careful with that
because if it's not important like like this it's not important about the views maybe after 10 seconds
it's going to get updated accordingly is that not the problem then you could use no sql but you have to
be careful about this because sometimes you have the same data repeated in different collections
and documents and you have to update them and maybe it's difficult to update them at the same time it's
yeah it causes that transaction exactly because they're not that's not sure exactly exactly so you
brought up a really interesting point about um like data integrity like schema with regards to using like
document database which is relational leaders right so if we imagine let's say let's say you're working
at twitter like year one right and you're using mongodb to set up all of your um all your data i'm not
saying that that's what they do but let's just imagine this is like hypothetical situation right so
everything's great and 10 years down the line you've become this really big company but you're seeing
a lot of issues with not using a schema that's enforced by a database so maybe you introduce a new
feature uh likes on tweets and now because there's lots of different teams that use this it's causing
some people's data to break because they have some assumptions around structure so like so that's just
the example right so my question for you is have you worked with this type of situation where um not
having a schema with a document database became an issue down the line and if so what kind of like
approaches or strategies that you use to alleviate that yeah so i had the same problem uh i worked in
a startup company from norway um that it was about articles like sharing news articles to a lot of uh
a lot of products and the problem is that we needed a lot of changes on the on the collections and the
documents and the problem is it was like wow right now it's like a mess because we don't have any schema
in our case what we did was when there's some kind of uh data model or something like this with uh mongodb
i i'm not uh familiar with but i know that there's some kind of modeling that you could do you could do
right now but in our case what we did was to use some kind of orm like mongoose in order to be sure
that we had uh a more control about well in in our times in my times we didn't have uh typescript so it
wasn't it was even more more interesting having this kind of object relation model because if not it
was very difficult in order to know uh the the properties that we were using creating and even
for inserting the data it was very dangerous because we weren't aware about the object we were putting
there so i think that some kind of control like this uh i know that it's not the same but some kind of
uh prisma um like mongoose something like that like that in order to be sure that you are using
some kind of a schema in fact mongoose you have this kind of schema and then you could do some
kind of migrations even in order to deprecate some of the we did that to deprecate some of the
properties to be sure to know which one is going to be used and which one not so this could be an
strategy yeah absolutely great yeah absolutely i've used mongoose before in the past like it definitely
alleviates a lot of these like pressures that you might feel if you're running into the situation so
yeah yeah yeah that's great it was you know that because when i started with mongodb it was like
mongoose it didn't exist yet it didn't exist yet right and it was so painful because mongodb is great
but you know we had this about inserting uh documents and we were putting the json directly to the
collection okay and it was like a mess and we had typos we had to do some kind of migration in order
to be sure that like normalizing all the documents of the collection and it was like millions of
documents so yeah when i when mongoose existed it was like wow and and we started using mongoose and
it it makes the the difference yeah absolutely yeah i when you said that i felt a little bit of
pain in there because i've experienced that as well so yeah that's uh that's great cool all right so
i've been talking a lot about like databases um let's talk a little bit about like a different topic
just so we cover some more um some more breadth right so i want to talk about application deployment
so there's so many different ways to get your your code into a live environment but based off of
your experience off of the excuse me oh sorry okay so based off your own experience working with um
like deploying applications right let's imagine that you're working locally you've written some code and
it works pretty well on your like a local environment and you want to roll it out into production
so this is maybe at a maybe it's a startup right and you want to build out this process process
pipeline so like technical and non-technical right what are your thoughts about how you would build that
out well for sure we need some kind of continuous integration uh well from the local i will start
from the local uh in order to create some kind of hooks git hooks in order to be sure that people is not
pushing some some code with uh errors from the linter or even with the ground commit messages so it would
be like the first defense but that's not enough that's like only in order to avoid people wasting
time waiting for the continuous integration and i would build some kind of continuous integration
like travis or github actions you have actions are very very awesome um and i would be sure to
again link the code but only the files that we change that the people push only the the files change
because for me conducive integration is very important but it should be fast because if not we
have a continuous integration of one hour it's like a lot of things could happen and you are getting
bored and you you don't care about it so we have to make sure that it's fast that we could paralyze the
jobs that we want to do for example i would create the install of all the dependencies i would then have
different jobs like the linter all the testing not only about the unit the unit unit testing but every
kind of testing that we have all in parallel like the end-to-end testing and i would build the
the application and it's very important to build the application in continuous integration and not in
local because people could link their packages change the node model so you don't control that kind
of system so it's very important to build the the project in the continuous integration to make
sure all the tests are passing there and you don't have the kind of message in my machine works well if
in the continuous integration is not working then it's another one for it yeah exactly and after that
unit testing end-to-end testing that for sure and after that i would there are some kind of
something that could be interesting even for startups at the beginning because the cost is very small and
i think that you get a lot of of insights is to when the like having some kind of data the how many
continuous integration and continuous integration are failing and the amount of time that it gets the
amount of fixes that you are putting in order to get some metrics like if we have a continuous integration
but we are pushing and 50 of the times we are getting some error we have to check it out because
if not it doesn't make sense to have a continuous integration that is not working absolutely so after
all the the tests and deploying creating a docker file in order to be sure that we could like put this
docker anywhere in any system and deploy we could deploy it in bursell i mean the hosting is not the
problem because right now we have like one million possibilities so many options yeah yeah so maybe for
a startup could be interesting to start with something like amazon because they have a free tier
and normally you want to i don't know to to have more more services you would like to have a load
balancer for me i would go directly to bursell or netlify or something like that in order to avoid
problems with infrastructure because if not because another thing to do in the continuous integration
would be to be sure to to put in a cdn the resources and sometimes it could be something interesting
in terms if you have people around the world could be interesting to put these resources near them
and yeah that would be all well and something that for me is very important could be the notify
notify in slack the deployment went well notify as well in the github the pull request
you have this url you could check the preview or if there's any error this is the error and for me
the web performance is very important so i think that it could be interesting as well to check lighthouse
ci in order to check if the application has some kind of web performance regression in order to avoid
you know because the problem sometimes is that you are like adding small amounts of regressions and
after one month or two months suddenly you are like build up yeah what happened here so lighthouse went
from 90 to like five what happened here yeah so that would be more or less my my approach yeah
that's great um i'm happy you called out some decisions that you would make because it's startup
versus like if it wasn't because it's a good distinction right not not everyone's gonna have the
same deployment pipeline depends on your resources depends on like level of complexity you want to
like spend up front building it and so forth yeah so absolutely great so you brought up some really
good points about observability about testing so i just want to kind of dive into that a little bit
as well right because a common problem i see with um application development is that a lot of more i
want to say like junior folks imagine that uh creating and deploying application is just writing
code and pushing it somewhere and that's it but you brought up some great points you know notifications
about like dashboards observability is such a big piece right we want to be able to understand the
performance the metrics for the stuff we're building so that we know how to improve it so again very
open-ended question but let's talk about like what you would do in the same context right startup
deploying pipeline but if you were to have like metrics captured tools and things that you would
like listen or look for what does that kind of look like so that you can optimize for how you would
have like a feedback loop for the things you feel okay so for me they are like well let's talk about
observability and then later i would talk about accelerate metrics because i think that developer experience
and giving the user as soon as possible what they need is important but about observability uh for
sure today nowadays there are a lot of services that they are very great and they are a bit expensive but
it's worth it like for example new relic datadoc apm in order to the datadoc apm it's like
very easy to use but the problem is that it's a bit expensive but i think oh yeah yeah it's very
expensive the thing is that uh startup that is in the at the beginning you don't have time in order to
build uh observability as you mentioned it's something that is difficult and a lot of people is not
concerned about doing a good observability it takes a lot of times so for me i would start with something
like datadoc apm in order to be sure that i could be sure that everything is working as expected
even this is expensive it's worth it because you need to be sure that your product is working out
there you know users are not having problems apis are responding what when one day what they have to
respond and the datadoc is great in order to not only get alerts and alerts that you could configure but
to deep go deeper you know to have some insights where you have to prioritize you have an api that
is slow in order even to improve the product metrics you know if you have an api that is slow when you are
buying something for sure you are losing money so you need to focus on there and the observability
should be done not only on the backend that is something that i i saw a lot of times but in
on the front end as well you could do some real user metrics you could capture very easy the errors
even promises that are not handled you could check even if the app is not working in some browsers and
the great thing about apm is that you get a lot of data you get the version of the browser you get
everything the user item but you have the filter for it and the great thing about going for apm and i mean
it's not like i'm i'm uh i'm selling apm i'm thinking like they should sponsor you or something
yeah yeah yeah it's not a sponsor i i swear there are there are other options like sentry for example
sentry is great but apm goes deeper for example with apm you could uh like connect the same request from
the database from to the front end you know and have the user the all the request journey journey
and that's great you know even when you are starting because when you are starting it's like
when you are a startup because i i was in a startup i have been in typhoon and in the norwegian
startup and you want to do observability and it's something that is great to have but when you are two
people it's like okay i want to do the servability but i don't have the time but it would be great so
pay for it you know don't yeah very useful to have it but you don't have the time in order to configure
as you want uh so at the beginning i would do that but if the startup goes bigger and bigger i would try
to create some kind of grafana you know to having because it's very expensive and having some kind of
parts with some great observability that you are building with your exact needs and put this kind of
data to grafana it's cheap it's great you even could combine with datadoc or grafana or something
like that and you could get some kind of interesting things and as i said not only about the backend or
requests with that but even with the web performance you could do some real user monitoring in order to
put that data in the datadoc and in order to know okay the user are using uh have a good experience
using our product so you could you could know with that yeah absolutely and i'm i'm very happy you bring
up like again like the business context right because when we're doing problem solving it's not just
taking something and applying to it taking everything has a cost be a technical cost time cost money cost
so talking about like what you would do because of like constraints that you have based off money time
team it's great and i think it makes a lot of sense so i'm happy you brought those things up
thanks it's because i felt it you know
yeah yeah you know when i mean i have been in startups i now i'm in a large company and you see
this kind of different uh approaches and in the last company it's like pay for everything or you have
you could or pray for everything or you have a team that is working on it like experimentation uh so
you don't have to bother about how to do an a b testing you don't you don't worry about it there
is a team for it and even for the infrastructure you don't worry about it but when you are in a
startup it's different not only about cost but time time is the the most expensive facility
yeah they want things fast they want you can't buy more of that either people can't fund you with
more time exactly exactly that's it yeah great awesome well thank you for going through that um
that's all the questions i want to ask you today miguel so i'm happy to say that i'm not passing no
skin no yeah so yeah no but overall thank you for going through everything thank you for you know coding
in front of me i know it's not the most comfortable but you know unfortunately this is like the best
thing that we have is to try to make people as comfortable as possible while being able to you
know validate that they can actually produce quality code right so thank you for going through
that thanks for answering all my questions i think you had a lot of great thoughts and great ideas so
um that's all i wanted to ask so i guess i'll hand it out to you now you can take back control of
this and steer how you want to go um you can ask me questions you can ask me to leave so you can talk
to your viewers without me here whatever you want yeah uh chat if you have any questions to justin
please just put the questions on in the chat and we we will ask them justin it was very funny i mean
i was nervous i have to say i was nervous because i haven't been in a tech interview for like five 46
years yeah yeah so do you like doing it very well yeah oh thank you so much i it was you are a great
interviewer i have to say because i felt comfortable and something that you do that i think it's very
important and uh a lot of people i don't know they don't do it's like like just say the things that
i did great even if i did something wrong you know and this is something very important even you say
like i like that that you said and it's like you are listening to me and you are like comforting me
so i i felt that i felt like at the beginning i was nervous but uh you said something about the
code that ah it makes sense i like that right and it was like more comfortable and more comfortable
and i i hope that more tech interviewers do that you know so uh congratulations for that because
oh thank you i really appreciate that and i think it's very important so yeah yeah i really appreciate
that like honestly so that's that's great yeah um you know when i interview people i i've done a lot
of interviews on the other side it's not always the best experience you get like really nervous
sometimes the person doesn't want to it feels like they don't want to be there and it's just not
a pleasant experience right so whenever someone's coming in through here i want to make sure that
while still understanding that they're going through an interview regardless it's going to be
stressful right but i want to make it as comfortable as possible make sure that while
they're going through it they're they're giving their best performance again understanding it's an
interview so just make it a pleasant experience overall right so i'm very happy you brought that
up so i appreciate it yeah it's it's the same i have been in a lot of interviews on both sides
and sometimes even as a shadow for with another partner and yeah it's difficult doing great
interviews is difficult because you want to to make sure that the people the person is a great fit but
at the same time you want to get the best of it you know about of him or her you know to be sure that
is comfortable enough so we have some questions for you we have a question about justin professional
experience what is his favorite language why what kind of complex project he had well out of a lot of
questions uh justin okay so professional experience and what is your favorite language okay um so i've
been doing this for over 10 years as well i don't i can't count how long but i mean i could but it would
be a waste of time so yeah so i am mostly a back-end engineer um i've had many roles before in the
past where i do full stack type of things i build front-end applications sometimes for fun but i'm
usually working on like large systems and building out infrastructure and um been on ways to handle
that so currently i'm working on a role where i'm building out tools and infrastructure for data
scientists in order to process that data provide them tools so that they can interact with their data and
do their like back processing streamed jobs service appointments and so forth so that's what i do
right now um my favorite language that's a bit of a bit of a tricky question just because like i wouldn't
say i have a favorite language uh i mostly use python at the moment there are lots of things i really like
about it but at the same time i think that python is as good as the people that you're working with because
it is so open-ended you can see lots of ways of doing things and frankly most of the ways of writing
in python are not the best in the context of working in an engineering team so for example if
i'm looking at how to do something i start googling up how to write something in python i might get
results that are from statisticians or data scientists and the code they write works really
well for what they're doing but i'm coming in from the context as an engineer the code they write might
not be might not be the best way to write it with regards to performance maintainability and stuff
like that right so python itself great language but the way it's used is way too open-ended so i have
a bias towards typed languages and i used to do a lot of java um not the biggest fan but you know it's
kind of like it's too rigid so i've been doing a lot of golang at the moment i find it's like a nice
balance and very pleasant but the surface area for what you would write python applications for
versus golang applications for don't have the cleanest like intersection like there are some
overlaps but because of that i can't just have this is my favorite language i'm going to do it for
everything it's like use case specific right yeah that's a a great answer as well it depends
yeah it depends it depends as like all things exactly so we have some uh massinger's team is asking
justin what is the english level of midu midu with me you could be honest don't worry about it yeah
mas o menos oh yeah so justin you have better spanish than me english no no it's it's okay
but justin that's a surprise what's happening here okay so that's the the the hidden spanish you
should you should return to your spanish knowledge i should but it's uh you know it's it's it's hard
your english is very good um i have no complaints about it you are able to work in it professionally
with with no problems whatsoever okay perfect thank you thank you so much uh so dartiles is telling
can you give a feedback to me to improve don't worry yeah you could be honest
you know like honestly like i can't really think of too many things maybe it's because
like you know i'm coming in here like happy face joining here um i will talk about things that you did
really well and things that i think that if you incorporate it a little bit more that would make
it even better because so when i'm doing these interviews there are certain things i'm looking
for right i'm not just looking for someone to give the right answer i'm looking for someone to be able
to convey their experience and convey decision making those those are two important things because
if you don't have experience um then that's a problem so experience uh sometimes people will
talk about the react projects they've built and when i ask them about them it turns out they've
just been doing like toy projects that they learned from like medium articles right i need i need
professional experience that's been battle tested very similar to what i talked about earlier with
regards to deployment right if you've been building toy projects you probably never really use like a full
deployment process you get in production and understand the problems that you'll run into
right very common like cores lots of first-time learners of front application run into course issues
right so having professional experience is so important because it shows you've run into certain
problems right now the second thing i look for is with regards to um problem solving so i am of the
opinion that as developers as engineers we are trying to be open-ended for how do we do things we should
not be prescriptive for how we solve problems one person coming in maybe they used to work at a
really big company and they did things a certain way they can't go to another smaller company and
impose that on them so you talked about this a lot with regards to how you would make decisions
based off of like are you a startup how much time do you have um what is the team you're working
with right all that stuff is really important so that's great i really like that and i think if you
can tie this in a little bit more with like professional experience as well like i've done
this before in the past like where i had to do this explicitly right i think it'll be useful but
at this point i'm trying to like pull things from like an empty bucket like i really think you did
really well and i'm not just saying this well i am just saying that but you know what i mean i think
you did that because of those two things so it's really hard for me to nitpick and cherry pick out like
things that i think you would improve on but there's always room for improvement and being
able to like fetch those things out will just like you know improve the overall quality of like the
things you're talking about in general as well i i think it's a great feedback i mean it's super
important i think it's a good um piece of advice for everybody in order to put on the table your
experience as every time that you have the the opportunity to to show your real experience i think
it's a great advice piece of advice for the people it's super important because as you said it's like
sometimes it's not only about code it's it depends you know and if you put uh it's not about grown
answers it's about good explanations and it's good about making mistakes because the only way to
learn is about mistakes you know you don't learn about making everything perfect and that's not uh
that's not how it works so i think that giving experience about yeah that's a problem that i
faced and the way to do to solve this was that and we were wrong you know but uh we learned about this
i think that's great that's what we are looking for yeah absolutely yeah so thank you uh so another
last question and that's the last one justin okay okay what steps will remain when you become a
feature developer and a company is interested in you at arc do you consider relocation for latim
applicants i don't think so because it's remote but okay let's see what's this remain when you become a
feature developer and companies okay okay so um imagine that i passed i passed the the the process right
so i'm gonna preface this really quick by saying like i handle a lot of the interviewing pieces
and that's like with regards to the processes like afterwards like these things can change i can tell
you the state of the way things are now but for more like detailed answers and stuff to this there are
better people at arc that i can direct you to however the answer at the moment is once you're a
once you've passed the assessment at arc you are good to go like we typically don't ask you to like
like that's all we need from mark we know your background and your strengths and we're not going
to ask you to like go through an assessment again for a new role it doesn't make sense right so there's
that it's a lot of time now to become a featured developer this is a special program that we have at
arc where you're featured for a two-week cycle it means that you have your profile built out on arc
um we support you throughout this process it's a two-week cycle and during this um companies who
come to arc will be looking at profiles from featured developers and they will apply to you
it's the reverse of your typical model for job applications right during this process and we also
provide coaching at arc um free 30 minutes and you come in and you can ask any questions you like how
can i fix my resume how can i fix my introduction um i'm having troubles with these types of questions
interview interviewers ask me so we want to help you make you successful right because um you arc
doesn't cost anything for you as a developer um we get paid when the client hires you on so we are
extra incentivized to make sure that you find a role that you like that you'll be successful with that
you will love right so um so there's that right uh one time assessment at the moment from arc uh you
become featured for two weeks if you don't find a role in two weeks arc will reach out to you to ask
if you want to be bumped down the list for the next two weeks and it's like a it's like a for loop right
when you break depends on when you want to stop or when you find a role right those are your break
conditions and for relocation uh we do not offer any relocation because like what miguel said
we are a remote focused organization however uh when you find a full-time role through a company
they might offer you relocation uh through the company themselves right we don't manage any of
that but that is a possibility based off of who you end up working for interesting awesome justin
thank you so much it was been it has been a pleasure and very interesting the tech interview i was a bit
nervous but thank you so much for doing it very very well i i felt very comfortable and thank you so
much for being here and answering all the questions and doing the the tech interview thank you so much
i hope to see you you here sometime yeah i mean if if people if afterwards you check the chat and
people aren't like angry at me because no they are not then you know i'd be happy to come back but
they are they are super happy with you they are super happy yeah thank you justin thank you justin
thank you thank you a lot of thanks there's they'll tell you justin te amo mi amor well that's
too much but it's something about love well thank you thank you so much justin all right thank you for
your time i really appreciate it thanks for you know sharing my presence on extreme and no i hope to
talk to you soon talk to you soon talk to you soon all right bye everyone thank you so much bye