Careercup Top 150 Questions

Practice Interviews Studying helps, but nothing can prepare you like the real thing. Each CareerCup interviewer has given over a hundred interviews at Google, Microsoft, or Amazon. To nail your interview, sit down with a trained interviewer and get their experienced feedback. One Hour Interview with Real Interviewers Our interviewers will give you a real interview, just like you’d get at Google, Microsoft or Amazon. We’ll test you on the same types of questions that they do. We’ll grade you the same way they do. How can we do this? We’ve done over 100 interviews each for these companies. We’ve screened resumes. We’ve been part of their hiring committees. We know what they want. We’ll Also Give You. Feedback on where you shined and where you struggled. Specific suggestions on how to improve.
Instructions on how to approach tough problems Lessons on what interviewers look for in your code.
A Typical Interview A typical interview includes a brief discussion of your resume and one or more technical questions. Each interview will do coding via a shared document. When the interview is completed, we’ll give you immediate feedback on how you did while it’s still fresh in your mind. Later that day, you’ll receive an mp3 of the interview to refresh your memory. Schedule Your Interview Today!

The Microsoft Interview
Microsoft wants smart people. Geeks. People who are passionate about technology. You probably won’t be tested on the ins and outs of C++ APIs, but you will be expected to write code on the board. In a typical interview, you’ll show up at Microsoft at some time in the morning and fill out initial paper work. You’ll have a short interview with a recruiter where he or she will give you a sample question. Be nice to your recruiters; while they may not evaluate your technical skills in depth, they can fight for you to be hired – or not.
Throughout the day, you’ll move around from interviewer to interviewer, visiting each one in their office. Use this time to look around and get a feel for what the team culture. Interviewers are not allowed to share their feedback on you with other interviewers, due to concerns of bias. Nonetheless, many sources indicate that some feedback is shared. When you complete your interviews with a team, you might speak with a hiring manager. If so, that’s a great sign! It likely means that you passed the interviews with a particular team. It’s now down to the hiring manDefinitely Prepare: ager’s decision.
You might get a decision that day, or it might be a week. After one week of no word from HR, send them a friendly email asking for a status update. “Why do you want to work for Microsoft? ” In this question, Microsoft wants to see that you’re passionate about technology. A great answer might be, “I’ve been using Microsoft software as long as I can remember, and I’m really impressed at how Microsoft creates manages to create a product that is universally excellent. For example, I’ve been using Visual Studio recently to learn game programming, and it’s APIs are excellent. ” Note how this shows a passion for technology!
What’s Unique: You’ll only reach the hiring manager if you’ve done well, but if you do, that’s a great sign! The Amazon Interview Amazon’s recruiting process usually begins with one or two phone screens in which you interview with a specific team. The engineer who interviews you will usually ask you to write simple code and read it aloud on the phone. They will ask a broad set of questions to explore what areas of technology you’re familiar with. Next, you fly to Seattle for four or five interviews with one or two teams which have selected you based on your resume and phone interviews.
You will have to code on a whiteboard, and some interviewers will stress other skills. Interviewers are each assigned a specific area to probe and may seem very different from each other. They can not see other feedback until they have submitted their own and they are discouraged from discussing it until the hiring meeting. Amazon’s “bar raiser” interviewer is charged with keeping the interview bar high. They attend special training and will interview candidates outside their group in order to balance out the group itself.
If one interview seems significantly harder and different, that’s most likely the bar raiser. This person has both significant experience with interviews Definitely Prepare: and veto power in the hiring decision. You Amazon is a web-based company, and will meet with your recruiter at the end of the day. that means that they care about scale. Once your interviewers have entered their feedback, they will meet to discuss it. They will be the people making the hiring decision. While Amazon’s recruiters are excellent at following up with candidates, occasionally there are delays.
If you haven’t heard from Amazon within a week, we recommend a friendly email. Make sure you prepare questions in “Large Scale. ” You don’t need a background in distributed systems to answer these questions. Just answer the question for one system and then think, how does your solution change with multiple computers? Additionally, Amazon tends to ask a lot of questions that are based in mathematics and randomness. What’s Unique: The Bar Raiser, who is brought in from a different team to keep the bar high.
The Google Interview
There are many scary stories floating around about Google interviews, but it’s mostly just that: stories. The interview is not terribly different from Microsoft’s or Amazon’s. However, because Google HR can be a little disorganized, we recommend being proactive in communication. A Google engineer performs the first phone screen, so expect tough technical questions. On your onsite interview, you’ll interview with four to six people, one of whom will be a lunch interviewer. Interviewer feedback is kept confidential from the other interviewers, so you can be assured that you enter each interview with blank slate.
Your lunch interviewer doesn’t submit feedback, so this is a great opportunity to ask honest questions. Written feedback is submitted to a hiring committee of engineers to make a hire/no-hire recommendation. Feedback is typically broken down into four categories (Analytical Ability, Coding, Experience and Communication) and you are given a score from 1. 0 to 4. 0 overall. The hiring committee understands that you can’t be expected to excel in every interview, but if multiple people raise the same red flag (arrogance, poor coding skills, etc), that can disqualify you.
A hiring committee typically wants to see one interviewer who is an “enthusiastic endorser. ” In other words, a packet with scores of 3. 6, 3. 1, 3. 1 and 2. 6 is better than all 3. 1’s. Your phone screen is usually not a factor in the final decision. The Google hiring process can be slow. If you don’t hear back within one week, politely ask your recruiter for an update. A lack of response says nothing about your performance. Definitely Prepare: As a web-based company, Google cares about how to design scalable system. So, make sure you prepare question from “Large Scale. Additionally, many Google interviewers will ask questions involving bit shifting and Bit Manipulation, so please brush up on these questions. What’s Different: Your interviewers do not make the hiring decision. Rather, they enter feedback which is passed to a hiring committee. The hiring committee recommends a decision which can be—though rarely is—rejected by Google executives.
The Yahoo Interview
Resume Selection & Screening: While Yahoo tends to only recruit at the top 10 – 20 schools, other candidates can still get interviewed through
Yahoo’s job board (or – better yet – if they can get an internal referral). If you’re one of the lucky ones selected, your interview process will start off with a phone screen. Your phone screen will be with a senior employee (tech lead, manager, etc). Onsite Interview: You will typically interview with 6 – 7 people on the same team for 45 minutes each. Each interviewer will have an area of focus. For example, one interviewer might focus on databases, while another interviewer might focus on your understanding of computer architecture.
Interviews will often be composed as follows: 5 minutes: General conversation. Tell me about yourself, your projects, etc. 20 minutes: Coding question. For example, implement merge sort. 20 minutes: System design. For example, design a large distributed cache. These questions will often focus on an area from your past experience or on something your interviewer is curDefinitely Prepare: rently working on. Decision: At the end of the day, you will likely meet with a Program Manager or someone else for a general conversation (product demos, concerns about the company, your competing offers, etc).
Meanwhile, your interviewers will discuss your performance and attempt to come to a decision. The hiring manager has the ultimate say and will weigh the positive feedback against the negative. If you have done well, you will often get a decision that day, but this is not always the case. There can be many reasons that you might not be told for several days – for example, the team may feel it needs to interview several other people. Yahoo, almost as a rule, asks questions about system design, so make sure you prepare that. They want to know that you can not only write code, but that you can design software.
Don’t worry if you don’t have a background in this – you can still reason your way through it! What’s Unique: Your phone interview will likely be performed by someone with more influence, such as a hiring manager. Yahoo is also unusual in that it often gives a decision (if you’re hired) on the same day. Your interviewers will discuss your performance while you meet with a final interviewer.
Interview War Stories
The View from the Other Side of the Front, by Peter Bailey
For the eager candidate getting ready for a big job interview, Cracking the Technical Interview is an invaluable reference, containing excellent coaching and practice material that gives you an inside edge on the interview process. However, as you go over your old data structures textbook and drill yourself with homemade discrete math flash cards, don’t make the mistake of thinking of the interview as a kind of high-pressure game show – that if you just give all the right answers to the tech questions, you too can win a shiny new career (this week, on Who Wants to be a Software Engineer? While the technical questions on computer science obviously are very important, the most important interview question is not covered in this guidebook. In fact, it’s often the single most important question in your interviewers’ minds as they grill you in that little room. Despite the questions on polymorphism and heaps and virtual machines, the question they really want an answer to is … Would I have a beer with this guy? Don’t look at me like that, I’m serious! Well, I may be embellishing a little, but hear me out.
The point I’m trying to make is that interviewers, especially those that you might work with, are probably just as anxious as you are. Nonsense, you say, as a nervous young professional, checking your pants for lint while you bite your fingernails, waiting for the interview team to show up in the front lobby. After all, this is the big leagues, and these guys are just waiting for you to slip up so they can rip you apart, laugh at your shriveled corpse, and grind your career dreams to dust beneath the heels of their boots. Right? Just like pledge week, back in freshman year?
Right? Hmmm? Nothing could be further from the truth. The team of developers and managers interviewing you have their own tasks and projects waiting for them, back at their own desks. Believe me, they’re hoping that every interview is going to be the last one. They’d rather be doing anything else. There might be a batch of upcoming projects looming on their calendar, and they need more manpower if they’re going to even have a prayer of making their deadline. But the last guy the agency sent over was a complete flake who railed about Microsoft’s evil for half an hour.
And the one before that couldn’t code his way out of a wet paper bag without using copy-and-paste. Sheesh, they think, where is HR getting these guys? How hard can it be to hire one lousy person? While they may not literally be asking themselves “Would I have a beer with this guy (or gal)”, they are looking to see how well you would fit in with the team, and how you would affect team chemistry. If they hire you, you’re all going to be spending a lot of time together for 11
Interview War Stories he next few months or years, and they want to know that they can rely on you – and maybe even come to consider you a friend and colleague. They want to know that they can depend on you. And as tempting as it might be to them to just settle and hire the next person who comes along, they know better. In many companies, particularly large U. S. companies, it’s harder to fire somebody than it is to hire somebody. (Welcome to the US: Land of Lawsuits! ) If they hire a dud, they’re stuck with them. That person might be unproductive or, even worse, a drain on the team’s productivity.
So they keep interviewing, until they find the right person. They know that it’s better to reject a good candidate than hire a bad one. Some of those interviews are real doozies. Once you’ve interviewed long enough, you build up a repertoire of horror stories. War stories, of candidates who looked promising on paper until the interviews went terribly, terribly wrong. These war stories are not only humorous – they’re also instructive. Names have been changed to protect the innocent – or downright ridiculous.
Interview War Stories
Pop Divas Need Not Apply Leonard was a very promising C++ coder, three years out of college, with a solid work history and an impressive skill set. He proved on the phone screen that he was above-average technically, and so he was invited in for an interview. We needed a savvy C++ person to work on a piece of middleware that interfaced with our database, and Leonard seemed like a sure fit.
However, once we started talking to him, things went south in a hurry. He spent most of the interview criticizing every tool and platform that we questioned him on. We used SQL Server as our database? Puhleease. We were planning to switch to Oracle soon, right? What’s that? Our team used Tool A to do all our coding in? Unacceptable. He used Tool B, and only Tool B, and after he was hired, we’d all have to switch to Tool B. And we’d have to switch to Java, because he really wanted to work with Java, despite the fact that 75 percent of the codebase would have to be rewritten.
We’d thank him later. And oh, by the way, he wouldn’t be making any meetings before ten o’clock. Needless to say, we encouraged Leonard to seek opportunities elsewhere. It wasn’t that his ideas were bad – in fact, he was “technically” right about many things, and his (strong) opinions were all backed with solid fact and sound reason (except for the ten o’clock thing – we think he may have just been making a “power play”. ) But it was obvious that, if hired, Leonard wasn’t going to play well with others – he would have been toxic kryptonite for team chemistry.
He actually managed to offend two of the team members during the forty-five minutes of his interview. Leonard also made the mistake of assuming that Code Purity and Algorithm Beauty were always more important than a business deadline. In the real world, there are always compromises to be made, and knowing how to work with the business analysts is just as important as knowing how to refactor a blob of code. If Leonard would not have gotten along with other IT people, he definitely wouldn’t have gotten along with the business folks. Maybe you can get away ith hiring a Leonard if he’s one of the best ten coders in the world (he wasn’t). But he was the classic failure example for the “Would you have a beer with this guy? ”
Stories What We Have Here is Failure to Communicate Trisha was a mid-level Java developer with a solid history of middleware and JSP work on her resume. Since she was local, we invited her in for an interview without a phone screen. When we started asking her questions, it quickly became obvious that Trisha was a woman of few words.
Her answers were short and often composed of “yes/no” responses, even to questions that were meant to start a dialog. Once she did start opening up, I still wasn’t sure she was actually talking. I saw her lips moving, and heard mumbling sounds coming out, but it wasn’t anything that sounded like English. I’m not sure if Trisha was nervous or just shy, but either way, I had to ask her numerous times to repeat herself. Now I was the one getting nervous! I didn’t want to be the guy who “ruined” the interview, so I pulled back on my questions. The other folks in the room and I exchanged uneasy glances.
We felt like we were on a Seinfeld episode. It was almost impossible to understand Trisha, and when she did speak up, her halting, uncertain, confused speech patterns made us feel more like code breakers than interviewers. I am not exaggerating to say that I did not understand a single answer she gave during the interview. Knowing, alone, isn’t good enough. You’re going to be talking with other technical people, and you’re going to be talking to customers, and sales reps, and Betty from Marketing. You will write something eventually, whether it’s documentation, or a project plan, or a requirements document.
The word processor might correct your spelling, but it won’t correct your lousy writing. The ability to communicate thoughts and ideas, in a clear, concise manner, is an absolutely invaluable skill that employers seek. The same goes for verbal communication. I used to work with a co-worker who doubled the length of every meeting he was in, because he could not answer a question in less than ten minutes. “Hey, Dennis, what time is it? ” “Well, that’s kind of interesting, because I just happened to be reading an article on cesium clocks and leap seconds and the history of the Gregorian Calendar and … I’ll spare you the rest.
The crest of the dot-com bubble, and the tightest labor market in history. Our company was racing to expand its development team, and we would have hired a German Shepherd if it knew HTML. Instead, we wound up hiring Ian. We should’ve hired the dog. Ian was a cheerful, friendly guy who had a gift of natural charisma. He got along fantastically with all of the interviewers, and seemed very intelligent.
Skillwise, he was adequate. He hadn’t written a single line of computer code outside of his college courses, and didn’t even have his own e-mail address. When we gave Ian the chance to ask us questions at the end of the interview, he asked about flexible work hours, and how soon he could take vacation time. Instead of showing an interest in the career opportunities, or in company’s growth prospects, he asked whether he could take the all-you-could-drink break room soda home with him. The questions grew more bizarre from there. Ian was very interested in our Legal Assistance benefit.
He wanted to know if it covered the cost of filing lawsuits, if it covered him if he got sued himself, if it applied to any lawsuits he currently was involved in, and if he could “theoretically” use it to sue the company itself. He also asked us if he could use it to help him “fix” some unpaid speeding tickets. In any other year, that should have been it for Ian right there. But, in 1999, we were hiring anybody who was even remotely competent. Ian collected paychecks from us for eighteen months, and he was about as productive as a traffic cone.
He usually sauntered into the office around ten-thirty with some sort of lame excuse (by my count, he had to wait for the cable guy sixteen times in a six-month period). He usually killed the morning by answering e-mail and playing ping-pong, before breaking for a two-hour lunch. After lunch, it was more pingpong, and maybe an hour of writing bad code, before bolting the office sometime around three. He was the dictionary definition of unreliable. Remember, your potential future team members need to know that they can rely on you. And they need to know that you won’t need constant supervision and hand-holding.
They need to know that you’re able to figure things out on your own. One of the most important messages that you, as a candidate, can convey in your interview is hiring me will make your lives easier. In fact, this is a large part of the reason for the famously difficult interview questions at places like Amazon and Google; if you can handle that kind of unpredictable pressure in an interview, then you stand a good chance of being useful to them on real projects. To cite a more subtle example, once I was on a four person team that was desperately trying to recruit new members to help work on an old pile of software.
It was a real mess; we’d inherited a nasty ball of spaghetti, and we needed people who could jump in, figure things out, and be part of the solution. There was one very smart fellow, Terry, who would have been a great asset for our team – but we didn’t hire him, despite his excellent technical and personal skills. It was because he insisted on meticulous written instructions for every step of the coding process.
He wasn’t going to make a suggestion or take any initiative – or blow his nose, for that matter – without a mile-long audit trail and a dozen signatures. While he insisted that he worked that way for reasons of quality (a defensible point), we got the impression that it had more to do with butt-covering, and we simply didn’t have the time for that kind of bureaucracy. Terry would have been an excellent fit in a government or aerospace IT department, something that required ISO 9000 procedures. But he would have never fit into our team; he would have been a burden, not an asset.
 My Spider Senses are Tingling I can think of lots of interviews that just fell into the general category of weird and uncomfortable: » » » » » » The Java coder who apparently considered hygiene optional, and had the interview room smelling like week-old blue cheese within ten minutes (my eyes were watering). The young fresh-out-of-college graduate with a tongue piercing that kept tick-tick-ticking against his teeth as he talked (after half an hour, it was like Chinese water torture).
The girl who wore an iPod through her interview, with the volume turned loud enough that she actually had to ask the interviewers to repeat themselves a few times. The poor, hyper-nervous fellow who was sweating like a marathon runner for half an hour. The girl who wore a T-shirt with an obscene political slogan to her interview. The guy who asked (seriously) at the end of his interview, “So, are there any hot chicks in our department? ” Those are the interviews where we politely thank the people for their time, shake their hand (except for the sweaty guy), then turn to each other after the door closes and ask – did that really just happen?
Nobody is saying that you have to be a bland, boring robot in a Brooks Brothers suit and tie. Remember, the interview team wants you to be “the one”, but they’re also very worried about the possibility that you’re going to be more of a distraction than an asset. Don’t talk or behave in a way that will set off their early warning radar. Whether or not somebody bothers to behave professionally during an interview is often a very good indicator of what kind of teammate they’re going to be. Rudimentary social skills are part of the answer to “Would I have a beer with this guy? , or at least, “Will I mind working next to this guy for six months? ” From the interviewer’s point of view, they’re picking a neighbor that they’re going to live and work with 200 hours per week for foreseeable future. Would you really want a neighbor that smelled like a hog rendering plant? Interview Questions Study hard, practice and good luck! How this Book is Organized The interview questions in this book are grouped into categories, with a page preceding each category offering advice and other information.
Within each category, the questions are sorted by approximate level of difficulty. Solutions for all questions are at the back. How to Use this Book An effective interview is not about memorizing interview questions, but rather, about applying an understanding of concepts and demonstrating your problem solving ability. Use these questions to find the gaps in your knowledge and to learn problem solving techniques that you can apply to new questions. Advice for Devs Your interview will be most likely not be conducted on a computer. Thus, when you practice the problems in this book, we recommend writing them down on paper first.
Then, type your solution into the computer exactly as you wrote it and see how you did. Special Advice for SDETs Not only do SDETs have to be great testers, but they also have to be great coders. Thus, we recommend that you complete the coding problems in this book with an eye for testing them. Even when the question doesn’t specifically ask it, you should ask yourself, “how would I test this? ” Remember: any problem can be an SDET problem. Suggestions and Corrections While we do our best to ensure that all the solutions are correct, mistakes will be made. Moreover, sometimes there is no “right” answer.
Many of the so-called “Applied Mathematics” problems read as brain teasers at first, but can be worked through in a logical way. Just remember to rely on the rules of mathematics to develop an approach, and then to carefully translate that idea into code. Example: Given two numbers m and n, write a method to return the first number r that is divisible by both (e. g. , the least common multiple).
The Approach: What does it mean for r to be divisible by m and n? It means that all the primes in m must go into r, and all primes in n must be in r. What if m and n have primes in common? For example, if m is divisible by 3^5 and n is divisible by 3^7, what does this mean about r? It means r must be divisible by 3^7. The Rule: For each prime p such that p^a m (e. g. , m is divisible by p^a) and p^b n, r must be divisible by p^max(a, b) The Algorithm: Define q to be 1. for each prime number p less than m and n: find the largest a and b such that p^a m and p^b n let q = q * p^max(a, b) return q
Hash tables are frequently, though not always, implemented with an array. A simple implementation of a hash table that hashes a string to a Person is as follows: class HashTable { Person[] data = new Person[MAX_HASH_KEY]; int getId(string s) { /* return a key for this string */ }; bool contains(string key) { int id = getId(key); if (data247) return true; return false; } void insert(string s, Person p) { data[getId(s)]; } Note: This implementation does not handle collision. Collisions can be handled by “chaining” (eg, using a linked list), or a variety of other ways. Vector (Dynamically Resizing Array):
If you’re stuck, we recommend simplifying the problem. Solve it for a small number of items or a special case, and then see if you can generalize it. Example: You are trying to cook an egg for exactly 15 minutes, but instead of a timer, you are given two ropes which burn for exactly 1 hour each. The ropes, however, are of uneven densities – eg, half the rope length-wise might take only 2 minutes to burn. The approach: 1. 2. 3. 4. 5. 6. 7. What is important? Numbers usually have a meaning behind them. The fifteen minutes and two ropes were picked for a reason. Simplify!
You can easily time one hour (burn just one rope). Now, can you time 30 minutes? That’s half the time it takes to burn one rope. Can you burn the rope twice as fast? Yes! (Light the rope at both ends. ) You’ve now learned: (1) You can time 30 minutes. (2) You can burn a rope that takes X minutes in just X/2 minutes by lighting both ends. Work backwards: if you had a rope of burn-length 30 minutes, that would let you time 15 minutes. Can you remove 30 minutes of burn-time from a rope? You can remove 30 min of burn-time from Rope #2 by lighting Rope #1 at both ends and Rope #2 at one end.
While some problems in this chapter are simply coding problems, understanding the mathematical solution will help you “sanity check” your solution. For example, if you know how many subsets there are of a set, you can check to make sure that your algorithm to print all subsets will give you the correct number of subsets. When computing the number of ways of doing something, think about doing it step by step. The following two examples will illustrate this technique.
How many ways can you pick k elements from n elements, if order matters and elements are not replaced? Eg – if we pick 5 different letters, “abcde” is considered to be different from “edcba”. The Approach: We have n choices for the first draw. For the second draw, we only have n-1 since one is removed. Then n-2, …. When we draw k times, we get down to n-k+1 choices on the last draw. So, n * (n-1) * (n-2)*… * (n-k+1) The Solution: n! / (n-k)! How many ways can you pick k elements from n elements, if order does not matter and elements are not replaced? We’re now just throwing letters into a bucket. Picking “a, b” is the same thing as “b, a”.
The Approach: If you compare this problem to the previous one, we’ve essentially double (or triple, quadruple, etc) counted items. That is, “abc”, “acb”, “bac”, “bca”, “cab”, “cba” were all considered unique in the previous solution but now they’re considered the same. Just how many times has “abc” been included (in its other forms)? 3! times, since there are 3! ways of rearranging “abc”. In fact, every item has been included 3! times, when it should have been included just once! So, we divide our previous answer by 3! (or, more generally, k! ). We now get n! / (k! * (n-k)! ).  You could be asked about databases in a variety of ways: write a SQL query, design a database to hold certain data, or to design a large database. We’ll go through the latter two types here. Small Database Design Imagine you are asked to design a system to represent a school’s registrar: course information, departments, course enrollment, teachers, etc. What are the key objects? Student. Professor. Course. Department. How do they relate to each other? *NOTE: I’m going to make some assumptions here for the purposes of writing up this explanation.
In your interview, don’t make assumptions! Ask your interviewer instead. Many-to-Many: » A course can belong to multiple departments, and each department can have multiple courses. So, create a separate table DepartmentCourse that acts as a “pairing” of the two. DepartmentCourse has just a department_id field and a course_id field. A student can be in multiple courses, a course can have multiple students. So, do the same as above and create a StudentCourse table. A course only has one professor. A professor can teach multiple courses. So, add a field professor_id to the Courses table. » One-to-Many: »
Large Database Design When designing a large, scalable database, joins (which are required in the above examples), are generally very slow. Thus, you must denormalize your data. Think carefully about what when data will be used—you’ll probably need to duplicate it in multiple tables.
Define Data Structures When implementing something so free form, ask yourself, “Where can I define a class or a struct? ” When in doubt, define a new class or struct. It tells the interviewer that you care about the maintainability of your code. Validate Your Assumptions Be careful about making assumptions. Suppose you’re asked to implement the word game Scrabble. Don’t assume that the dictionary will be in English—or even in that character set. It could be in any language! Ask your interviewer lots and lots of questions so that you know what to implement. Are you solving this problem once, or many times?
Sometimes the solution will change depending on whether or not your code will be called multiple times. For example, suppose you’re asked to find all anagrams of a word. If you’re calling this code just once, it may be fastest just to rearrange the letters and check if they’re in the dictionary. But, if you’re going to call the code multiple times, it’s now fastest to precompute data by iterating through all the words in the dictionary. Can you generalize your code, or part of it? If you really want to go above and beyond, try writing your code as though it were a more generalized case.