Help us to make this transcription better! If you find an error, please
submit a PR with your corrections.
Luciano: AWS expertise is in high demand. We both work for an AWS consulting partner, and we have seen hundreds of applications for roles in AWS development, architecture, operations, and data engineering. If you're looking for a role like this, whether it is your first of such role, or you have lots of experience, this episode is for you. We are going to share our process, what we look for, how we try to make it fair, and give some tips that we hope we're gonna help you and people like you to learn the role that takes your AWS career to the next level. I am Luciano, and here with Eoin, this is another AWS Bites podcast episode. AWS Bites is made possible by the support of fourTheorem, an AWS consulting partner that works with you to make AWS migration, architecture, and development a success. See fourtheorem.com to find out more details about that. The link is in the show notes. Should we just jump straight and describe the application and the interview process that we do at fourTheorem, Eoin?
Eoin: Yeah, we're happy to share this and find out what people think. When we're hiring at fourTheorem, especially for AWS expertise, it is important to state that the process isn't just about testing AWS knowledge. In general, it's a two-way process where the candidate and fourTheorem are asking questions and listening to see whether there's a mutual fit for both in terms of culture, way of working with them, way of working and the type of customers we work with, skills and knowledge, of course, but also future plans in terms of the company and growth opportunity for the candidate as well.
Process in general, like we've evolved this over the course of the last five or six years, and when we get an application or a referral, we review the candidate. Sometimes we have a CV and a cover letter, sometimes not. Sometimes you just get a LinkedIn profile or maybe you get a referral. If it looks like a possible fit, we'll just go for the first interview. And the first interview is a 30-minute introductory call with Fiona, who's our amazing founder in charge of finance and people.
And that's really about listening to the candidate and giving the candidate an opportunity to hear about fourTheorem and learn more about us. And if this indicates a good cultural fit and the general agreement, we'll go to the next step. And the next step is a one-hour kind of conversational interview with two people usually from fourTheorem. Those people are generally in senior technical roles, not exclusively.
And this is where we cover a lot of broad topics, including the experience, your knowledge, expectations for you, your future plans, what you want to do next, not just where you've come from. We also talk about technical skills, but then there's the aspects like how people work, what kind of process they work in traditionally, what they liked, what they didn't like, what they'd like to change and do differently, how they communicate the team ethic and how they like to work with others and how they have in the past.
And there's no right answers really here. You know, you don't have to be completely worried about your previous experience. It's more how open are you to in general. It's also a good opportunity for candidates to learn about how we work at fourTheorem, the kind of projects we do. So after that, if everybody's still happy, the next step and the final kind of interview phase is another interview, but it's a technical interview.
And this is also one hour. And the candidate has a choice here. So there's three options. They can do a collaborative coding exercise where they start a solution to a brief technical problem that we present. Actually, we present two problems and they get to pick one. The other option is a take home coding exercise, which is the similar kind of thing, but they just do it on their own time. And then they come back and present it and discuss it.
And the third option is that they can present a project that they have already written prior in like other previous work. If it's something they can share, maybe it's an open source project, maybe it's something they just did for fun, whatever you have. So we try overall, like we try not to take too much of people's time. In our view, if you take more of people's time, you should start paying them at that point. I know that some companies have take home exercises where they expect people to work for days or weeks. I just don't subscribe to that. So let's go into some more detail and about how all this works. Luciano, in general, if you think about the roles we are for, what are the things we're looking for?
Luciano: Sure, so I will say that in general, we are looking for technical knowledge and skills, but I think it's also fair to say that in this industry, we tend to overemphasize that the importance of how much technical skills do we need to have to land a job in IT or technology in general. I think that level of skills really depends on the type of role that we are hiring for. If we are looking for very senior roles, we have certain levels of expectations, but I think there is a lot more that we need to bring in the picture to really evaluate a candidate.
It's not just about technical skills, for sure. And just to give a little bit more context, because context is probably important here, I think we need to describe a bit how we work at fourTheorem, because of course that is important in the way we hire people as well. The majority of our work is for clients. So we basically work as architects, engineers, bringing our expertise with AWS in the context where a company is trying to migrate or build a specific system in the cloud.
So most of our expertise is on AWS, so we try to bring that on board in the project, but we'll need to be flexible in the sense that we will be working with a range of different technologies, because our customers might be very different in terms of all the different kinds of technologies that they use, including software, programming languages, and even methodologies that they use to actually work together.
So I think in most cases, it's important to see when we try to evaluate candidates, how that ability of being flexible and take ownership and have conversation with the customers, it is actually part of the personality of the person we are trying to interview. So that's something that is important to be successful in our company. So it's a skill and probably like a more characteristic also of the specific character of the individual that I think it's very important for us and sometimes can be as important, if not more, of technical skills.
And I think that needs to be also mentioned together with the fact that internally we do a lot of training, we do certifications, we have acceleration programs, we try to share as much knowledge as possible, we try to pair individuals. So we believe that even if you don't have the most amazing technical skills, we will give you the tools to get there. But I think it's much harder to give you the tools to learn how to deal in this environment if you are not already kind of a cultural fit for the particular kind of environment.
And another interesting point is that going back to the topic of different levels of skills, we will be hiring from junior to all the higher level, like principal, senior, architect, whatever you want to name them. So that again, the skill expectation will be proportional to the level of experience that we are hiring for. So I think in general, if I have to summarize a few points, what we're looking for are people that are curious to keep learning and building, even if they are very senior, I think we want people that still accept that there is always more to learn, there are always new methodologies, new technologies, and it's always a continuous journey of exploring what is the possible today and trying to do our best with new tools that we get all the time.
People that are collaborators, so people that don't just want to work in silos, just write code all day on their own and just come back with a fully completed solution. We actually want people that can have a positive impact in a team, they can have conversations at the very beginning of a project, work together on building the project, reviewing failures and reconsider the approach, and always be there to try to help each other on what can we do to do things better, what can we do to get better as engineers, and how can we improve our work style, but also the work that we do with our customers.
And I think to do all of that, you need to have a certain degree of compassion and empathy, because that's, I think, kind of a fundamental key that enables a lot of the conversation and a lot of the collaboration activities that we try to promote in our company. On the technical side, we want people, as I said before, that are flexible, so you might have, of course, your own preferred choice of technology and tool, but you need to be flexible to work also with other things, and ultimately, you need to be aware that there isn't really a silver bullet for things.
All technologies, they will have their own pros and cons, so you can use all of them probably to achieve the specific goals that you have. So another thing that is important is very often when you join a project that is in progress, there might have been a lot of decisions that have been made before you actually started the project, so that if you just look at the current picture, there are a lot of things that might look weird or wrong, and I'm sure that that happens all the time to everyone, but I think you can have an attitude of just saying, this is wrong, we should have done this differently, or a much better attitude, which is the one that we will prefer, is to start to ask questions like, why are we doing this?
Have we considered that? Is there anything that we can experiment to see if it's a more viable solution? And I think that most of the time that I've done that in my career, I have found that actually there is a very interesting history that led the project to be in that stage, and you can learn a lot from that history, and that can give you a lot of insights on what you can be doing next. And if you just look at the current static picture, it's only telling you a very small portion of the story, and it's probably not enough for you to be successful.
So we want to really make sure that people will have that kind of attitude, or at least that they can be open to approach projects in that way. And other couple of things, and I'm gonna speed up just not to bore you too much, is that we are just looking for people that are not expected to know everything, but are more aware that they don't know everything, but they know that they can learn and what to do to unblock themselves, what to do when they need to ask for help.
And if there is a project with lots of unknowns, they can work with that and figure out how to move it to a better place where all these unknowns are slowly being addressed, and we move to a position with more certainty. And the last point is that we really appreciate not over-engineering things. Sometimes it's very easy, especially when you're starting a new Greenfield project to over-engineer everything and just try to do everything in your perfect ideal way, but we still need to be pragmatic because at the end of the day, we are working with businesses.
Businesses will have specific needs, goals, timelines. So sometimes you need to find the right trade-off between what can we achieve in a short term that gives value and then take an iterative approach to keep improving things, rather than just trying to make it perfect at the first go and maybe take months and months before you can deliver something that the business can use. So one final point I have, I already said that that was the final point, but there is one last one, is that you might see us doing a lot of public speaking, podcasts, and so on. This is not necessarily the only kind of people we hire because we appreciate that it's not for everyone to be engaged in public speaking, and you can still be an amazing professional even without doing all of these activities. So if you think that you need to be a public speaking person or a very public profile just to be able to work with a company like fourTheorem, we definitely don't think that that's the case. So just want to make sure that that's clear. That's definitely not a prerequisite. What about the application? So let's just say that we receive a CV or we receive an introduction. What do we do at that point?
Eoin: The CV, LinkedIn, referral, email, or all options, we may just ask for a CV further down the line just as it helps with the interview process. We don't use any kind of automated software for interviewing people. First of all, we just review all the CVs and the applications and just discuss them before deciding whether to proceed or not. I suppose in the past, we had some kind of organic growth and we've been fortunate enough to hire people just from our network.
And also just because people hear about us and like what we do, we get applications directly. We've managed to get a decent, I suppose, proportion of high quality candidates. And we generally don't use recruiters and take unsolicited applications. When the profile is an internal referral, we generally get a little introduction from the person who may have worked with them in the past, introducing the profile and thinking, saying whether they think they're a good fit for fourTheorem.
It is important to note that the person who does the referral won't be involved then in the interview process, just to keep it as unbiased as possible. It's also important to notice that you don't have to have a computer degree. You don't have to have a degree. I've hired great people with computer degrees, computer science degrees, also have seen applications from people who do and haven't had great application success.
I've also worked with great people who've got different degrees in different fields or none at all, and just have great experience and just a real passion. So those things are not hard requirements at all. And you don't have to have an AWS certification either. I mean, these things may help just to show some basic level of knowledge. We talked about that in the previous episode, which we can link in the show notes about certification. It can be helpful in some situations, but it's not the be all and end all. So once we have the application, as long as you put a good bit of effort into presenting the application well, we'll go to the next step, which is the all important Fiona chat.
Luciano: I like the title. We should rename it internally like that. But yeah, this conversation is the first starting point is more just to have a first impression on both sides of what the company looks like, what the opportunity looks like, and for us is to have an opportunity to get an impression on the candidate. Generally, the topics that are being discussed is what can we offer as a company? So what is the work-life balance that we try to promote?
We are a remote company, so we work remotely. We don't even have an office. So that's an element that we present at this stage and that some people might like it, some people not, but it's something we need to make very clear very early on. Then we also talk about what can we offer in terms of bonuses scheme, holidays, and other benefits. And in general, I think it's an important conversation point to get a feeling for what the future will look like on both sides for the company itself, like what are our plans for the future, but also if you are gonna be part of this company, how can you expect to grow in the company, in your role, what can be basically the evolution of your profile if everything goes well in this particular engagement. So this part of the interview isn't very technical. So it's more about cultural fit. It's more about understanding if there is a common ground. And then if we see that there is a receiver or expectation that is aligned, then we can decide to move on. Otherwise, I think that that's probably the point where the interview stops. But let's say that everything is great. What do we do next?
Eoin: The next one that this conversational interview we mentioned at the start, it's I think at the one I really try to focus on the most, I think, and in it, we cover your experience. If you have some experience, this depends completely on the level you're at and what stage you're at in your development career. When you're talking through your experience, I would say don't just talk through the technologies, but also the process, the business goals, the business context, having awareness of that wider picture is really interesting for us because we're working in that way with our customers.
So we would ask questions about how you work in a team, what process you like and how you've addressed challenges. We're also kind of interested in cases where you help others, collaborate with others, maybe mentor others, and also where you're open to help. So showing that you have some humility is very valuable here. Are you open to listening and learning from other people? Even people who are more junior, this is a very good indicator in terms of the principles of empathy, openness, humility, curiosity.
Everybody has a voice in the company. So if you think just because you've got 15 years experience that you shouldn't listen to graduate engineers because they can't know any more than you, then that's probably not a great fit. We would, of course, have questions from the candidate then about fourth year and how we work, what our projects are like, what our customers are like. And then if we're hiring for an AWS role, of course, we'll ask you what you've done with AWS, what services you've used and how you have used them.
It's not about listing off 250 services. There is no number to reach at this stage. It's more a question of how you use them and depth certainly more important than breadth in this case. Maybe some interesting story about challenges you faced with AWS is interesting. And then sometimes we ask general questions, technical questions. So an example is like, how would you build a landing zone page with a signup form for some case that we would devise?
And usually it's a very simple question or at least a simple challenge that we're presenting. So we're not trying to trick anybody. It's not a really intense kind of a question. It's just understanding how would you go about thinking about a set of business challenges and turning it into an architecture or a piece of software. And one hint I would give here, and maybe it's a little bit of a spoiler, but you don't always have to use AWS when you're describing solutions.
And if you think you do, then that might actually work a little bit against you. It's a very positive sign for us to see people who don't just reach for AWS every time, especially when there are simpler, better solutions for the customer out there. Sometimes the simplest better solution for the customer is don't build anything. There's an off the shelf solution, for example, or don't build anything.
There's no business value in that. It's not worth the effort. You know, those are equally valid answers for there are customers. So that's really good if you can show anything like that. So then we'll also discuss, because there's time generally here, what life at Fora theorem is like, and begin to hopefully paint a picture in the candidate's mind about what it might be like if they decided to go ahead and get a job at Fora theorem. We've had the half hour chat with Fiona, this round about an hour on the conversational interview. We've got one hour left of people's time, and that's the technical interview. I think this can be daunting for people, the idea of this. Nobody likes to feel like they're in the spotlight being tested on their technical prowess. Hopefully we've got some solution to that. What do you think Luciano? Have we solved that problem here?
Luciano: I hope so, but I have to be fair because I am one of those people that enjoys doing the kind of art core coding challenge and type of interview. And I've been practicing that a lot. So I think for a long time, I had an expectation that that was the way to do interviews for everyone, but I'm glad that in Fora theorem, we all recognize that it might not be for everyone. Different people might not necessarily shine in this kind of setup.
And that doesn't necessarily mean that they don't have the technical skills we're looking for. So one of the things that we do is we try to offer different options. We try to offer not just a coding exercise on the spot, let's do something together, let's solve a specific short problem. It could be also, if you have a project you have been working on, you can present it and then based on that, we can ask you questions and we can have a conversation about that.
And our alternative is that if you prefer to build something which needs to be short, you can just do it as a tech home exercise, but we wouldn't expect you to spend more than a few hours working on it. And then we just use this extra hour to discuss your solution. So we have these options and based on the option, the interview might be a little bit different, but in general, I think it's worth remarking that the coding bit or the coding assessment ability bit is still important, but not the most important part, because what we care the most is how do we work with this particular person?
How easy it is to basically understand what is their approach, what they're thinking about a specific problem. If they understand the requirements, if they are specific questions to clarify some of the requirements, it doesn't matter too much if they complete the problem and solve it in the most perfect solution. It's more about this entire process, this entire conversation and this kind of collaboration experience.
And I think in general, our position is that you can get better at coding throughout your career, but to have the kind of communication skills that we are looking for, it is a little bit more difficult to develop those if it's not part of your character. So we try to balance the interview in that way, trying to put more emphasis on, are you the right fit for this team? If you are, even if you don't have all the skills we need right now, you can develop them easily. Otherwise it's probably going to be a much harder conversation. So I think in general, ER is just important to establish that relationship with the candidate, make sure that there is good communication, make sure that there are enough technical skills. And I think that would be probably more than enough to, to pass the interview, but I think there are some common mistakes that people will do. So can we give people suggestions to, to avoid some of these mistakes? Yeah, let's try to do that.
Eoin: I was also just going to say as well Luciano, because we've emphasized communication quite a lot, and I don't want people to get the impression that we're talking about looking for people who've got like perfect English or super eloquent or have a great vocabulary. It's not, it's more about being open to listening and asking when you need help or being willing to communicate ideas. So it's not, it's not about having perfect English and about being an extrovert for sure.
Where lots of us at fourTheorem are more kind of social introverts. So we completely understand if people aren't like super outgoing and bubbly, you don't have to be a great talker. It's, it's more about great communicator. And there's a big difference there. It's more about, can you work with other people? And I think people generally know what we mean, hopefully when we say that. When we talk about common mistakes, one that I think comes up quite frequently and is a real shame is when we see people just not listening or letting the interview speak, interviewer speak properly.
Sometimes this can, we all understand that people are sometimes nervous in this case. So we'll always try to take that into account. But if people are just trying to dominate the conversation and talk over the interviewer and present their ideas and kill the conversation from the other side, that's not a great indicator for collaboration and just dominating the conversation in general is not a good look.
Especially in the technical interview, I've seen lots of technically proficient people who don't end up getting an offer because they just want to take full ownership of the solution and present it as their work. And we try to present it and make sure that people know that it's a collaborative coding interview where we kind of talk together and we see how we would work together. It's not about showing what a rockstar you are, because that's really not what we're looking for at all.
It's actually a big turn off. We're looking for people who can work with our clients, listen to them, collaborate, who show that humility will ask questions when they need it. And we say to people, look, it doesn't matter. If you can't remember, if you're, we let people do the coding interview. If they're doing the live one or they need to take home one, or if they're presenting something, it can be any language, any technology, any platform, whatever tools they want to use.
It's completely up to you. First of all, I would say pick the language that you're most comfortable with, not the one that you think will be most impressive because there isn't one that's most impressive. It's generally just the one that you're more comfortable with. But if you say, okay, I've done JavaScript for 15 years, so let's do JavaScript. And then all of a sudden in the interview, you can't remember the name of the function to get the all the properties and values of an object.
And you have to go to MDN and look it up or Google it. That's completely okay. I would say just do that or just ask the interviewer, do you remember? And just say, I don't, I've forgotten what this is. This happens to us all, all the time. So it's much better to be open and honest. That brings us to the second common mistake, which is not admitting when you don't know. It's too easy to tell when people are bluffing and the culture we have with our customers is one of radical transparency.
So our customers trust us and value us more because we don't try to bluff. We'll quickly admit when we don't know, and we'll openly admit our mistakes. And that means that when we say we do know something, what we say is valued, right? So I think it's very important when you don't know it in interview context to say so. A third one is not asking the interviewer questions. So if you need clarification, you should ask.
And it's just a good idea in general to show you understand and collaborate with others by engaging in a proper conversation. It shouldn't be a one-way quiz. The last common mistake, you've probably heard it before, but it's just like basic errors on CVs, cover letters and emails. Now we understand that people make typos. We all make typos and mistakes. These are all very common, but a CV is a chance to show you have some pride in the quality of what you create.
And I think it's quite easy to get it right these days. I'm kind of amazed sometimes that we get CVs in from a recruiter and the recruiter hasn't helped the candidate to improve the quality of the CV as well. I wonder what value is being added if they're just passing on the CV exactly as it is. So please just like get when you're writing a cover letter, if you get our names right, get our company name right, get the spell, the names of the technologies you've worked with correctly. It's just better. You're giving people much too easy an opportunity to reject your application. If you've got basic mistakes at that stage, that's the negative side of it over with. What happens then after the interview Luciano? I think this part is actually very easy.
Luciano: We generally have a small group of people that have been involved in the different stages of the interview. So what we do is we just have a chat among ourselves to just get a feeling of what do we want to do with the candidate? Do we feel comfortable going forward or not? Also we have been collecting notes throughout all the different phases. So we already have a feeling for everyone else's opinion. So we might just discuss the points where opinions might differ and decide, okay, well, let's take a decision together. So at this point it's more a matter of, it is a yes. Are we going to make an offer to the candidate or we stop the interview there and we just give them a rejection. So depending how it goes, it might be a yes and happy times. And there is the usual conversation in terms of negotiation timing and if the candidate accepts the offer is just about the logistics of getting started. But if it is a no, what do we do then?
Eoin: Well, we're always available to give honest feedback to people. Some people want to hear it. Some people don't, you know, if they don't get the role, then they're just happy to move on. And often actually it's not that the candidate isn't great. They often are great, but it's just not the right fit at that time. We're always careful to just kind of think about what they would do when they come in, who they would be working with. If you've got the kind of team dynamics, right? So sometimes it just isn't the right fit at that time. And maybe you're too experienced or not experienced enough at the right time. And sometimes also it's not a no from us, but a no from a candidate because they don't see it at the right fit for the right time. And in both of those cases, sometimes you just resume the conversation down the line and the timing is better. And we have done that in the past and it has worked out very well. So I suppose in conclusion, what can people take from all of this?
Luciano: Yeah, I think we focused a lot on fourTheorem and our specific project process, which is very tailored to our needs and our company culture. But I think there are some things that you can take away, either if you're not interested in fourTheorem as a potential candidate, or maybe you are hiring people in another company. So what can you learn from all of this? What do we think is important? And if you're hiring, I think it's important to always make sure that you give candidates a very clear view of what's the interview process, what would be the different steps, what is going to be the timing, and you share all this information as early as possible, just to give them a chance to come prepared and try to be, to be the best version of themselves, I imagine, for the interview.
It's also important though, to give them different opportunities for expressing their skills. Again, talking about technical challenges, we realize, and I personally realized that hardcore pair programming is not for everyone. Even amazing developers fails them just because there is so much pressure and they require a specific environment and not everyone would be comfortable in working in that environment.
And this environment doesn't really reflect the reality of the day-to-day job. So there is also that to keep into account. So just be aware of that. And if you feel the candidates have good technical skills, but they might be afraid of that kind of approach, try to think about alternatives, try to figure out what are other ways to assess the technical skills of that particular candidate. And I think that kind of leads me to a more generic comment of just be aware of potential bias.
I think this is more and more important these days. There will be candidates with all sorts of different backgrounds, and that doesn't mean that they cannot contribute to the company, that they cannot be good candidate, they cannot contribute to the team. So try to always assess whether you are projecting some bias on candidates and try to be honest with yourself and figure out, am I taking this position because I have a bias, or maybe there is an actual problem with the person that is not going to be a fit for this particular role or company.
And I think I personally have to try to do that myself more because I think there is always some kind of bias that we kind of underestimate. So that's probably a suggestion for myself as well. So on the other side, if you're looking for a new role, so if you are a potential candidate trying to look for companies and maybe specifically in the cloud space, I think there are some generic suggestions that we can take away from today's chat.
And for sure, you need to try your best to prepare yourself for the interview. Don't just walk in without even thinking about the interview. I think the interview is still important. You still need to do some preparation. You still want to do a research on the company. If it's a technical interview, maybe there are topics that you want to review because maybe you know, you're going to be chatting about cloud architecture.
So do you have some use cases in mind that you can immediately start to describe and explain when that kind of question comes up. So don't, I would say don't underestimate interviews. Don't just think that if you have been in the industry for many, many years, by default, you're just going to shine in an interview. I think it's still important to do some amount of preparation. And when you walk into the interview, always have a positive attitude, be curious, ask questions, try to learn as much as possible about the company and the people that work in that company.
If you are doing something technical and you feel like you are getting stuck, it's totally fine to ask for help, to ask for clarifying questions. Don't try to just come up with the best answer to every question. Sometimes the questions are actually strategically created with some gaps just to see what is your reaction? Are you going to be asking for clarification or just going to make a bunch of assumptions around with them?
So just be aware that sometimes it's actually the best strategy to ask for a question and make sure you really understand what it is being asked. And finally, I would also suggest people to be proud of the work that they've done so far. I'm sure that everyone has very interesting stories. Even if you are a graduate, probably there are things that you have done through your journey to get where you are.
And I think you can find ways to highlight where you're coming from and how you can be valuable for the team or the company. So just keep that in mind and use that to also give you an extra positive attitude. And I think with that, we are at the end of this episode. I'm sure that this episode was probably more opinionated than any other one we've done before. So I think it's really, I'm really more excited to hear about your opinion. If you agree with our approach, if you do something radically different, do let us know in the chat, because I think we can all learn and we can all get better by sharing the different experiences in this field. So thank you very much. And we'll see you in the next episode. Bye. Bye.