How to Ace the Google Interview: Ultimate Guide(byte-by-byte.com) |
How to Ace the Google Interview: Ultimate Guide(byte-by-byte.com) |
The main things I want to see, though, are: can you communicate well about the parts of the problem that aren't clear to you? Can you analyze and compare solutions? Can you figure out something reasonably efficient? Do you understand your solution well enough to code it?
(Speaking for myself, not my employer.)
Received the green light and moved to the next phase, where I spoke with potential teams over the phone, then settled with Google Maps. Met with one of their Tech Leads, cool. I was really happy and though that all my effort to prepare for the “Google interview” had payed off.
Then no word back from the recruiter with a final offer. It turns out the VP of eng saw some red flags in my interview and decided to bail.
I felt really frustrated and while I spoke I spoke with the recruiter he apologized and even said the hiring manager was on my side and people overall liked me but there were two engs that were on the fence. Gosh, I think I met with 7-8 engs, all the seniors seemed to like me. I remember not having the best conversation with 2 engs who were new to the company and could not relax nor communicate well.
Bottom line, prepare but also be prepared for some degree of luck and arbitrary judgements.
Yes, there are great interviewers in google. Engs that are engs in their minds and hearts, who can see the process is not perfect but work to get it better. But unfortunately, there are insecure folks who should be better trained for before interviewing candidates.
That was 5 years ago, not sure I would subject myself to this sort of loop even again. And strange enough they contact me few months after to reinterview but this time I could skip the big loop and meet with just 3 engs... I said no since I was already in a new job.
These guides act as optimizations, shortening the path you need to take to get the job, shortening the stuff you need to learn, etc. But in the end, the path is all you get. If you don't like programming and if you don't like learning, then are you really gonna like Google?
I suppose there's people who genuinely like programming who just need a manual to teach them how to play the game. Lord knows I've practiced my fair share of whiteboard problems when I'd rather be reading about compilers. But there's something wrong about having to play a game to get the job.
Is it true that an experienced developer would not be able to pass the interview without studying using a similar guide? If so, then the interview process is... fubar.
If the process is so nuanced that there's an entire industry around these types of guides (and Google even highly recommends you buy them!), then the process is fundamentally flawed.
But we already knew that, and as long as others are still playing the game, we are forced to play or miss out.
Keyword research and trends... https://trends.google.com/trends/explore?date=all&geo=US&q=G...
When you search modern interview topic and comments/opinions on the current process, you'll find a few SEs (typically working at places like Google at some point) on that on the side sell training bootcamps, etc. These people will swear every direction that it's a reasonable process in comments around the web referring to their side business. Creating problems they provide solutions to: gatekeeping 101.
They don't test for good engineers -- they test for people who practice these style interviews, and for good new graduates.
It makes sense to ask these questions to new grads, but afterwards there is so much more experience that I feel like is much more important than acing data structures questions.
I am amazing at whiteboard questions, but that doesn't make me a good engineer. It's because I found the trick to solving these, and have practiced them. A lot of it it is practice 'ooo this looks like a graph problem, let me use a graph', etc.
That actually does make you "a good engineer". The vast majority of developers wouldn't even be able to recognize that much.
Prepping while working is draining.
That part is not completely correct. At onsite can choose to write code in a Chromebook which will have a lightweight editor with syntax highlighting.
from collections import defaultdict
def dups(seq):
d = defaultdict(int)
for x in seq:
d[x] += 1
return [k for k, v in d.items() if v > 1]
Of course, once we start optimizing how the original array is stored, we may have exceeded the limits of this problem as a teaching exercise :)
As for time, it does seem to be O(n) to me; can you clarify why you think it's nlogn? It may not be particularly fast in practice when compared to other O(n) approaches like the bitmap, but I don't think the complexity is wrong.
Your solution is nice - it actually gives you more information (how many appearances, not just T/F >1 appearance), but it does require more additional space and isn't necessarily faster. I think the bitmap approach would be nicer if you're ok with using more space; the bitmap is essentially a very easy to find perfect hash function due to the unique input constraints.
> Analyzing the above approach, we have an algorithm that takes O(n) time and uses O(1) space.
Yes, I confirmed that by pasting it into the REPL and verifying that it gives the wrong answer for a one-element list. Apparently the author failed to follow his own advice to always test code that you write.
In Silicon Valley, tech interviewing has become an arms race between applicants cramming to pass tech screens and interviews, and employers coming up with new routines. Sites like Glassdoor and CareerCup are loaded with interview questions that have appeared in those routines, giving savvy interviewees the opportunity to see the questions on the exam and prepare accordingly.
How do you feel about the existence of these sites, and do they affect how interviews are conducted?
This also discourages overly complex or overly familiarized questions. If the question is too complex, chances are it will end up posted online soon after, penalizing the interviewer in time cost. If a new question is recycled frequently, it will also likely end up online at some point and penalize interviewers from using questions they're overly familiar/biased in assessment to based on their own rote learning.
Good for them financially maybe. Professionally, I didn’t see they go beyond the average senior dev. But that just me being sour.
If you just want to know what the interview for your roles would be, the recruiter from Google will happy to give you an overview.
But to answer your question, yes, absolutely.
This is not a thing. Everyone goes through the same level-adjusted loop.
> Another way is to be a significant contributor to some popular open source project.
LOL no. Google is literally famous for rejecting major open source contributors for not knowing how to reverse a binary tree.
AFAIK, you could swap the child pointers and do that recursively for the child nodes. You could also do things O(1) by just changing the comparison function, perhaps by wrapping it to negate the comparison.
They probably didn't want Brew author that much; we don't know the details.
As for popular open-source projects, I don't know about Guido van Rossum or Rob Pike, but Max Howell definitely whiteboarded in his interview: https://twitter.com/mxcl/status/608682016205344768
There are also many people who are great at programming, wh love it, who are terrible at interviewing. After all, these are two related, but ultimately different skills. You talked about it yourself in your last paragraph, ending with:
> But there's something wrong about having to play a game to get the job.
Sounds like the fault is on the employer that makes you play the game, not on "people want to be employed without becoming employable".
I'm scared shitless of whiteboard exercises (and - probably biased by that - see no point in them). There's no way I'd be able to get through them UNLESS I optimize for .. whiteboard programming interviews w/ resources like this site.
In spite of writing code every day, for 15 years plus, and although I LOVE programming, this just excludes me from the list.
(This hits a bit close to home for me because my employer of 13 years just got bought and I'm in the process of looking for interviews again - for the first time since 2006..)
When I interviewed around 2008, there was whiteboarding, but only psuedo code based which I could do just fine. The majority of interviews focused on questions regarding time/space complexity trade offs, design choices, etc. not on-the-fly fully optimized implementation solutions, first pass. The worst thing I ran into was having to write merge sort as the FizzBizz of the time.
Now, it's an absolute circus. Most in the industry really don't know what they're looking for and how to adequately assess abilities. They're far more concerned with trivia and memory recall and filtering any remote risk of a false negative than actually accomplishing the tasks for the position at hand.
The current process is very well designed on multiple fronts to attempt to delegitimize professionals and is quite optimized at grabbing fresh grads desperate for work experience or finding cheaper labor without raising red flags on illegal hiring processes. Why people have put up with this practice boggles my mind.
The vast majority of roles don't need Alan Turing, Donald Knuth, or Jon von Neumann to accomplish some basic business goals so let's be realistic and stop pretending they do.
No one at Google is going to recommend hiring you if they think you'll be in the bottom 50% of engineers at Google when you join. However, 50% of the people hired by Google end up in the bottom 50% of engineers. And frankly, hell there's plenty of jobs that don't require a rockstar. So in many ways you need to be better to get the job than to do the job.
Theses are 2 skills totally different and not exclusive at all.
A skill need to be learned and practiced. In the case of interview, for a pretty good reason, it's not a skill that we practice usually and once you need to do it, you lack experience and fail even though you could have what needed to do the job.
In that sense, it's probably a good indicator for Google that the interview advice includes "practice writing code", "make it a habit to validate input", and "learn about data structures", and it's probably a bad indicator for Google that the advice includes "practice writing syntactically correct code on a whiteboard" and "practice solving problems with a 30 minute timer."
> practice writing syntactically correct code on a whiteboard
This probably differs from interviewer to interviewer as to how strictly it's adhered to, but it's not really a hard and fast rule. I'm sure there are some interviewers that will ding you on a forgotten semicolon, but I suspect that most would not.
Personally I look for code that isn't so far from syntactically correct that it's clear you are trying to BS me. I'll even accept pseudocode for the most part. But I've had candidates that try to make up language features, and that doesn't fly with me.
> practice solving problems with a 30 minute timer
I only give my candidates 30 minutes. The whole interview is 45, I spend 5 minutes introducing myself and setting up expectations, 30 on the question, and 10 on answering their questions (after all, they're also interviewing us).
You can tell pretty early whether they're on a solid trajectory, and I'll offer the occasional hint to keep someone on track, or ask tangential questions if they're doing well on time. Not finishing isn't a deal killer, provided you had a solid approach and weren't just running in circles. But a good candidate will finish in about 25 minutes and we can spend some time talking about alternate approaches. Sometimes I'll show them the optional approach and see how that conversation goes.
Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions and candidate wasn't able to realize that even with hints.
Based on their perception of my algorithmic experience from my CV? Google's a weird one.
Even Google suggest to "practice writing syntactically correct code on a whiteboard". This is clearly a useless skill as a software engineers except in getting a job at companies that do whiteboard interviews. Did you try to refactor code on a whiteboard?
How are they able to find people that are able to efficiently debug problems?
When I interview people I tell them, "Bring your own laptop set up to be able to code and debug". And I give them "Fix this site" or "build this thing" kind of problems.
It looks like that it works a lot better to find "hidden gems" and people that are good at "doing" instead of those that are jsut good at "telling".
One of the best interviews that I've ever had was a screen-sharing session that was based around much the same mentality: "I have this problem. Script a solution in whichever language you choose in notepad. Now, here's sample data. Run it. O.k. It doesn't work as you intended, so start debugging it."
We (as an industry) focus on developing, when debugging is an equally desirable skill. If you can't understand why your code is breaking and need someone else to assist you, then it isn't - necessarily - a bad thing but you are consuming another resource that could be best devoted to other things during the time it takes to sort the problem that you created out.
Have you ever actually been on the interviewer end of the process?
Literally over half of the candidates literally don't know how to program! They can sort of string together a Markov-chain something if you sit them down in front of an IDE and let them copy-paste stuff until syntactic errors go away, but put them at a whiteboard and they don't know where the parentheses go in a function call.
(They'll write crap like "()f" or "f()a" when they want to call a function, stuff like that.)
I'd be a lot more comfortable with "We have a machine set up for you, but you can also bring your laptop," as long as the machine is actually well set up and you don't fall into the implicit expectation that passing candidates will bring their laptop anyway. (Most of them will, in the end.)
Still no access to a compiler or debugger, but baby steps.
Syntax is probably something that without fail novices screw up. I saw this in my own subordinates who simply would not see on their own laptops, even with the red squiggle underline, syntax errors in their own code. Also, I'm sure Google has data on its interviewing process and found in some important, measurable way that there's a problem with hires who screwed up the syntax. Correspondingly, none of my decent subordinates ever screwed up syntax once. I think this is the least controversial part of their process because it is dumbfoundingly easy and low cost.
Engineering interviews are overall a mature process and I honestly doubt there's that much innovation in terms of raw skills discovery. TripleByte, for example, doubled its multiple choice question count from 18 to 36, introducing design questions, and now has a brief 45 minute free programming problem. Hardly a huge innovation.
Clearly what's immature is the feedback and communication to candidates that fail. At Google specifically communications problems don't just crop up in threads full of rejects. Bad communications affect people working there, like product managers, admins and designers, who lack the skills they test for despite the tests themselves not obviously corresponding to anything the engineer actually does day-to-day.
It's bad for morale to test for stuff that doesn't matter. That may explain why smart people report the engineering org is not welcoming to people of different backgrounds. The empathy (or savvy) needed to throw out stupid tests is the same kind you need to understand people who don't share the same culture or values as you.
Google doesn't really know that because the company only knows the things it measures. It takes insight too to know what to measure and how things are related, especially when dealing with human beings and not software.
That is too say, their interviewing process explores things at sufficient depth and breadth to make knowing "the" solution not a deciding factor.
on a related note, I write scala on daily basis but scala is not that well suited for coding interviews, I found.
Kidding aside, why do you feel Scala is unsuited to coding interviews, assuming the interviewer well-understands the language?
The most obvious change was to accept psuedo-code (like in the olden times) to reduce cognitive load dealing with: syntax, dynamic problem solving, and dealing with someone asking you random questions shifting your train of thought or changing the problem description on the spot.
This now common poorly structured interview process does a lot to discourage high level conversation and low focus on syntax. It tends to get hung up on language specific syntax, data structure recall, and less on designing and analyzing solutions.
BS atop BS... its BS all the way down
Honestly this sounds like a thought experiment.
Do you have any ethical hangups about entering an environment where falling out of your favor can leave someone stress-crying in their place of work and/or about their livelihood.
If so, how much money would it take for you to join the system anyway?
How long would you stay in such a system if you found yourself already in one?
Back in the real world, in a business context, it sounds like an abusive workplace and an untenable system. Like, that obviously can't last forever.
Is this your idea of an engineering nirvana? Does engineering happiness have to come at the expense of manager happiness?
A very substantial point actually.
I'm not so sure this is better. I was an individual contributor for over ten years until I became a manager a couple of years ago, so I've seen both sides of this coin. My experience has been that typically engineers aren't interested in understanding all the non-technical things that are necessarily part of the decision making process, or worse think of these things as beneath them, asinine, or "easy". Much of the feedback from engineers is negative, not useful due to an overly narrow focus on specific tech stacks or solutions, or lacking context. Sometimes the context isn't there because of poor management decisions to not be transparent but often it's not there because the engineers' bias results in them not seeking it out. Very few things are black-and-white, and certainly it's better to include engineers' in the decision making process at some level, but that's a two way street--maybe engineers could work a little harder to overcome their own erroneous biases.
Return question: Do you have a firm grasp on quite how much money it is?
I have a very solid network inside google (ex-coworkers from another FAANG job) and also from xooglers, at IC and management track.
Even in my last interview failure (see my post here), the recruiter told me I had more than enough to support my application. Yet, an exec made the no-go call.
Obviously not saying FAANGs are quite that bad, but still, this is a pretty shallow reason to work somewhere.
You're given a problem, there are usually a few clear-cut ways to solve it. You're expected to find an optimal or near optimal solution fairly quickly, and explain your approach clearly. That's it.
I've thought the more open-ended, unstructured interviews lead to more bikeshedding opportunities.
This is a significantly more meritocratic industry than most, and within the industry, the FANGs are relatively more meritocratic than smaller startups.
I'm surprised we're even having this conversation.
1) binary trees for which theres usually a STL
2) some sort of odd string / array manipulation that never comes up in real life
3) some sort of linked list manipulation where again there is an STL for that and/or wouldn’t come up in real life
4) some optimized algorithm that literally took the first person years to discover prims vs kruskals MST for example, but now is expected to “figure out” on the fly.
5) Expects you to solve all these tasks with an insane time pressure that again is not a simulation of real life, it just makes it stressful almost as a rite of passage
- "I'm sure there are managers and engineers crying in private in every big company out there": You're not excusing google here, just expanding the range of companies whose apparent behavior is mortifying a couple of people in this thread.
- "Google probably does some things very well to keep all the talent despite the negative press it gets.": probably. They probably do a lot of a/b testing to dial in the compensation/retention ratio they're looking for, or maybe they just heap rewards onto engineers because they can afford it. Be that as it may, some people think that what google's doing is detrimental to society, or at least the problems are bigger than a salary or even a total compensation package should make up for.
I still think Google stands as an attractive workplace for reasons that are not just compensation and resume boost, though.
Is this referring to how they creepily track people, or are they doing worse things which I’m not aware of?
Years of experience is definitely not a guarantee of competence.
Candidate A: Can recite algos and remembers that Levenshtein distance is the answer.
Candidate B: Has no idea what Levenshtein distance is, writes a brute-force solution with the understanding that it's not an optimal solution. After the interview she spends more time learning what she doesn't know, learns about Levenshtein distance, and sends you an optimal solution via email.
The above is a real-life scenario, so my question to you is - how do you decide who to hire?
Anyway I'd think one might use an array and not some other list/collection.
Who cares? If they write code that's well engineered and works in your product and they rely on auto-complete or whatever, isn't that what your business needs and why they really pay you? Furthermore, said code will be written from a comfy chair while they listen to their favorite music, with access to Google, SO, etc. And they will have enough time to leisurely think about what they're doing, test, refactor, etc.
In contrast, during such an interview, they are hand-writing code under duress for a problem they've had no time to think about while being judged by one or more people staring at them. If you're company is one of those famous ones where they get so many applicants they need to weed out many potentially good people, and also don't care whether they let in crappy people who game this system, then fine, whatever works.
Unless you're giving public demos/performances (which is what an interview is), this skill set isn't nearly the most relevant one for the job.
EDIT: This is a fascinating analysis of this phenomenon from a pilot's perspective: https://youtu.be/BBpqvPujZgM?t=1135
The video is the post-mortem of a plane crash at an air show with the pilot involved. In the part I linked to, he talks about the psychology of a skilled person when put under this kind of pressure and how the quality of their decision making can quickly break down. The whole video is also great if you're interested in aviation.
I know you're talking about software engineers, not data analysts, but:
select from <table> [oops... you're supposed to put an asterisk there]
select <column>, count(field) from <table> [holy shit... I forgot the group by]
select <column>, case when <condition> then <result> else <other> from <table> [oh man, case statements need to be terminated with an `END`]
select <columns>, from <table> [oh no... SQL doesn't like that comma before the from statement]
select <...> from <table1> join <table2> table1.column = table2.column [This is embarrassing, I forgot the `on` keyword]
select <stuff> from <table1> union <stuff> from <table2> [Jesus... I forgot to type `select` after the union]
select <column>, sum(column2) over (partition by column3 between unbounded preceding and current row) as cumulative_sum from <table> [dang, SQL doesn't know which rows if I don't actually mention `ROWS BETWEEN`]
select <column>, count(case when <condition> then 1 else null end) as count from <table> order by count desc having count > 1 [ahh that's silly, you can't put your HAVING clause after the ORDER BY]
with cte_1 as (select <...>), cte_2 as (select <...>) cte_3 as (select <...>) select <columns and aggregations> from cte_1 join cte_2 on <...> left join cte_3 on <...> where <condition> group by <many columns> [Oh my goodness, I forgot a comma after closing cte_2]
Now, perhaps this says more about myself more than anything, but I really do write code comfortably all day, I'm glad my current employer, or any number of the clients I've worked for, haven't had this philosophy (even when watching over my shoulder waiting for results they need at the moment). I'd be mortified if anyone ever dug up some of the atrocious things I've requested of the database in the server logs.
> I know you're talking about software engineers, not data analysts, but:
(inserts self-pwn car crash here)
I've done SQL for ~20 years and I'd say I'm good at it. I don't make as many mistakes as you've described but I know exactly what you mean, and I'd never hold that against you because I don't give a toss about mistakes that the language will catch.
I've rarely interviewed others, but when I did I asked high-level stuff approaches. I wanted to see if they could grasp the solution, not the physical framework.
Actual example: you're given a large collection of words, which you're allowed to pre-process - you have plenty of time to do this. Later on you are given another word, how would you very quickly find all acronymns of that word?
(inerviewee programmer didn't get it, so I tried it on a non-programmer we had around - she very quickly worked out you ordered the letters and saved them - she didn't explain it clearly (to repeat, she wasn't a programmer) but in programmer terms it was a dictionary with keys as the sorted letters and the values as a set of the words).
In this case, would you employ the supposed programmer who didn't get it, or the non-programmer who did?
Actual example: Show me how you'd represent an arithmetic expression using objects, and how you'd evaluate it in an OO style (was after class hierarchy of (op, leftexpr, rightexpr and .eval method. With plenty of time and pushes in the right direction, he still didn't get it despite claiming good OO on his CV)
(True story: to same guy who didn't get the OO expression question, I started off with an SQL question. His CV said SQL was his strong point, so I gave him an easy one: "explain to me what a left outer join does". He shook his head in confusion "Never heard of it". Actually happened! I'm not even exaggerating!)
As a SQL guy who knows Python, but specifically just pandas/seaborn/numpy (matrix/set operations rather than the underlying constructs which make numpy/pandas possible), as opposed to a SWE with OO skills, could you point me in the right direction to learn how this question should be answered?
>"explain to me what a left outer join does". He shook his head in confusion "Never heard of it". Actually happened! I'm not even exaggerating!
I... I don't even know what to say here. That's absurd to me he would claim SQL knowledge and respond with that answer.
My response would be "that is the same as a `left join`" (then I'd explain what a left join was) and follow up with "I exclusively write 'left join' and never 'left outer join' as my experiences with the DB/MS I'm most familiar with (Postgres, Redshift, MySQL, MSSQL and a couple others) accept the `left join` syntax without specifying `outer`".
I'm also not nearly as picky as a compiler/interpreter. I can tell what you're trying to write, and lots of people make silly mistakes. But a high volume of mistakes, or especially difficulty getting anything substantial out at all, those start to make me worry.
[#] If this doesn't seem obvious consider the inverse - worse designs will inevitably require more lines of code to get the same result.
I think that's extremely dependent on context.
I write mostly SQL and bash and would argue that both languages are not conductive to try to reduce size at the cost of future maintenance.
I agree with that. I've had candidates explain certain points of syntax as they worked, or demonstrate their knowledge in other ways, or write their code particularly well or cleanly, and I make sure to mention that positively in my notes. But less-than-flawless syntax by itself isn't a negative for me.
I agree with the main things you look for - I too try to focus on those more than syntax.
Unfortunately, it seems that we are just now starting to realize the human aspects of software eng. Still, even if there could be a massive amount of data to show in which interviews, or more generically, how human judging or predicting personalities/traits/etc are intrinsically flawed
Ok, couldn't find a sample on the web so here's mine. It's not right for brevity and because this is the first python code I've done in ~3 years, so any criticisms welcome. Hopefully can get the formatting right
# super.init omitted for brevity
class Expession: # abstract base class
def eval(): pass
class Literal(Expession):
def __init__(self, val): self.value = val
def eval(self): return self.value
lit1 = Literal(8)
print(lit1.eval()) # prints 8
class UnaryExpr(Expession): pass # base class for unary expressions
class Negate(UnaryExpr):
def __init__(self, expr): self.expression = expr
def eval(self): return - self.expression.eval()
lit2 = Literal(13)
neg = Negate(lit2)
print(neg.eval()) # prints -13
class BinaryExpression: pass # base class for binary expressions
# Note that subclasses Add and Multiply have the same
# __init__ code so I should hoist that into the BinaryExpression
# base class but for clarity I'm leaving it in the subclasses
class Add(BinaryExpression):
def __init__(self, leftExpr, rightExpr):
self.leftExpression = leftExpr
self.rightExpression = rightExpr
def eval(self):
return self.leftExpression.eval() + self.rightExpression.eval()
add2literals = Add(lit1, lit2) # 8 + 13
print(add2literals.eval()) # prints 21
class Multiply(BinaryExpression):
def __init__(self, leftExpr, rightExpr):
self.leftExpression = leftExpr
self.rightExpression = rightExpr
def eval(self): return self.leftExpression.eval() * self.rightExpression.eval()
mult2literals = Multiply(lit1, lit2) # 8 * 13
print(mult2literals.eval()) # prints 104
# now let's make a complex expression, say (7 + 2) * (-4)
# Doing this by hand but a parser would build this from that
# string
expr = Multiply(
Add(Literal(7), Literal(2))
,
Negate(Literal(4)))
print(expr.eval()) # prints -36
Make sense?
Re. the left join, I abbreviated it. Full event was that there was 2 interviewers, me + other guy. I said to our interviewee, "what's a left join?". Cue puzzled expression and headshake. My co-interviewer qualified that for him: "what's a left outer join?", getting the response "never heard of it". He claimed 4 years of sql on his CV. No job for you, matey.
This isn't rare either, worked at a recruitment office and overheard a conversation which recruitment agent used to check applicant wasn't clueless. Applicant was applying for C++ job. Q: "give me 4 STL containers". Applicant replied "cin and cout".
If you've done no C++ that's like asking a python guy "give me some python data structures" and getting back the reply "input() and print()"
Edit: to clarify about the expression eval stuff, I wasn't expecting code, just an obvious grasp of a tree of objects with relevant subtypes, and eval(). He knew roughly how to do it procedurally, but blatantly had no clue on the OO style (which, yes, he claimed to have on his CV).
Incidentally, I'm just starting my very first step into Pandas today. Looks SQL-ish!
That seems pretty likely.
Some people live on their company's computer and when they leave they do not have one.
Yes, I always add "there is a machine set up for you if you do not have one". That said the machine has a generic setup with most common editors but no plugins. But good engineers will probably have a script on a Github Gist or something like that will setup the machine as they want it.
In general, a candidate with their own setup will do better. I think this is one of the reason that big companies do not let people use their computer.
That's exactly how I do it. My goal is to assess the candidate's skills with realistic expectations, a whiteboard is a tool he or she can use, not the goal of my interview. If he can write code on a whiteboard and he doesn't know how to compile a program, it rings a bell.
So get one. You can get a good one from the pawn shop for $200. You can afford that if you're interviewing for a 6 figure job.
Edit: I'm not kidding. I've bought $200 laptops from the thrift store, usually for travel purposes so I don't worry about losing/breaking it.
(Also, that doesn't address the question of getting a working decent setup, if you're not otherwise using it.)
This is the best part of these interviews. The utterly dehumanizing nature of it. You aren't even treated as a person until you've uttered the correct series of phrases that signal you are a member of the right class. Every word that comes out of your mouth, and everything on your resume up until that point is completely disregarded and treated as a lie.
MIT CSAIL is the research lab joining of the legendary MIT AI Lab and MIT Lab for Computer Science. People who work hard and win the lottery to do research at CSAIL (or other prestigious lab) shouldn't afterwards be looking for entry-level coding jobs for which a whiteboard code monkey dance interview/hazing would be appropriate, IMHO.
(For different reasons, people who are in programmer career tracks, with verifiable industry track records and/or open source involvement, also shouldn't be put through the entry-level hazing. Claims that the ritual gives certain companies metrics or somesuch would carry more credibility, had those companies not been caught brazenly colluding, at the CEO level, to systematically suppress wages and mobility of their own employees, with presumed spreading market effects throughout industry.)
If nothing else, Logo? In 2019?
No, but we also don’t need to make up ridiculous lies, especially ones that aren’t particularly funny.
My point is that there is plenty to complain about - unrealistic time pressure, writing on a whiteboard, only testing coding when that is the least interesting part of a senior developer's job, no opportunity to test and debug, etc. - that it isn't necessary to bring up these exaggerated boogeymen about how everyone is asking for novel algorithms on-the-spot.
IMO being able to say “I don’t know the the specifics, but I would use dijkstra’s algorithm on this problem” shouldn’t disqualify you because you couldn't code it.
He said it will compile it and submit report when he gets back to his desk. :/
I also go out of my way, to make it clear that I don't care about every hanging parenthesis, indentation, or typo.
I care about whether or not the candidate asks for clarification, or bulls ahead with assumptions, whether the overall algorithm works, whether the candidate can identify limitations of, and bugs in their solution (Everyone has bugs. Everyone. There's nothing wrong with that.) and what their testing strategy is.
In my experience as both interviewee and interviewer, there is a lot of power struggles involved. Just like any other interaction betweeen engs like code reviews.
So, he's asking you to do something he can't do? Why can't he just read your code and know how it will behave?
I am starting to think that most of those decisions are made by burocrats who have no accountability on the actual results, specially at Google where they can afford to lose great candidates left and right.
I'm too lazy to find my actual code but here's the gist:
C# but might working in Java/etc too *
Create an Image of some size
loop hight of image
loop width of image
Bitmap b = cast Image to bitmap since Image doesn't have the pixel method
get pixel value or whatever looks legit
end
This creates a new bitmap for EVERY pixel in the image. If the image is large enough and the system is 64 bit bad things happen. On Lubuntu this code burned through 8 GB of ram in seconds and was well on its way to eating all the virtual memory before I forcefully shut it off.
Maybe this is a Linux issue but it hard locked my system. I couldn't switch to a different terminal or anything.
> My point is that these are entirely different things.
Entirely? I'm sure that Google employs plenty of fools (as do all large corporations) but to suggest there is no correlation is preposterous on its face.
Imagine if most highly compensating employers made the barrier to entry so absurdly difficult, you would no longer consider looking for new positions every 1-2 years to grab new offers/seek larger raises. Obviously, this isn't sustainable long term but it sure will reduce turnover rates if you can get a small cartel to follow suit.
The only thing I can think of is that the actual bitmap data is not tracked as a managed array by a Bitmap instance, but rather is a pointer or handle from some underlying native library. GC might not kick in then, because it doesn't realize how much memory all those bitmap objects are actually hogging. Now, on .NET, when libraries do that kind of thing, they're supposed to use GC.Add/RemoveMemoryPressure to let it know. But perhaps the library that you were using didn't?
I have also never received any negative feedback from hiring committees or managers about how I conduct my interviews, what I focus on, or how I analyse candidate performance.
I guess this depends on how you run the interview but one of the things that frustrates me about whiteboard interviews that focus on the coding rather than the design is that I have to step through test cases (especially edge cases) like this manually, which is tedious and not at all how you do things in real life, where you just run the test cases and see what happens instead of having to run your own code on a whiteboard.
I agree with stepping through code being lame. If a candidate has tried to do some sort of boundary condition check and mentions a test that'd catch it, then I'll give them a pass. If a candidate just blows past the code without any attempt whatsoever to check that they're in bounds on an array, then I'll ding them for that. You have no idea how often I see code like...
Node neighbor = data[x+1][y];
The infinite loop in my question is fairly obvious (because it involves walking around a data structure iteratively). Candidates either see it right away and handle it as they solve, notice it halfway through and crowbar it awkwardly in, or don't notice it until asked to walk through a specific test case, or don't even notice it while walking through the test case.
Ultimately, if the code looks correct to me, or even close (I mess up occasionally) then I'll just ask what cases they would test.
Node neighbor = data[x+1][y];
Learning to write code on paper for exams and on white boards for interviews actually improved my skills a lot. Maybe not everyone coded like I did, "against constraints", but having to slow down and take into account the constraints mentally led to making better code.
This piqued my curiosity. Can you give an example?
And most recently, when iterating over a string's characters the underlying string methods KNOW that the string is being iterated and will pick up at the current iteration point. For example, you've got the string "5432112345". And via iteration, you're currently pointing at the first "2" at index 3. The candidate asserted that if you call "indexOf('2')", it would return 6 because "indexOf" knows that it is iterating and should start 1 beyond where it is pointing at.
And my favorite - once had a candidate that misspelled a function name while coding in Ruby. I didn't ding them for it. But I pointed it out because it just bugged me. And the candidate then swore to me that Ruby will automatically call the correct method if there was only 1 candidate based on the misspelling. You know when you do things like "git inti" and it says "did you mean init?". The candidate swore that Ruby would just call "init" for you because it knew what you wanted.
Ruby 2.3 and later ships with this gem and it will automatically be required when a Ruby process starts up. No special setup is required.
I was relatively new to programming and had been practicing in Java but didn't know how to execute a lot of map/filter/reduce operations off the top of my head like that. I did, however, know that my interviewer was a Python programmer that probably didn't know much about Java language features.
I think most decent interviews will give you a pass on an enhanced standard library.
public isTheFooBarred(class Node { int[][] positions, int size } node, int x, int y, Set visited = new HashSet(node.size)) {
// ...
}
I really tried to give the candidate the benefit of the doubt, and asked if there was some sort of annotation processor or code pre-processor that they were using, but they were adamant that it was plain old vanilla Java. I'm pretty sure that they were using some in-house built thing, but their solution had significant problems, so it wasn't the only reason I was against the hire.
The question asked was a very short multiple choice; only two of the answers were possible under immutability.
When I interviewed for my current job using Java, I had been programming in Ruby and JS for the better part of a decade and had to refresh my Java syntax fairly quickly. I know I made some dumb syntax mistakes in my phone interview, like instantiating collections totally incorrectly. I distinctly remember one of my in-person interviewers saying "well, in Java it's boolean, not bool, but sure...". More semantically, I may very well have messed up mutability of collections and primitive conversions and boxing and such.
Enough of my interviewers saw through all of this that I got the job. Now people on my team come to me and say, "hey you're a java guy right?" and ask me questions about this stuff. I wasn't a java expert when I interviewed, but now I am, because that's what my job required, so I learned it. That's what my interviewers were looking for, to the company's benefit.
Why does this even matter? They're writing the code on a whiteboard, without being able to compile or debug, in 20 minutes. Does Google really expect code to be correct and production ready in 20 minutes?
In the end, we did end up making an offer to this candidate. They did well on everything we asked them. This was the only "brain fart" they had.
BTW, they still got hired and proceeded to be a solid productivity reducer and all round waste of time.