Google Coding Interview With a Google Software Engineer

Comments · 955

• GE

  @Geo_vanni_H · 1 year ago

  I like to pretend I understand what I’m watching.

  2K

• JU

  @justingonzalez7279 · 1 year ago

  I learned something today.. I don’t know what I learned, but I learned something.

  1K

• DO

  @dorbabaioff3188 · 6 months ago

  Honestly his solution is way more complex than what is needed and his computation complexity is higher than what he calculated

  185

• CH

  @charan2234 · 10 months ago

  What a great learning session, i learned that I'm cooked 👍🏼

  196

• SH

  @shayanxyz · 8 months ago

  Passing google's interview is easier, getting interview is where the game is.

  100

• HA

  @haywardhaunter2620 · 1 year ago

  I worked at Google for 12 years and conducted at least 100 software engineering interviews there, and I&apos;ve done 100s more at other companies before that. &nbsp;The coding problem questions are really two things: &nbsp;the &quot;problem&quot; (how to count subsequences) and writing the actual code.<br><br>The specific problem is largely irrelevant. &nbsp;It should be just hard enough to give the candidate a chance to show how they approach problems, to see how well they communicate with another engineer on a technical problem, and to get a small code sample. &nbsp;(The best questions can also be tweaked on the fly to make them easier or more challenging.)<br><br>Make sure you understand the question. &nbsp;Even if you think you do, asking an articulate question about an edge case to demonstrate that you&apos;re thinking through the details.<br><br>If you have an observation about an aspect of the problem, let the interviewer know. &nbsp;(The candidate here did that by figuring out the number of possible subsequences was 2^len(s).) &nbsp;<br><br>Always start with the simplest, most direct algorithm you come up with. &nbsp;Don&apos;t assume you&apos;ll need to create an data structure to index into the data. &nbsp;If it&apos;s stupidly inefficient, make sure the interviewer knows that you know that. &nbsp;(&quot;That would be O(n^3), which is crazy. &nbsp;It seems like there should be an O(n log n) way.&quot;) &nbsp;And then brainstorm alternative approaches. &nbsp;Not just alternative solutions, but <i>approaches</i> that might lead to a solution.<br><br>(Wonder aloud: &nbsp;&quot;What if I had an index ... ?&quot; &nbsp;&quot;If I used a recursive search, would I need backtracking?&quot; &nbsp;Interviewers will often steer you away from directions that lead to dead ends.)<br><br>Decompose the problem. &nbsp;Separate the hard part (checking if a word is a subsequence) from the easy part (counting). &nbsp;If you&apos;re stumped on the hard part, see if breaks it down further (building the index versus actually testing the word).<br><br>Sometimes we just don&apos;t see the &quot;trick&quot;, and that&apos;s OK. &nbsp;The interviewer should be managing the clock. &nbsp;If you&apos;re stuck, they should give you a hint. &nbsp;But if they don&apos;t, ask for a one. &nbsp;&quot;I&apos;m stuck, gotta hint?&quot; is fine, but a specific question, like &quot;How do I avoid rebuilding the index on every word?&quot;, is better. &nbsp;Or explicitly make a simplifying assumption. &nbsp;(&quot;For now, let&apos;s assume I have an index I can query this way. &nbsp;If there&apos;s time at the end, I&apos;ll show how I&apos;d create that index.&quot;) &nbsp;You&apos;d be doing the interviewer a favor. &nbsp;If they don&apos;t walk out of there with a code sample, they failed.<br><br>If you panic, say, &quot;I&apos;m going to code the simple solution, while I think more about how to make it faster.&quot; &nbsp;It&apos;s better to have a correct implementation of a suboptimal algorithm than incomplete or flawed code for an optimal one.<br><br>As an interviewer, I judged the coding part of these interviews almost completely independently from the problem solving part. &nbsp;For me, the main issue is whether they can comfortably and fluently express their idea in the code. &nbsp;I don&apos;t just look at the final code; I watch how they write the code in real time. &nbsp;Someone who knows their language well won&apos;t struggle with syntax when writing an expression, an if statement, or a loop. &nbsp;Even more experienced coders usually reach for the right type of loop and put thought into making good interfaces. &nbsp;When the syntax and mechanics of your language are so ingrained that they don&apos;t require much conscious thought, you can stay focused on correctness and understandability. &nbsp;It&apos;s one thing to have a logic bug. &nbsp;It&apos;s another to write code that doesn&apos;t something very different than what you set out to write (and, yes, I&apos;ve seen that many times).

  909

• JA

  @jason_lalrem · 10 months ago

  My dream job was a software engineer at Google, but after watching this, its better to stick with freelancing

  135

• AD

  @adnanhossain3152 · 6 months ago (edited)

  This must be how our pets feel when they see humans interact. Thank you for that.

  23

• DM

  @dmitrypetrov8491 · 11 months ago

  it&apos;s &quot;no hire&quot; in my humble opinion.

  107

• PS

  @PsyntaraOfficial · 8 months ago

  I am happy that I figured out the logic on my own , but I am a bit sad that I still struggle to code it properly

  11

• CE

  @cetizen7909 · 9 months ago

  Watching it for 10 minutes made me go to the restroom and take a dump

  36

• KI

  @kingbluecr7102 · 10 months ago

  Remember guys, if you ever get stuck... THROW A HASMAP ON THE PROBLEM!

  250