PS: A lot of people told me to make this article a paid, short e-book. This didn’t feel like something I wanted to do with it. Be patient with me though, a book will eventually come. I (will) have many, many things to say.
TL;DR You will most likely fail many times. When you do, don’t just try again, try again with wisdom.
For a long time, I wished this article was simply…written. I wished the words would dance their way out of my mind unto a server so that it could be read like this by you. Of course, that didn’t happen because I cannot wish anything into reality except, perhaps, procrastination. It took me four months to write this; I hope it’s interesting enough for you to read in one sitting.
My journey is a bit complicated, and like most people, I don’t remember every part of it. The goal of this article though is to talk about parts I remember because I realize the importance of documenting. I will talk about the hard challenges, lessons, and communities that I believe contributed to my getting into Google.
I hope my story inspires you; I hope it spurs you to believe in yourself and to take the right action.
First Big Break
The first time I ever imagined working abroad as a Software Engineer happened in my second year at University. I heard about some Covenant University alumni who had worked at Bank of America Merrill Lynch (BofAML) & Goldman Sachs (GS) in a conversation. I remember being fascinated at that moment by the fact that working abroad hadn’t even crossed my mind until that point; I suddenly became more aware of how one’s environment can limit the future that one aspires to.
Anyway, I digress. I heard about other people who had done it, and then I realized it was possible. So, I decided to explore.
I applied to many different places throughout my time at University, but I’ll focus on two companies: BofAML & GS. These two were investment banks with similar pipelines: Spring (2 weeks) → Summer (8–10 weeks) → Full-time. You keep progressing if you perform well and the ultimate goal is the full-time offer. Between 2016 and 2018, I applied to both at least 3 times each. Adding other applications, I submitted something between 50–100 applications.
My applications to BofAML are a bit hazy; I submitted multiple applications and got multiple rejections, but I only remember a few details. One particular one hurt though, in retrospect. I had gotten to the penultimate interview stage and I was asked a complex-sounding question that actually translated to: How do you find a value within an array?. The answer was a simple explanation about traversals. Yes, all I needed to do was explain for loops. I only realized that this is what the question meant a long time after the interview. The lesson here was that I didn’t understand Data Structures and Algorithms (DSAs) intuitively. The lesson was that wordplay was enough to confuse me. I got a deserving rejection.
Like BofAML, I submitted many applications to GS. I remember the first time because of how memorable it was; I applied for the 2016 Summer internship. One of the requirements for the application was a cover letter explaining my motivations for applying to GS. I don’t remember why, but I cut it really close to the deadline, so I had to rush. I thought I came up with something cute though.
The other requirement of the application was taking a math test. I had my trusted calculator, so everything should have been grand, right? Well…no. Immediately the test started, my calculator’s battery died. You know those situations when something terrible happens and the only thing you can do is laugh? This was one for me. I don’t remember how long the test was, so I’d like to scale here: if the test was an hour-long, I spent about 50 mins trying to get a new calculator to no avail and finally realized in the last 10 mins that I had a brain that was quite good at mental math. It was all really clumsy, and this time, I got a swift rejection. I learned two important lessons. First, it’s good practice to have a fail-over; if I had an extra calculator or battery, I would have been fine. Second, it’s good to consider all available options before making any decision; if I stopped for a moment, I would have seen that the math questions were easily solvable by my mental faculty.
The year after, I applied to GS again. This time, I applied for the 2017 Spring internship. I felt really good about this cycle and I wrote one of the best cover letters I’ve written to date. I understood GS’s business and I knew where I wanted to fit in; I had practiced interview questions and I spoke to current GS employees to get “inside gist”. It all fell into place and I got the offer for Spring.
The more exciting part though was getting an offer for the 2018 Summer internship after I killed it during the Spring internship. This meant that the next stage in the pipeline was a full-time offer; all I needed to do was kill it during my summer internship as well.
My japa plan was now in hand…or so I thought 🙂.
First Big Rejection
The summer of 2018 was one of the best times of my life; I got to spend ~3 months in London with some of my best friends. They had gotten summer and full-time offers through GS’s African Recruiting Initiative. However, by the end of summer, I did not have a return offer to GS.
After some deep reflection, I realized that I was honestly half expecting it. I made 4 mistakes during the internship.
I tried to learn too much
My project was to write a complex-ish Go script to automate metrics generation from Kubernetes cluster audit logs. I needed to populate a dashboard with these metrics using a lib; I needed to use Kafka to enable async operations; I needed to store all the information in the firm’s data lake in a queryable format.
However, I got fascinated by Virtualization, Containers, Docker, and the internals of Kubernetes. Once something sparks my curiosity like that, I usually go deep. As you can imagine, this isn’t ideal for a short internship. I ended up spending weeks learning unnecessary things which eventually delayed my implementation. I completed maybe 85% of the project by the end, but I could have gotten to 100% and much earlier too.
The hardest part of the whole project was persisting logs in the data lake. Data could be in any format, and finding a schema that worked was hard. I didn’t give myself enough time to tackle this problem. Minus this, all I needed was a knowledge of JSON, basic data structures like maps, Kafka, and Go.
I finished the internship understanding things like how Kubernetes tracks and handles container states, but I didn’t complete my project and I didn’t have an offer. Yay, me.
I learned the importance of just-in-time (JIT) learning (read more about it from Arinze’s article); I learned the importance of understanding the problem in front of me and solving that. Curiosity for a nine-to-five is only useful when it aligns with your team’s goals.
I didn’t have enough technical depth
This one was a tough pill to swallow. Particularly, I didn’t have a deep understanding of DSAs. All the different parts of my project required this: parsing the logs, populating the dashboard, and storing the data.
Because I didn’t understand DSAs well enough, a lot of my initial solutions were incredibly inefficient. I had difficult code reviews and eventually needed to take a short course on maps to create something better.
Having a strong DSA foundation would have made a significant difference during my internship. Not only because I’d have completed my project earlier, but also because I’d have been able to write more compassionate code. Yes, I’m cheesy like that. Poor foundations lead to code that is inextensible, hard to read, hard to test, and hard to debug! It will be a terrible experience for whoever visits the code next.
This was the second signal after the BofAML interview experience I described earlier that I had a DSA knowledge gap. I resolved to learn it properly.
I didn’t handle my admin tasks well.
Part of being a summer intern includes things like replying to hundreds of emails, attending conferences, meeting with company management, giving presentations, and so on. I term these “admin tasks”.
I was poor at managing my time around these things. The main problem though was that I didn’t have a process for dealing with them. Some techniques I use to handle these at the moment include: zero-inbox, inbox labels, no-meeting days, and daily calendar slots to attend to urgent ones.
I had multiple presentations, and sometimes I got too technical for non-technical audiences. Sometimes I gave too much of a background story and didn’t get to the point quick enough. Sometimes I wasn’t able to capture the business benefit of what I was working on. Sometimes I just hadn’t practiced beforehand.
The signal was clear though: I needed to improve my presentation skills.
I didn’t feel settled in the team. I should have moved.
I left this one for last because, as a principle, I try to highlight what I could have improved personally first in any situation. This was uncomfortable to admit, but it is true from my perspective nonetheless.
I didn’t feel settled in the team I was assigned to for my 2018 Summer internship. I didn’t feel like that was where I could do my best work. There were some passive-aggressive comments I got sometimes because of mistakes I made which really hurt. I found it hard to ask questions because I felt like some teammates weren’t approachable. But, I didn’t ask to leave the team because I wanted to make it work. I don’t say this as an authority in your life, but in every situation you find yourself, think about if you’re at peace. If you don’t feel peace, that’s your cue. Don’t hesitate 🙂.
Beyond the reflections and lessons, I should say that I’m super grateful for all the friends that interned with me; I found comfort in them! Love you all!
After the internship, I doubled down on HackerRank, GeeksforGeeks (G4G), and Cracking the Coding Interview (CTCI). Before these, I had tried out Codewars. These platforms were the worst ways for me to start to learn, but more on that later. I practiced — struggled really — with these platforms and learned some things the hard way. After some time, I felt a lot more confident in my knowledge of DSAs, so I decided to apply to companies again. Remember what Arthur Ashe said.
Start where you are, use what you have, do what you can
Once again, I heard about opportunities through a conversation. A friend told me about another friend that got an offer from Bloomberg and Palantir. In my head, I was like “Oh, they actively interview and recruit Africans? Bet”. I researched both companies to find out what they did and if I found them interesting. It turns out I did, so I decided to apply to both.
I applied to Palantir first. I found an open role on LinkedIn and sent a cold message to one of the company’s recruiters and got a reply. The point of this was to make sure that someone was going to look at my CV. Shortly after that, I got invited to the first stage of the interview: a 75-min HackerRank coding test. I took it, but I couldn’t solve the problem within the time limit because I felt super nervous. As with most problems I set my mind to, I still made sure to solve the question — and I did it that day. After solving the question, I got an interesting idea: send the solution to the recruiter as a show of tenacity. This leap of faith got me a call to the next round — a phone interview!
However, boldness is not an alternative to preparedness, so, I failed the phone interview. I remember making sure to ask for feedback after I got the rejection email and I haven’t forgotten what the recruiter told me: “You were able to come up with efficient approaches, but you were too hesitant to code it up”. I took this. This was progress from my BofAML interview.
I applied to Bloomberg next. I followed the same process. I reached out to a recruiter to ensure that my application will get looked at. I submitted my application and got invited for a phone interview. The question I was asked during the interview involved using a stack on a string, but I hadn’t studied stacks or string traversals, so I failed this interview as well.
These experiences were my second and third set of technical interviews — after the one I had with TeamApt in 2017. They were important to show me how much I had improved: I could now explain for loops (LOL) and I was able to solve the difficult Palantir coding test. They were important to show me what I needed to improve: I still needed more knowledge on DSAs. I didn’t know about Stacks, for example. I also needed to improve my interviewing skills in general. They were important to show me what I needed to continue doing: studying, interviewing, and asking for feedback.
For now, though, the 2018 recruitment cycle had ended and I needed a job in Nigeria. So, I applied and got into TeamApt.
🧘🏾 Take a breather, if you need one!
Working on Foundational Problems
PS: While I worked in companies before and after TeamApt, I’ll focus on just them in this article, as they are the most instrumental to this story.
Many people don’t know this, but I got sacked by TeamApt during an internship with them in 2017. I remember feeling devasted by that at first — like, “How can you get sacked during an internship, Ayo? (tears)” — but that has been one of the most important moments in my life.
So, why was I sacked?
At the beginning of 2017, TeamApt, < 2yrs old at the time, was starting to make huge strides. I joined as a Software Engineering intern and my first main task was to write Selenium tests for frontend components.
I had worked in a company before, but it had not been as fast-paced. So when, at TeamApt, I was expected to produce quality work quickly, I was out of place. The tasks weren’t impossible, but they were poised to stretch you. I made the same mistake I would make a year after during my GS Summer internship. Remember it? I got sucked into an endless cycle of unnecessary learning. What this meant was that I wasn’t delivering on tasks or meeting up with deadlines. I was given a grace period after an initial review, and then eventually let go.
I remember the biggest reason for my devastation being that I felt like I wasn’t going to be part of the important mission that TeamApt was executing. I believed in it so much that I convinced a friend to apply even when she had a full-time role somewhere else. She went on to convince another mutual friend to apply and that chain has probably only continued to expand till today.
Back again, but better
If there’s anything you should take from this, it’s that I try to be very self-aware. I think about every damn thing, and it makes me appreciate a lot of experiences, eventually.
I came to appreciate TeamApt for letting me go because self-awareness showed me I lacked the underlying skills they were looking for. Without the sacking, I would probably have wasted my GS Spring internship, and if not that, then my Summer internship in a worse way. Most importantly, without the sacking, I wouldn’t have seen how poorly I performed in a fast-paced environment — and you know everywhere is fast-paced these days!
Fast forward to a year after, I decided to apply to TeamApt again, and I got in! And this time, I was ready to do the best work of my life.
I joined a team building a product called Moneytor, which offered internet banking & merchant management services to Nigerian banks. You can think of the product as a pack of ingredients. For each bank we delivered the product to, we made the meal in a unique way.
The beginning was difficult: I was assigned to a bank early on and I needed to learn Spring to deliver an API for them. Spring is one of those frameworks that doesn’t look approachable — it’s full of annotations and extra detailed error logs — and would require hours and hours of study to become usable. However, I had the lessons from past experiences in hand, so I only learned what I needed to learn when I needed to learn it (+1 JIT learning). By the end of my time there, I had worked with at least 7 banks (working with some more than once), delivering different Moneytor modules to them, and helping their users achieve financial happiness. Before I left, one of my managers said I was like a swiss-knife — a metaphor to show my versatility. I took the compliment!
The Aptian Magic
Asides from my main job, there were many things about the company that contributed to my overall growth
- The company’s fantastic CTO, Felix, along with many other super-smart people, put good engineering practices in place. From the very first day, we practiced things like code reviews, unit and integration testing, CI/CD, and so on.
- We read and reviewed multiple books together as a company including Clean Code, The Pragmatic Programmer, and Computer Science Distilled (my recommendation, obviously). We discussed ideas and used practical examples to explain engineering principles.
- We gave presentations — I gave some — on different topics and tools.
- We had multiple hackathons as well, with winners getting monetary and non-monetary rewards.
I’m sure there are some other things I don’t remember, but it was fun! These activities ensured that a lot of the engineers approached their work from a foundation of quality. TeamApt gave me time and the environment to address the mistakes I made during my GS Summer internship. I had learned how to learn things when I needed them; my client-facing role taught me about empathy; the hard problems and thorough code review process ensured I had technical depth; the talks I gave within and outside the firm improved my presentation skills.
If companies were pots that cooked engineers and products, TeamApt was the perfect cooking pot for me. Shout out to the incredible Aptians keeping the (evolving) mission going!
The Valley of Disappointment
All of this time, I hadn’t forgotten my main goal: japa. So, I kept interviewing while working. Again, I interviewed with multiple companies, but I’ll only focus on the ones important for this story. Also, I only applied to places where I felt I would fit; I needed to like what they did.
In December 2019, a recruiter from Facebook reached out to me regarding a summer internship. I took the first interview and was successful. I remember the question requiring me to use binary search and queues (I think); the feedback for this interview was that they were impressed because I came up with the most optimal solution. The final stage had 2 questions. The first one was trivial; the second one required using recursion, but the interviewer could not understand my solution. This was painful for me, and I took the lesson to go back and learn how to explain recursive solutions better.
I applied for a full-time role with Goldman in September 2019 and as part of submitting the application, I was invited to take a test. I believe there were three questions; I remember reading through them, knowing I could solve them. However, something weird happened. The cue from my brain that I really wanted to get this opportunity suddenly put an incredible amount of pressure on me. This made it hard to think clearly. But that’s not where it ends. Smile — my internet provider — decided to take a holiday. Nervousness and bad internet do not go well together my friend. So, I couldn’t finish this test during the time limit and I got an automated rejection 🙂. I, and I hope you expect this by now, made sure to solve the questions afterward — I even timed myself!
The experience taught me something important: desires can become unhealthy in desperation. My desire for the job made me so nervous that I couldn’t take steps to achieve it. But what really is this? It’s a fear of getting a rejection. The reason I was so nervous was that I wanted the job, and I didn’t want to get a rejection. It was important to identify this and then discard it. In life, you either get something or you don’t. I make sure to never lose sight of this. My approach is captured perfectly in this quote I saw somewhere:
Work for the best outcome, but make peace with the worst outcome
In February 2020, Goldman came to Lagos to recruit summer interns as part of their ARI program. I applied to the program and got in. Getting into the program just means that you have the opportunity to be interviewed for the role, it doesn’t mean you have the job.
Part of the program’s interview process involved designing a hypothetical system that solved a problem and making a presentation to defend the design. I really love architecting systems, so this was fun. And my team won! I even got special commendation because of how well I answered questions during my team’s presentation.
However, I couldn’t proceed to the final stage and you wouldn’t believe why! (tears) Remember the coding test I failed in September 2019? It still counted as part of the current “cycle”. This meant I couldn’t take another test and for all intents and purposes, I had “failed” the coding test again. The village witches were trying, lmao, but God tries harder. My main joy for this particular process was that 3 out of 5 people in my team got the internship and eventually, full-time roles.
2019 was a really strange year for my Bloomberg applications. I applied for a full-time role and botched the interviews. I think I made it to the second stage, I don’t remember much about it. But after botching the full-time interviews, I decided to apply for an internship with them.
I was planning to go for my Master’s as well, so an internship would also have made sense for me.
During the internship interview process, I did so well that the recruiter asked me to move to the full-time track. So, here I was again, taking interviews for a full-time role with them. I kept progressing through their stages and eventually traveled to London in February 2020 for their onsite round. This was the farthest I had ever gotten for Bloomberg.
If I wasn’t here to clarify, you’d think the Bloomberg and Palantir scripts had the same director!
I also initially applied for a full-time role with Palantir in 2019. I failed the initial coding test — it was the hardest question I had ever seen (tears). I think it took me like a week to solve the question eventually, but the satisfaction I got was worth it.
After failing the coding test, I decided to apply for an internship with them — as I did with Bloomberg, and for the same reason. I also did really well in the interviews and a recruiter also asked me to switch to the full-time track — as it happened with Bloomberg! I progressed all the way to the on-site as well.
The on-sites for Bloomberg and Palantir were only days apart, so I only had to travel once for both. I was quite excited about that trip because things seemed like they fell perfectly into place. I had been switched from the internship track to the full-time track for both companies; I was the best version of my interviewing self. Surely, I’d finish the trip with at least one offer?
The story ends sadly though: I failed both on-sites. My feedback for Bloomberg was that I didn’t handle edge cases well enough. My feedback for Palantir was that I didn’t take enough initiative during one of the interviews. I was so disappointed that I had to take a month off everything related to coding — I still had to work though, but I basically zombied through.
All these disappointments were hard experiences for me and I always made sure to take the lessons to improve myself. Something interesting happened during my month off though: I came to appreciate how much I had grown. Remember that boy who couldn’t explain for loops because the interviewer knew some synonyms? He was getting on-sites now. He knew his data structures now. His professional contributions had impacted thousands (and possibly millions of users). There was growth. So I learned one more lesson: it is important to slow down to reflect. There are things you only see when you slow down.
Preparing for Interviews the Right Way
I said earlier that starting with Hackkerank, G4G, CTCI, and Codewars was the worst way for me to start to learn. The reason for this was because I didn’t quite understand data structures properly when I was starting out, so I should have dedicated time to that.
I think initially my plan was to learn the data structures I needed as I solved more questions. This works, for more advanced structures, but not understanding the basic ones means that there’s a limitation to the type of solutions one can conceive. If I don’t know about HashMaps, I cannot know when a HashMap will be useful; but if I know about Trees, I can conceive a Trie or a BST by some trial and error.
So, my biggest breakthrough came when I read Computer Science Distilled (Thanks, Naij Education 🙄). It is basically an “Explain It Like I’m 5” storybook for Computer Science. I learned the basic data structures in plain English and it helped me create a mental model that mapped these structures to real-world applications. Understanding their implementations was a breeze after that and solving questions from Hackkerank, G4G, CTCI and Leetcode were much easier after that.
For posterity, I even created a repo to explain and implement data structures in as many languages as possible. If you’re interested in contributing a new language implementation for an existing structure or you’re interested in adding a new structure entirely, please create a PR. I have a few PRs pending, but I promise to get to them soon.
Overall, understanding fundamentals (along with my past experiences, of course) helped me break through something James Clear called “The Plateau of Latent Potential” in Atomic Habits — it’s a point that must be crossed to allow meaningful change to shine through.
In all the time I spent preparing for, having, and failing interviews, I made sure to continue to pursue my curiosity in different ways. This included building personal projects (like the recruitment platform I built for a non-profit org with a team); reading articles and books to learn and understand things; taking technical courses or watching random youtube videos.
In my pursuit, I’ve learned a few things:
- There are many things to learn and understand; focus on one at a time.
- When you are genuinely interested in something, then researching about it doesn’t feel like work, it feels like play.
- Don’t compare yourself to others. It’s okay to admire, but don’t envy. Envy will skew your growth because you’d try to be someone else.
- Curiosity is a gift, so nurture it. Create processes to pursue it. Refine the processes as you go along.
- You don’t understand something if you can’t explain it. “Explain it like I’m 5” should be a guiding principle.
Resilient, Spaced Practice
At different time periods, I would solve 2 questions in the morning before work starts and 2 questions after work was done. This was impossible for me to sustain for years because at different points I had other priorities or I just wanted to chill. So what I did was to have short periods of time that I set out to achieve a goal. For example, I could solve questions every day for a month and then take a break for another month and repeat. Sometimes it was 2 months. What’s important is that I was consistent with setting (and achieving) goals bounded by those time periods.
I found that spaced practice like this gave me time to properly digest what I had learned during the last time period. I would be able to meditate on it and even find a practical application for it in everyday life. Say I learned about graph traversals in the last time period and then I’m on a break now, I could get assigned a task to implement something that requires graph traversals at work, or I could find an article that describes how a company used graph traversals to solve a problem. This happened to me so frequently (you know the law of attraction?), and it was super important in furthering intuitive understanding.
One of my favorite quotes from The Alchemist by Paulo Coelho goes like this: “And when you want something, all the universe conspires in helping you to achieve it.”
So if you decide to do this, make sure to look out for ways you can apply what you learn. If that isn’t easy, look for how someone else has applied it. The world is big enough that an example probably exists and small enough that the internet will help you find it.
At the point in time that this article ends, I had solved ~700–1000 interview-style coding questions.
I’ll just like to acknowledge God, my family, my girlfriend, and my friends. Your kind words, gifts, comforting arms, and boundless love were a source of strength for me.
If you can, go through your journey with your community. You’ll be better for it.
Ok Google, wagwan?
Getting an interview at Google
Before getting an interview at Google, I had submitted at least 10 applications to them at different times. The response was always the same.
I always wanted to join Google, but because of all the unanswered applications, they weren’t a part of my immediate plans. It seemed like I would not get a call back while I was in Nigeria, so I pursued other “feasible” options. But as luck will have it, someone reached out:
You know those emails you can’t quite believe? My Lagosian senses were tingling like, “Which kain format be this now abeg? It looks legit? Is that an ‘o’ in the google domain or is it a ‘0’ ?”. On another day we will discuss traumatic Lagos experiences (tears) but for today, let’s focus. I was finally convinced it was real when I got a calendar invite. I decided that even if it was a scam, I had to at least get on the call with the person. In the worst case, I’d be able to warn others about this new “format”.
Well, it turned out that it was legit. And during the call, I went on to answer 10–15 questions about data structures and JVM — I think I was asked about JVM because my CV implied I knew it. The questions were to test my “interview preparedness” and boy was I ready; I had just finished 2 months of solving interview-style coding questions every day post the month-long break, post the two failed on-sites.
Preparing & Interviewing
I had two interviews after that: a video interview and the virtual on-site. The on-site consisted of 5 interviews: 3 for coding, 1 for systems design, and 1 for Googleyness.
When I was asked to pick a date and time for the video interview, I decided to pick one a month away. I felt ready, but I didn’t want to rush. This felt right, so I wanted to take it slow. The first thing I did was to create a plan for intense practice over the next month.
I didn’t need to study the fundamentals again because I knew them well; what I needed now was to see and solve as many different types of questions as I could. So, I paid for Leetcode premium with a friend and set off. The first interview was a success and by the day of my onsite interviews, I had
- solved 51 out of 85 questions with the Google tag
- done at least 30 mock interview sessions with my friends and on Pramp
- read through almost all the systems design use cases on donne martin’s system design primer repo.
- solved at least one question a day for 3 months
As a side note, I mentioned earlier that I love architecting systems, so I had been implicitly preparing for the system’s design interview by reading blogs and working on projects.
I had my onsite interviews on Aug 27th and heard that I was successful on Sep 9th. That was the shortest feedback timeframe I’d heard of at the time. I told you it felt right!
On the day of the news, I just marveled at the whole thing and thanked God. The japa was actually in hand this time. I made sure to acknowledge all the work that had gone into getting me to that point — early days, late nights, forgone outings, and so on. I wanted to make sure that I acknowledged the hard work because it keeps me humble. It keeps me hungry.
Everything I had done over the past 5 years contributed to this — not one thing or some things…everything. The journey is important friends, and it’s up to you (mostly) how you steer it.
Every time I failed or was disappointed, I got a little sad or very sad (depending on the context), but I always made sure to learn from my mistakes and go again. It’s borne from an understanding that to reach a crescendo we must start the journey upward; every time we fail is an opportunity to aspire to a new crescendo.
One of my closest friends says I obsess over the problems I set my mind to, and I agree — I keep trying (albeit in different, improved ways). For what is success, if not forward failure persevering?
 Grand is to Ireland, what innit is to the UK. How else would you know that I’ve been in Ireland for 2 mins 😂 ?
 “japa” is a Nigerian slang that means “leave the country to work / study abroad”