Except, usually, when these stats are published, they don't calculate, say, the average tenure of everyone who left in the past year. Instead, it calculates, how long has everyone who is currently there been there for. This results in ridiculously large numbers for companies like Kodak and GM, but incredibly low numbers for companies that are growing fast.
Yes that's what he means. You'll find that Google actually seems to rank pretty well in turnover (longer time spent at a single company is good) compared to other countries companies in it's industry.
That's because whatever statistic you pulled doesn't account and adjust for Google's growth which is massive in the past couple of years. If a majority of employees are new hires, then they haven't been there for 2 years and that drags down the average....
We need to stop repeating these statistics with no context. It's incredibly misleading.
Yep. The attrition rate is not even remotely close to 50%. My recollection was that this turnover rumor started with a stat that at one point in Google's recent growth, the median tenure of the employees was only 2 years. This stat then got interpreted (and then reported) by some as Google having an obscenely high turnover. Of course, you can't get turnover rate from median tenure, they're completely different things.
If the size of a company doubles in a year, the median tenure will be <=1yr.
If the most junior employees of another company start quitting en mass, the median tenure for the remaining employees will actually increase.
Median tenure is a completely useless in determining how many people are leaving a company.
Several companies (including Google) have very good associate PM (APM) programs that offer recent grads rotations through a few different roles, mentorship, and a strong peer group. Several APMs end up with rapid upward trajectories at the company and many decide to jump into starting their own companies but it is rare to come across people who did this and regret it.
Some people go into industry or consulting for a bit, get an MBA, and then join directly as a PM. Another popular route (the one I took) is to be a startup founder and learn what works and doesn't on your own terms directly from your own customers.
SWE and PM have very different lifestyles - a PM's day is slammed with meetings and most of your output is email, presentations, spreadsheets, PRDs, dashboards...a SWE's day is more focused on code, ops, design docs - fewer interrupts and more focused. But you likely know this as you've lived both realities already! My advice would be to think about which path suits your disposition and to solve for joy, learning, and impact.
Can you kindly reply to some of questions posted over there? For instance, I too would like to know the path (referral or direct or through interview platforms, etc) TIA
All I do at work is fix bugs by changing a few lines of code and glue together API's to send data from A to B. I don't regularly search BST's using DFS/BFS algorithms or find the kth shortest string in a merged unsorted linked list or some shit like that. Preparing for these technical interviews is like a part-time job after my full-time job.
I'm EXTREMELY interested in finding a new job at literally any company outside of my own. Maybe interviewers don't think I'm interested enough when I can't crank out a 100% correct and optimized algorithm in 15 minutes? /s
As well as screening for social class/culture/values fit. FAANG companies don't want nonconformist people outside of the kool-aid bubble regardless of their abilities.
How does being able to implement standard algorithms and solve programming problems screen out "nonconformist people outside of the kool-aid bubble regardless of their abilities"? These interviews are designed exactly to evaluate ability, in contrast to loosey-goosey "tell me about a time..." culture fit questions where the interviewer can apply their own biases and reverse engineer a justification for whatever hire/no-hire decision they want?
They appear to be evaluating the ability to learn and apply knowledge of previous published works on imperative algorithms. But, as far as I can tell, they aren't testing for much ability beyond this. Where are the questions for logic, formal methods, semantics, mathematics of program construction, functional programming etc? Such theory is much more useful for designing APIs and gluing components together, something I imagine most Google engineers spend the majority time doing.
You mean like the time my CTO said to me concerning the billing system for a telco subsidiary I looked after "this had better be right otherwise we are both out of a job"
But why would one skip over brilliant engineers who are not so desperate? What the desperation brings to the table for the employer and why is that so important?
You need a certain fraction of people willing to just do the required work without complaining -- there is only so much schlep a person can tolerate; certain factors like marriage, children, a mortgage, sick parents, and sense of duty can raise the amount someone can handle. There probably aren't enough slots internally to accommodate the others. Compliance is a very useful trait for employees to have, obviously it falls on a spectrum.
That seems like a facile way to blame any non-hire outcome on the candidate not being Machiavellian enough.
If the emphasis on the candidate's level of proactive interest was truly that heavy... how do you explain recruiters? My level of interest did not cause me to develop psychic powers in order to mentally dominate them into calling me out of the blue.
<<Command: You do not believe Terr_ has psychic powers.>>
IIRC, the published results were that above a certain bar, there was no predictive value to interview results. Having interviewed many dozens of people, and been in dozens of interviews, I can confidently say that the current standards of technical interviews do not screen for quality, but interest.
The whole point of having someone study typical problems to the point where they can solve them in 30-45 minutes is not to demonstrate quality at the job. Rather it is to have them signal that they are interested in doing the things they need to do to get hired. Those types of problems are outside the scope of software engineering, and getting good at them requires a significant investment in time.
Yes, they will reduce the rate of false positives somewhat, but greatly increase the rate of false negatives.
> the published results were that above a certain bar, there was no predictive value to interview results
What I said is not exclusive to this research. These types of interviews are not great, but there's no other "accepted" way and a lot (most?) companies are afraid to try new stuff because making a bad hire is very expensive.
> they will reduce the rate of false positives somewhat, but greatly increase the rate of false negatives.
In addition to what I just mentioned above, the companies that invented and stick to this style of interviewing are well aware of and don't care about the false negatives. Their desire is to reduce false positives and they have a mile long line of willing candidates behind that person if they get a false negative. When you interview at Google/Facebook/etc, your recruiter will tell you that a lot of people don't pass the interview the first time. And if you don't pass, they'll reach out to you again in ~6 months to see if you want to try again.
The companies that use these interviewing processes that don't have a large pipeline of candidates are doing themselves a huge disservice IMO. But kind of like "nobody got fired for hiring IBM"..."nobody got fired for copying Google".
If it makes you feel any better, changing a few lines of code and glueing together APIs to send data from A to B is what 80% of Google engineers do each day too.
protocol buffer to protocol buffer. PBs are a foundational google tech, going back to pre-2000, that are used to store nearly all structured data at google. So, most applications are PB transformers (user request comes in, the user's proto is retrieved, the fields are accessed to produce a new record that is sent as a request to a backend, etc).
Scaffolding sounds lame. I wonder how many engineers are treated this way at Google, implementing someone else's idea that is likely confined to the scope of the company. I mean, someone has to dig the trenches. "Working at Google" sounds overrated.
I would hate to get employed at Google and then work on Google+ for ten years. Seriously? No one cares about Google+. You're a slave at Google, they are literally doing statistical experiments with your time.
It is known, people turn down Google offers all the time to remain independent. Working for a big company doesn't give you a lot of freedom, unfortunately.
I don't know about google, but on my first proper job after graduating (the actual first lasted only two months) I was given a coding problem that involved writing a parser. After I got hired in the company I spent about seven months gluing APIs and adding one-liners etc, but in those seven months I once actually had to write a parser (for Tag-Length-Values). And in the seventh month, another engineer had a problem that was almost identical to my interview question- we were all gathered together around their monitor laughing about it.
So I'm guessing, it's not for the everyday stuff that google thinks you need to know how to invert binary trees etc, it's for that one time when you'll really need to do it.
... of course, at that point you can just look up the solution, but I guess they want to make sure you can understand it.
I think the real value is in the ability to recognize the opportunity to apply an algorithm when it arises. You can't just look that up on stack overflow and the alternative is usually spending 10x as long to write a large logic hairball filled with bugs and missing edge cases. Apply another 10x multiplier for the maintenance.
I've inherited enough of these (deeply nested code hairballs that can be replaced by a comparatively miniscule set of tree traversals or something) to change my view from "algo is just programmer status signalling" to "algo is a core competency that matters."
There is something wrong with our general approach to programming. Majority of "real" work is writing total functions (in the sense, non-recursive). Yet, we very much insist on using Turing-complete languages everywhere.
I suspect we would be better off if we used total domain specific languages for the majority of the work (data transformations) and TC languages only sparsely, where we cannot avoid recursion.
This is somewhat what you do when you write SQL, but SQL is an OLD language and it doesn't compose well with other things.
This approach is exemplified by for example Facebook's Haxl, which is a functional domain specific language for filtering content. So you write the domain code in a specific language, which is easily transformed/compiled.
(Actually your TC and your DS language don't need to be different syntactically, they can be both based on a common functional language.)
Interestingly, the interviews are very much based on TC language notions.
That's exactly what I did for a FB interview 2 yrs ago, I essentially had a +4 hour session every day after work to practice programming questions. I thought it was fun, a nice break from the everyday "fix code and do 1:1s".
while i am not fan of algorithmic interviews every six months or so i come across text book algorithmic problems in my routine work which is nothing fancy just maintaining legacy code.Recently there was a library given by one of the big four's which had to be integrated into our system. It was working fine on pc but the moment it was brought into embedded system it started corrupting the stack, turned out that it was constructing the tree via recursive call which was blowing up the stack. We had to convert it from DFS to BFS to get it working.
So i would certainly not discount value of having good knowledge of algorithms.
I understand what you're saying and I generally agree that algorithmic/coding interviews are broken. But you know what? Sometimes you need the fancy stuff.
I once stumbled upon a problem at work that, after some thinking, I realized could be modeled as a graph problem and solved by performing a topological sort. It was a good and elegant solution to the problem. But what if it hadn't landed on my plate, and instead on someone who didn't know a thing about graphs? The problem might not have been solved (which would mean great pain for our customers, since it was on a feature that customers directly interfaced with), or worse, someone else might have turned up with a horribly messy, spaghetti-like solution.
So I think companies should actually hire people who know their CS fundamentals, even if 80% of the time they'll be doing trivial work that someone less qualified could do. What matters though is having people that are ready for the hairy stuff when it comes up.
Most real world problems don't have elegant solutions though. There might be an elegant concept behind the solution but usually the end implementation gets pretty dirty.
The dirty stuff ends up being most of the work and is what counts for the most in the end product. Companies should be hiring on the ability to take care of the dirty tweaking and tuning. But this experience is something that can only be seen in past projects and that's too much work for a hiring manger to be bothered with.
I actually had the same experience as you. Finding a solution using topological sort. I agree that familiarity with basic data structure and algorithm is a must for engineer. But for interviews that solely depending on fancy coding algorithms that must be done within 15 minutes is insane. Combining grasping of algorithm with problem solving with real project experiences and willingness to learn new tech would be more effective in interview.
Agreed. I think the data structures part of an interview doesn’t require a whiteboard coding puzzle. If someone knows what a graph is and can describe a well-known graph algorithm like Dijkstra’s or topological sort, that’s more than enough to know what the person knows.
Mere coding ability is easily tested with fizzbuzz-like problems.
I too recently had a problem where creating a graph with a topological sort was the answer. I am comfortable with graph theory ideas, but I had never heard of a topological sort, but easily found it with Google.
I have an education in engineering and I am entirely self-taught on the software side. I think the most valuable thing is learning and exposing yourself to as many ideas as possible. Once you know what "boxes to look in" constructing search terms and finding answers isn't that difficult.
These are useful tips, although the example questions are extremely outdated. I found one tip "interesting" though.
> If you already know the answer, don't just blurt it out! They will suspect that you already knew the answer and didn't tell them you've seen the question before. At least pretend to be thinking though the problem before you give the answer!
Most interview questions are taken from sites like Leetcode. So you would have come across some of them if you work through those problems. Is it really that bad if you give the solution quickly? Some problems have specific "techniques" to solve them which you would likely only know if you solved it before. Are you expected to come up with a completely new algorithm to solve a problem?
Short answer, yes. They don't expect a perfect answer but do expect something better than brute force (with presumably higher expectations depending on the level role). The better the answer is optimized the more impressive. Another part of it is the interviewers want to see at least some thought process. So if you stall giving the answer away you show alleged thought process and an excellent solution allegedly come up with on the spot.
>Most interview questions are taken from sites like Leetcode
For phone screens: sure. Frankly, a lot of people will bomb a fizzbuzz-level question at the phone screen so why bother spending time thinking of a good question that they might leak onto the internet, forcing you to take the time to make up another?
Interviewers tend to take the on-site a bit more seriously and will at least add an unusual wrinkle to a leetcode question to stump anyone who just has a great memory but very little actual ability.
> If you already know the answer, don't just blurt it out! They will suspect that you already knew the answer and didn't tell them you've seen the question before. At least pretend to be thinking though the problem before you give the answer!
Ah yes, deceit and trickery, the basis of any solid future working relationship.
It is absurd that instead of correcting own bias against people who happened to randomly run across exactly the same problem, they advice you to pretend ignorance.
>"> If you already know the answer, don't just blurt it out! They will suspect that you already knew the answer and didn't tell them you've seen the question before. At least pretend to be thinking though the problem before you give the answer!"
This to me epitomizes the absurdity of this whole "leet code, cracking the algorithm" mania that has blighted the tech interview process. The only way to pass these types of tests is to spend time studying them. But then if you have studied and therefore know the tricks(use two pointers etc.) its seen as unacceptable enough that you should either lie or tell your interviewer "I know the trick" to solving this so ask me something else." The whole thing has become a scripted charade.
I get it that these types of tests and interviews work for Google but it's absurd when small startups still building a product adopt these tests simply because Google and FB do it.
There's a sad corporate uniformity to it that feels very much at odds with the hacker ethos.
A better response would be honesty: "I've seen this question before on a (puzzle/interview prep/whatever) site. The optimal answer was better than what I initially came up with... I didn't consider that we knew one of the coins was explicitly heavier than the others, I was only thinking that one was a different weight. That's a good reminder to read your specs very closely."
I dealt with this recently. Was asked to implement a LRU cache. I knew the trick, use two data structures to keep things sorted and accessible in constant time. Could do it in my sleep. Had to pretend I had never seen it before, started with a non optimize d solution and added the correct pieces to make it optimal. Interviewer seemed miffed, kept adding tests to see if my algorithm would get the wrong answer and seemed upset that I got it right. It was bizarre. Didn't get the job, didn't remember the answers to a few of the other questions, though I found them post interview.
Probably because you deprived them of the opportunity to feel superior because they knew the answer and you didn't. You probably dodged a bullet - would you want to work with someone that got "miffed" during an interview because you knew the answer to something?
CTCI puts an emphasis on interviews whereas this book is only about competitive programming.
CTCI tries to make interviews about competitive programming, this book is about competitive programming itself.
CTCI offers some high level problem solving advice, and a list of exercises. This book elaborates provides a framework for understanding the exercises and elaborates on techniques for each type of data structure.
Can any interviewers at Google or any of these large corporations share about how the interviewing process has changed in the last few years as now Cracking the Coding Interview, HackerRank/CodeWars/LeetCode, Glassdoor, mock interview sites, and even interview-prep bootcamps have become part of the curriculum for potential candidates to prepare for interviews? Do the companies find it as absurd as the candidates do?
Not an interviewer in Google, but have been in Google.
I've read CtCI, used the mentioned and/or other websites for problem solving and have had 10+ interviews on pramp.com and interviewing.io, both as an interviewer and interviewee.
Due to my experiences and experiences of other people that I know, my conclusion is that the interviewing process has not changed. Google has a pool of thousands of questions, so you likely did not hear the questions that they'll ask you before coming there, unless it's the question to establish whether you're a programmer at all or not (phone screen). Like learning to drive -- you don't go out and memorize every road by heart, but learn how to act on the road and interpret situations, signals and signs. Those resources shouldn't teach you the questions, but teach you how to really be you in an interview and perform at your nominal level.
After going through the above resources, my impression is that they have helped me type faster, make less mistakes in boilerplate and think more about the problem when it's given, before diving into it. Certainly, I do remember a few "tricks" more than I used before going through them, but overall, I think they've helped me very little with the problems in interviews and more with my behavior in interviews. The pattern that I've always seen is that intelligent people who code well pass the interview more often than not and that less intelligent people and/or those who don't code well don't pass ever.
My employer (albeit not so large on the engineering side) seems to have doubled down and are mandating teams use HackerRank to give remote tests, whereas before teams had more flexibility to do better/worse with the process or do the standard thing. I find it absurd, and am glad intern interviews are still flexible for now...
I run a (paid) newsletter that sends fun coding interview puzzles every day. If you're interviewing around (or if you just enjoy programming problems), check out Daily Coding Problem: https://dailycodingproblem.com/!
You should've mentioned that email address is required and solutions are $25 a month. But other than that good idea if the actual puzzles and solutions are valuable.
You're right, I updated it to reflect that it's paid. I think email address is implied by the newsletter though.
I'm obviously biased but I think the problems are fun and the solutions are valuable. Here are some blog posts I wrote that hopefully give you an idea of our questions:
I get really nervous with timed interviews, ticking clock freezes my mind.
Wondering if you have any tips for that.
I code in java at my day job but its not really well suited for whiteboard interviews where I have write all this code on the board. Google interviewer was noting down what I was writing on whitboard and said that he will compile the code after the interview. Wondering if you have any thoughts about it, maybe choose something more consise like ruby?
Why not compile and run the code during the interview? IMHO it should be way faster than writing stuff on the whiteboard and will save the interviewer the trouble later.
99 comments
[ 3.0 ms ] story [ 75.2 ms ] threadhttp://www.businessinsider.com/employee-retention-rate-top-t...
We need to stop repeating these statistics with no context. It's incredibly misleading.
If the size of a company doubles in a year, the median tenure will be <=1yr.
If the most junior employees of another company start quitting en mass, the median tenure for the remaining employees will actually increase.
Median tenure is a completely useless in determining how many people are leaving a company.
What is the source of this statistic? Do you have a citation?
"The class is held in room 32-124 from 5:00-6:30 PM on January 12 - 15, 2009"
Context: I'm on the Google PM Hiring Committee and help craft our hiring rubrics.
Several companies (including Google) have very good associate PM (APM) programs that offer recent grads rotations through a few different roles, mentorship, and a strong peer group. Several APMs end up with rapid upward trajectories at the company and many decide to jump into starting their own companies but it is rare to come across people who did this and regret it.
Some people go into industry or consulting for a bit, get an MBA, and then join directly as a PM. Another popular route (the one I took) is to be a startup founder and learn what works and doesn't on your own terms directly from your own customers.
SWE and PM have very different lifestyles - a PM's day is slammed with meetings and most of your output is email, presentations, spreadsheets, PRDs, dashboards...a SWE's day is more focused on code, ops, design docs - fewer interrupts and more focused. But you likely know this as you've lived both realities already! My advice would be to think about which path suits your disposition and to solve for joy, learning, and impact.
I have a couple of leads for you if so.
As well as screening for social class/culture/values fit. FAANG companies don't want nonconformist people outside of the kool-aid bubble regardless of their abilities.
If you were interested in the job, you would do enough studying to become "consistent enough" across 6 interviews.
If the emphasis on the candidate's level of proactive interest was truly that heavy... how do you explain recruiters? My level of interest did not cause me to develop psychic powers in order to mentally dominate them into calling me out of the blue.
<<Command: You do not believe Terr_ has psychic powers.>>
The whole point of having someone study typical problems to the point where they can solve them in 30-45 minutes is not to demonstrate quality at the job. Rather it is to have them signal that they are interested in doing the things they need to do to get hired. Those types of problems are outside the scope of software engineering, and getting good at them requires a significant investment in time.
Yes, they will reduce the rate of false positives somewhat, but greatly increase the rate of false negatives.
What I said is not exclusive to this research. These types of interviews are not great, but there's no other "accepted" way and a lot (most?) companies are afraid to try new stuff because making a bad hire is very expensive.
> they will reduce the rate of false positives somewhat, but greatly increase the rate of false negatives.
In addition to what I just mentioned above, the companies that invented and stick to this style of interviewing are well aware of and don't care about the false negatives. Their desire is to reduce false positives and they have a mile long line of willing candidates behind that person if they get a false negative. When you interview at Google/Facebook/etc, your recruiter will tell you that a lot of people don't pass the interview the first time. And if you don't pass, they'll reach out to you again in ~6 months to see if you want to try again.
The companies that use these interviewing processes that don't have a large pipeline of candidates are doing themselves a huge disservice IMO. But kind of like "nobody got fired for hiring IBM"..."nobody got fired for copying Google".
Even the coolest idea requires scaffolding. The larger/more novel the idea, the more (re)scaffolding needed.
I would hate to get employed at Google and then work on Google+ for ten years. Seriously? No one cares about Google+. You're a slave at Google, they are literally doing statistical experiments with your time.
It is known, people turn down Google offers all the time to remain independent. Working for a big company doesn't give you a lot of freedom, unfortunately.
So I'm guessing, it's not for the everyday stuff that google thinks you need to know how to invert binary trees etc, it's for that one time when you'll really need to do it.
... of course, at that point you can just look up the solution, but I guess they want to make sure you can understand it.
I've inherited enough of these (deeply nested code hairballs that can be replaced by a comparatively miniscule set of tree traversals or something) to change my view from "algo is just programmer status signalling" to "algo is a core competency that matters."
I suspect we would be better off if we used total domain specific languages for the majority of the work (data transformations) and TC languages only sparsely, where we cannot avoid recursion.
This is somewhat what you do when you write SQL, but SQL is an OLD language and it doesn't compose well with other things.
This approach is exemplified by for example Facebook's Haxl, which is a functional domain specific language for filtering content. So you write the domain code in a specific language, which is easily transformed/compiled.
(Actually your TC and your DS language don't need to be different syntactically, they can be both based on a common functional language.)
Interestingly, the interviews are very much based on TC language notions.
I once stumbled upon a problem at work that, after some thinking, I realized could be modeled as a graph problem and solved by performing a topological sort. It was a good and elegant solution to the problem. But what if it hadn't landed on my plate, and instead on someone who didn't know a thing about graphs? The problem might not have been solved (which would mean great pain for our customers, since it was on a feature that customers directly interfaced with), or worse, someone else might have turned up with a horribly messy, spaghetti-like solution.
So I think companies should actually hire people who know their CS fundamentals, even if 80% of the time they'll be doing trivial work that someone less qualified could do. What matters though is having people that are ready for the hairy stuff when it comes up.
The dirty stuff ends up being most of the work and is what counts for the most in the end product. Companies should be hiring on the ability to take care of the dirty tweaking and tuning. But this experience is something that can only be seen in past projects and that's too much work for a hiring manger to be bothered with.
Mere coding ability is easily tested with fizzbuzz-like problems.
I have an education in engineering and I am entirely self-taught on the software side. I think the most valuable thing is learning and exposing yourself to as many ideas as possible. Once you know what "boxes to look in" constructing search terms and finding answers isn't that difficult.
> If you already know the answer, don't just blurt it out! They will suspect that you already knew the answer and didn't tell them you've seen the question before. At least pretend to be thinking though the problem before you give the answer!
Most interview questions are taken from sites like Leetcode. So you would have come across some of them if you work through those problems. Is it really that bad if you give the solution quickly? Some problems have specific "techniques" to solve them which you would likely only know if you solved it before. Are you expected to come up with a completely new algorithm to solve a problem?
For phone screens: sure. Frankly, a lot of people will bomb a fizzbuzz-level question at the phone screen so why bother spending time thinking of a good question that they might leak onto the internet, forcing you to take the time to make up another?
Interviewers tend to take the on-site a bit more seriously and will at least add an unusual wrinkle to a leetcode question to stump anyone who just has a great memory but very little actual ability.
Ah yes, deceit and trickery, the basis of any solid future working relationship.
This to me epitomizes the absurdity of this whole "leet code, cracking the algorithm" mania that has blighted the tech interview process. The only way to pass these types of tests is to spend time studying them. But then if you have studied and therefore know the tricks(use two pointers etc.) its seen as unacceptable enough that you should either lie or tell your interviewer "I know the trick" to solving this so ask me something else." The whole thing has become a scripted charade.
I get it that these types of tests and interviews work for Google but it's absurd when small startups still building a product adopt these tests simply because Google and FB do it.
There's a sad corporate uniformity to it that feels very much at odds with the hacker ethos.
Or something like that.
Probably because you deprived them of the opportunity to feel superior because they knew the answer and you didn't. You probably dodged a bullet - would you want to work with someone that got "miffed" during an interview because you knew the answer to something?
CTCI tries to make interviews about competitive programming, this book is about competitive programming itself.
CTCI offers some high level problem solving advice, and a list of exercises. This book elaborates provides a framework for understanding the exercises and elaborates on techniques for each type of data structure.
I've read CtCI, used the mentioned and/or other websites for problem solving and have had 10+ interviews on pramp.com and interviewing.io, both as an interviewer and interviewee.
Due to my experiences and experiences of other people that I know, my conclusion is that the interviewing process has not changed. Google has a pool of thousands of questions, so you likely did not hear the questions that they'll ask you before coming there, unless it's the question to establish whether you're a programmer at all or not (phone screen). Like learning to drive -- you don't go out and memorize every road by heart, but learn how to act on the road and interpret situations, signals and signs. Those resources shouldn't teach you the questions, but teach you how to really be you in an interview and perform at your nominal level.
After going through the above resources, my impression is that they have helped me type faster, make less mistakes in boilerplate and think more about the problem when it's given, before diving into it. Certainly, I do remember a few "tricks" more than I used before going through them, but overall, I think they've helped me very little with the problems in interviews and more with my behavior in interviews. The pattern that I've always seen is that intelligent people who code well pass the interview more often than not and that less intelligent people and/or those who don't code well don't pass ever.
I'm obviously biased but I think the problems are fun and the solutions are valuable. Here are some blog posts I wrote that hopefully give you an idea of our questions:
Given a table of currency exchange rates, determine whether there is a possible arbitrage: https://dailycodingproblem.com/blog/2018/01/02/find-an-arbit...
Picking a random element from an infinite stream: https://dailycodingproblem.com/blog/2017/11/30/random-elemen...
Merging k sorted lists: https://dailycodingproblem.com/blog/2017/11/29/how-to-solve-...
Or point folks to some notes from an updated version of the class.
Wondering if you have any tips for that.
I code in java at my day job but its not really well suited for whiteboard interviews where I have write all this code on the board. Google interviewer was noting down what I was writing on whitboard and said that he will compile the code after the interview. Wondering if you have any thoughts about it, maybe choose something more consise like ruby?
I would love to get updated version of notes.