1550117053
How do I prepare for interviewing with Google, Facebook, or Amazon while having a full time job as a software engineer?
#interview-questions #interview
What is GEEK
Buddha Community
1550117332
I’ve rarely heard of anyone quitting a job before they had another job offer already lined up. Any time you see a coworker sending out a “Farewell!” email to the entire engineering organization, the first question you ask them is: “So where are you going now?”.
I’ve switched jobs twice so far—and both times I’ve prepared for the technical interviews while working full-time. I’m guessing from your question that you’ve already discovered that it’s very difficult to continue outputting what you usually do at work, while studying up for the technical interviews.
As someone who completed going through the entire interview cycle with six companies less than half a year ago (Google, Facebook, Apple, LinkedIn, Uber, AirBnB), I can let you know what I did to prepare and how I paced myself to prepare in time for interviews.
First, in order for you to be able to prepare, you have to know what to prepare for. Every interview I’ve ever gone through in my eight years of industry experience have been…pretty much the same. I completed a cycle of interviews in 2009 (when I graduated from undergrad), in 2012 (when I switched companies to join Box), and in 2017 (when I ended up joining Google). Supposedly at some point, I’ll start getting different interview questions because I’ll have enough years of experience, or be “senior” enough (I was a “Staff” level engineer at Box, which is the one above “Senior”) to merit non-whiteboard-coding interview questions. But I haven’t reached that yet.
Anyhow, if you’re in the similar position as me, you’ll get the following breakdown of interview questions (for the onsite):
- 3–5 algorithms questions (e.g.: find the maximum sum of any k contiguous elements of an array, write a function to serialize and deserialize an imbalanced binary tree, find the minimum distance to get from point a to point b in a directed graph)
- 1–2 design questions (e.g.: design Facebook newsfeed, design a url shortener, design Google docs)
- 0–1 other programming questions (e.g.: implement a circular buffer with raw only arrays)
- 0–2 cultural/personality questions (e.g.: talk about a time you resolved a disagreement at work, what are you looking for in your new job?)
All six companies I interviewed with adhered to this format (as of 2017), and that preparing for one company is as good as preparing for all of them — because their interviews are essentially the same.
If your time is limited (whose isn’t?), I would focus almost all of your energy on mastering the algorithms questions. Not only because they are the largest segment of your interviews, but also because it’s the only skill that you almost never use in your regular job (probably) and consequently will be the last prepared for.
I design systems all the time at work. I think hard about what type of data structures to use, and how to tweak existing ones to be optimized for a particular implementation and usage. I also deal with personal conflicts all the time, and have a huge bank of stories to tell regarding work-drama and conflict resolution. What I NEVER do, is solve how to find the largest palindromic substring in O(n^2) time and O(n) space. I imagine most software engineers don’t.
I could dedicate a whole blog post talking about how ridiculous it is that in 2017 we are still giving engineers (who have several years of industry experience) white-boarding algorithms questions and using that as the primary indicator of technical talent. This particular topic has been ranted over several times already on the internet, so I’ll spare you from another rendition of it.
But if you’ve set your heart on joining one of the top-tier tech companies, and have succumbed to being ok with winning inside the system rather than protesting against it, then you’re in luck.
The exact thing that you will do on the day of your actual interview is 100% repeatable, and practicable in your own home, on your own time. The resources and practice problems available for you to perfect your technical interviewing skills is vast and mostly free—and they very much accurately reflect the questions that get asked in real interviews. I’ve done phone screens and on-sites with six companies, which amounts to something like 30 technical interviews (each about 45 minutes a piece); I can attest to the fact that the practice problems you’ll find on the internet will prepare you for the interviews well. I firmly believe that anyone who is already proficient at coding can pass the technical interview gauntlet at any top tech company given that they prepare for it. You just need to suck it up and practice.
Your preparation for ALL of the algorithms questions can be covered by LeetCode.com. LeetCode really is, your one-stop shop to preparing for the algorithms questions. I solved the first 175 LeetCode questions to prepare for my interviews — and I did very well on the interviews. You won’t need to solve as many as I did— I was over-prepared if anything. If you complete 100, you’ll be very solid. Don’t skip the ‘hard’ ones to only do the ‘easy’ and ‘mediums’. Do them all.
I highly recommend investing in a whiteboard. Coding on a whiteboard is nothing like coding on a text editor. Rectifying a mistake, or changing your mind on the approach of your solution, on a text editor is completely fine; doing the same on a whiteboard is completely unforgiving. You should get used to coming up with short, but somewhat descriptive, variable names (writing long words over and over on a whiteboard is not only tiring/slow, but also makes you run out of space real fast). Get used to your shoulder/arm being tired for holding it up for so long while writing on a whiteboard. Gain good judgment on how much space/room you need to implement some functionality; sometimes you want to jump around implementing different parts at different times, and having the spacing correct can be really clutch here.
When I was preparing, I’d read the question off of LeetCode and I’d try to implement it on a whiteboard. When I’d convince myself that I had a working solution on the whiteboard, I’d copy my solution into LeetCode’s text editor and submitted the solution to see if I passed all of their crazy performance requirements. If I only passed the correctness tests, but not the performance tests, I’d rethink my approach and start the question from scratch on the whiteboard. And then repeat, until all of my LeetCode tests passed.
During my more intense weeks, my preparation schedule looked something like this:
- 3–5 algorithms questions (e.g.: find the maximum sum of any k contiguous elements of an array, write a function to serialize and deserialize an imbalanced binary tree, find the minimum distance to get from point a to point b in a directed graph)
- 1–2 design questions (e.g.: design Facebook newsfeed, design a url shortener, design Google docs)
- 0–1 other programming questions (e.g.: implement a circular buffer with raw only arrays)
- 0–2 cultural/personality questions (e.g.: talk about a time you resolved a disagreement at work, what are you looking for in your new job?)
I started preparing for interviews about a month before my technical phone screens. I scheduled all six of my onsites about a month after my phone screens. It was a tough two months, but it left me super prepared.
1550119135
It’s hard to answer this question without having a baseline of information first. I suppose the first questions you need to ask yourself are:
- How much time can you realistically put into studying?
- When do you want to interview with these companies? Do you have a timeline?
- How strong is your background in these concepts? Were your undergraduate and Masters programs focused on these particular areas?
- Have you had the chance to study previously released interview questions from these companies? How did you do?
- Have you pinpointed which areas you need help in?
- Do you get opportunities to use any of those higher-level concepts on a regular basis in your job? If so, how is your implementation?
There are several free courses out there to help you brush up on algorithms (Stanford @ Coursera is a popular one) but it really comes down to how well you can answer the questions posited above. Once you can evaluate yourself and your skills accurately, set aside a certain amount of time per day, just like any other test you have prepped for before (because it is after all a test!) and create a schedule to help you build up to interview dates and times. Find your strengths and weaknesses - evaluate your progress by setting aside a number of the many available questions out there and only testing yourself on them on certain dates.
As you get closer to the date, have your friends or coworkers test you on the primary concepts. Run through mock interviews if you can - try to find engineers who have worked for those companies and arrange paid Skype interviews (you can find many of those people on here!). Talk as much as you can to ex- or current employees at the companies you are targeting.
I know that this wasn’t the most helpful answer in directly answering your question, but I’m afraid that there really isn’t a generic (yet widely applicable), ‘one-size-fits-all’ answer to this particular question. It’s a variable question with variable answers, depending almost entirely on the things I mentioned above.
Good luck though - I hope this helps!
1598383290
What Are Google Compute Engine ? - Explained
What Are Google Compute Engine ? - Explained
The Google computer engine exchanges a large number of scalable virtual machines to serve as clusters used for that purpose. GCE can be managed through a RESTful API, command line interface, or web console. The computing engine is serviced for a minimum of 10-minutes per use. There is no up or front fee or time commitment. GCE competes with Amazon’s Elastic Compute Cloud (EC2) and Microsoft Azure.
https://www.mrdeluofficial.com/2020/08/what-are-google-compute-engine-explained.html
#google compute engine #google compute engine tutorial #google app engine #google cloud console #google cloud storage #google compute engine documentation
1550117053
How do I prepare for interviewing with Google, Facebook, or Amazon while having a full time job as a software engineer?
#interview-questions #interview
1598751120
Software Developer vs Software Engineer — Differences: Bogus or Real?
Software Developers vs Software Engineers
Personally, it pisses me off. Every time I see an article on this topic, my emotional bank account gets robbed. They are all about SEO. Inappropriate keywords squeezed into tiny sentences just to get better rankings. No intent to entertain or enlighten the reader whatsoever. Sometimes, such articles can even be outright wrong.
And even though the purpose of this blog post can be to generate traffic, I tried to make it more of a meaningful rant than a lifeless academic essay.
So, let’s see how you feel by the time you are done reading this paper.
Without further ado:
Since there are no proper interpretations of both terms, a lot of people use them interchangeably.
However, some companies consider these terms as job titles.
The general “programmer-developer-engineer” trend goes along the lines of:
- A programmer is someone who knows how to code, understands algorithms and can follow instructions. Yet, it doesn’t go further in regards to responsibilities.
- A developer is someone superior to the programmer. Except for coding, they also do design, architecture, and technical documentation of the software component they are building. They might be referred to as leaders, but not necessarily.
- Finally, an engineer implies that you are the real deal. You’ve graduated with a degree, have some tech knowledge, and preferably experience… and you are capable of designing a software system (a combination of software components your peons, the programmers, have built). You’re like an overseer. You can see the bigger picture. And it’s your responsibility to clearly explain that “picture” to your team.
#devops #software development #programming #software engineering #software developer #programmer #software engineer #software engineering career
1603904400
How to Prepare for a Coding Interview in 8 Weeks
As of this writing, the market is tough. We’ve been hit hard with a deadly
pandemic that left thousands of people unemployed. It’s layoffs everywhere and the companies are being conservative when it comes to
hiring.
Companies are not willing to hire people with no experience or people who they’ve to train.
Your first job in tech is the toughest, you’re competing
with virtually every new college grad and anyone who completed a boot
camp. I know it can be hard to even land an interview, for someone to
give you a chance to talk and demonstrate you could be valuable
employee.
Now, the chance of you getting an interview totally depends on how your resume compares to the job description. The more relevant it is to the
skills required, the better your chances of getting an interview.
To build your resume, I’d recommend https://thetechresume.com. It’s a nice read to follow the principles when it comes to building a tech resume.
Over the past few months, I’ve been collecting resources like videos,
websites, and taking notes to prepare for coding interviews.
In that process, I made an 8 weeks study guide curated of important data
structure resources to prepare for tech interviews and honestly this
study guide was helpful to me to know what to study every day and in
following a routine for my job search.
Why 8 weeks?
If you’re serious about preparing for a tech interview then 8 weeks is the
minimum to be given to prepare thoroughly for a tech interview. I know
there are few who would cram up pools of content in a week or two. But, I
believe that is not a realistic or sensible approach.
Tech interviews can be intense and most companies expect you to solve problems or go through a data structure topic in detail.
Now, My study guide with resources will eat up the entire blog space. So,
Instead of straight-up dumping down the content all together, I racked
my brains on how to deliver the content in the most effective way
possible to ensure the habit of consistency and dedication stays intact
during the interview preparation process.
In this blog post, I would give you what to cover each week. If you’re
interested to know what resources to refer to when covering each topic then I’d recommend subscribing to the newsletter https://thedailycoding.com in which you’ll receive one email daily about the concept and the resources to practice.
If you believe you can find resources to relevant topics on your own then
here’s how you should plan to cover each topic every week.
#coding-interviews #software-development #job-interview #job-search #coding #latest-tech-stories #coding-interview-tips #coding-job-interview-advice
1597741200
My Advice After Interviewing 100+ Software Engineers
This awkward and stressful thing between emerging a hero after completing the 12 labors of Hercules and the pointless successive hula hoops jumps of a circus trained animal, which we lightly call job interviews. We all hate them, yet they are an unavoidable fact of our professional lives.
When for the first time I ventured naively into the uncomfortable and inhospitable world of software engineering technical interviews, it didn’t take long for me to feel that judging a software engineer’s ability in 2 or 3 hours is as accurate as cruentation.
However, I always wondered how it was to be like the one sitting on the other side, what it takes to understand if an engineer is a good fit for the role. For the last couple of years, I conducted over 100+ software engineering technical interviews, and although each company has its unique process, there are common pitfalls people tend to fall. Here is my honest advice on how to avoid them.
The good software engineer
“The road to success and the road to failure are almost exactly the same.”
– Colin R. Davis
There isn’t a unique definition for a good software engineer. It relates to the needs of the role and the diversity and maturity of the company. A recent startup would undoubtedly need a short time to market, while a more mature company that grew to a large customer base would probably be facing some scaling and architectural challenges. Building product while understanding what makes sense to the business is different than solving complex technical challenges. A detailed perfectionist engineer is different from a fast iterating one. You need to understand what the company is looking for and frame your behavior and discourse into that mindset. Don’t do a one fits all CV, instead adapt it to that reality. If you have to do a pitch (in a way, you always do one formally or otherwise), frame it in a way that you show how you will be an asset to that specific company. You should understand the necessity the role is trying to fill and ask yourself if that motivates you if it does then embrace it. You should figure what the “good” definition looks like for the company’s context and show how your knowledge, experience, and attitude fits in that definition.
Do your homework
“By failing to prepare, you are preparing to fail.”
- Benjamin Franklin
Going on an interview without having a clue about the company it’s like going on a date and talking only about yourself, doesn’t mean there won’t be a second date but doesn’t give a good impression. Put in the effort to learn about the business, its objectives, it’s mission, strategy, and results. I would never fail someone for not knowing anything about it, but it is a hint of the candidate’s motivation. Also, it is a standard criterion HR tends to evaluate. Besides business goals, be sure to check the company’s tech blog if they have one and know their tech stack. Not very often candidates show legitimate interest for the company, but when they do, it is an excellent way to stand out.
Have a critical sense
“It is the mark of an educated mind to be able to entertain a thought without accepting it.”
- Aristotle
I’ve met exceptional technical experts throughout my career and they were all kinds of different people. Still, all of them had at least one thing in common; they were the ones who defied the status quo and made the processes and technologies improve. So many candidates, when asked if they have questions, have nothing to add. Avoiding asking questions is a wasted opportunity, grab that moment to ask about the technical decisions the company made and the challenges they are facing and discuss the tradeoffs of each technology.
Examples:
Are they considering moving to HTTP/3 yet?
Are they moving to an event-driven microservice architecture? What kind of message broker are they using? Why not use Kafka instead of RabbitMQ?
What kind of database technology are they using? What was the use case? Would ElasticSearch be a good alternative to SQL in that use case?
And so on. Questioning the technical decisions will show that not only you know these technologies and can argue when they should be used but also that you can think critically and ultimately care about improving whatever applications you work with.
#interview #software-engineering #interview-questions #software-development #interview-tips