[matmann2001]

This is getting ridiculous. These guides to interviewing at specific companies are starting to sound like the video game cheat code books of old.

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.

[ChrisCinelli]

I completely agree.

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".

[maxheadroom]

>Bring your own laptop set up to be able to code and debug

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.

[otabdeveloper2]

> This is clearly a useless skill as a software engineers except in getting a job at companies that do whiteboard interviews.

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.)

[int_19h]

I have been on the other end of the process more than once, in different companies and countries, and I have literally never seen anything like that.

[retiredcoder]

Me neither. Quite common deal breaker I seen is mismatch of expectations (e.g.: candidates applying for senior positions with experience to lead bigger projects, etc) but never seen gross incompetence like that (so that I am not even sure if GP is being literal or not).

[ereyes01]

> (They'll write crap like "()f" or "f()a" when they want to call a function, stuff like that.)

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.

[travbrack]

I think the function syntax thing is one of those things that's so basic that someone who gets that wrong probably doesn't code very much.

[ereyes01]

If you put someone in a fight vs. flight situation, and add in the task saturation of the coding interview, a competent person can react adversely and make basic mistakes. A week ago in a conference, I watched an SRE who I knew was very competent have a panic attack when a demo didn't work as expected. I never learned what exactly happened, but apparently it was simple enough that a colleague was able to quickly fix the problem over their shoulder.

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.

[retiredcoder]

Quite interesting.

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

[oblio]

To make it worse it's actually fight or flight or freeze and freeze is actually the most common reaction...

[mk89]

I frankly still don't understand what's the expectation of such whiteboard exercises. It's just one method, and companies have to understand that one day maybe it will be superseded, hopefully soon. This "we have always done it that way" is ridiculous. If you want to know how good a candidate is, you can easily do it with pertinent questions and maybe a couple of pair programming exercises to see how the person codes, how he/she structures the code in a comfortable situation, not under stress and in an unrealistic scenario -> coding on a whiteboard, as if we had no electricity. Whiteboards should be a tool, not the goal of an interview.

[bitL]

Elite schools do that in undergrad; e.g. as an initial scored lab exercise, write this recursive fractal shape using Logo, parallel Delaunay triangulation with prefix sums , dynamic programming solving oligopoly problem or single-value Paxos pseudocode on a piece of paper in 10 minutes (I am being serious). If you can cope with it, it immediately shows up in the interview and you are considered a member of the club, a person worthy of having conversations with.

[aphextron]

>f you can cope with it, it immediately shows up in the interview and you are considered a member of the club, a person worthy of having conversations with.

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.

[peter_l_downs]

Which elite schools? I went to MIT and didn’t have to do any of this.

[chollida1]

https://courses.csail.mit.edu/iap/interview/materials.php

[neilv]

Just to add context: MIT Interim Activities Period (IAP) is a "winter break" few weeks in which anyone can lead classes/sessions on any topic: http://web.mit.edu/iap/about/index.html

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.)

[Dangeranger]

The course you linked to doesn’t cover any of the algorithms mentioned in the grandparent. It does however cover about three dozen common interview questions. The course is also from 2009.

[MRD85]

That seems really easy for MIT. I'm towards the end of my 2nd year at a regional university in Australia and nothing there seemed that bad.

[marquis-chacha]

That's a student taught class. Not really policy-defining.

[natalyarostova]

It's a Caltech and Stanford thing. MIT isn't really elite.

[fenomas]

Oh not in Utica, it's more of an Albany expression.

[natalyarostova]

I see.

[jjoonathan]

Sure.

[mattkrause]

I’m having a hard time believing this is true....

If nothing else, Logo? In 2019?

[tamrix]

Hackernews has its own instagram reality to it.

[bitL]

I think the term "Logo" stands on a perfect abstraction level that in reality could have meant "using turtle.py you programmed last week with turn, move etc. commands", don't you think? Do we need to be super-precise down to minutiae when discussing informal stuff? Moreover, it's on paper, so who cares what syntax is the pseudocode, it could be even Logo itself.

[mattkrause]

> Do we need to be super-precise down to minutiae?

No, but we also don’t need to make up ridiculous lies, especially ones that aren’t particularly funny.

[bitL]

Alright then. Believe as you wish.

[buckhx]

Course numbers or it didn't happen

[geofft]

I agree with your comment in general, but, I worry about the bias of "Bring your own laptop set up to be able to code and debug" - some perfectly qualified candidates don't have laptops. Some perfectly qualified candidates do have a laptop but don't code much at home, and the setup they're used to is their work machine or a school lab computer. We already have too much bias in favor of code-all-day-code-all-night candidates (e.g., looking for GitHub profiles) and I think requiring someone to bring their workspace might push this to the point where good candidates who happen not to code outside business hours wouldn't stand a chance. (There are lots of reasons for this that wouldn't impact how qualified you are, from "I have a family" to "My workplace is real stingy about open source, so I haven't bothered to set anything up for non-work coding".)

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.)

[ChrisCinelli]

I did not write it for brevity.

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.

[geofft]

Yes, I figured you probably had a provision, just wanted to ask for the sake of people saying "This sounds like a good idea." I agree people with their own setup will have an edge, and that seems like a downside that you could argue is defensible. I just think that saying you have to have your own setup because we know people without their own setups won't pass is too far.

[mk89]

> I'd be a lot more comfortable with "We have a machine set up for you, but you can also bring your laptop,"

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.

[skookumchuck]

> some perfectly qualified candidates don't have laptops

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.

[ilikehurdles]

When I was looking for work, my laptops setup was embarrassing. MacBook Pro with both a broken keyboard and misbehaving trackpad. I had to bring with me an external mechanical keyboard and trackpad. It worked out in the end but that could leave a bad impression with interviewers.

[skookumchuck]

It wouldn't bother me any. I'd just think you were thrifty, and were capable of working around problems to get things done.

[cellularmitosis]

Indeed, seeing a candidate bring a $250 ebay thinkpad running linux would impress me and be great ice breaker

[geofft]

How do you afford $200 if you're interviewing for a six-figure job but don't yet have a six-figure job? Personal loan?

(Also, that doesn't address the question of getting a working decent setup, if you're not otherwise using it.)

[skookumchuck]

If I need to advise someone how to come up with $200, he isn't capable of a 6 figure job. If I have to hold someone's hand to set up programming tools on a laptop, he isn't capable of a 6 figure programming job.

[geofft]

Interesting - why is that? Have you hired such people and found them incapable of doing the work?

[seanmcdirmid]

I’ve heard that Google allows you to type code into a computer now during an interview. A welcome improvement in the state of the art.

Still no access to a compiler or debugger, but baby steps.

[dominotw]

I had to write code exclusively on white board last month. Only laptop in the room was interviewers which he was using it exclusively to furiously copy the code i was writing in the whiteboard.

He said it will compile it and submit report when he gets back to his desk. :/

[vkou]

I've done nearly 100 interviews at Google, at least half of them with me copying code from a whiteboard, and I have never tried to compile a line of code that a candidate wrote.

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.

[retiredcoder]

I have to ask this, do you see yourself as the norm at Google throughout your whole employment time there?

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.

[dominotw]

OK so of the 5 interviewers, 2 did this. Others seem to not care. Do you know if "must compile" is a google wide rule that some interviewers just ignore?

[vkou]

I have personally never heard of 'must compile'.

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.

[defen]

> He said it will compile it and submit report when he gets back to his desk. :/

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?

[piyush_soni]

Same happens at Amazon. They want syntactically correct program that will actually compile and run on a compiler, but to verify that they click a photo of what you've written on the whiteboard to actually try that on the computer themselves. :|

[retiredcoder]

Someone above him might have decided that’s part of the process.

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.

[Frost1x]

This process is very well designed to put all the cards in the employers hands.

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.

[tyingq]

Sounds like a great opportunity to whiteboard an exploit instead.

[keanebean86]

I'm a moron and did something stupid not too long ago that would be perfect for this.

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

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.

[int_19h]

I'm curious why this worked like that, since GC should consider all those bitmaps orphaned at the end of every loop iteration (possibly as soon as you get the pixel even, since that reference is no longer used). The GC might not run for a while, but it should certainly run long before the entire system starts swapping...

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?

[estomagordo]

Can confirm. I interviewed last September and was given the choice between laptop and whiteboard. Picked laptop. It seemed this element was new to most interviewers at that time.

[cliffwarden]

I wish more interviewers were like this

[doctorpangloss]

I'm totally sympathetic to how stupid these interviews feel.

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.

[dilyevsky]

Google used to run “how to interview with Google” multiple day bootcamps where they’d train you to pass its interviews. I’ve gotten couple of those candidates and thought it was just ridiculous.

[retiredcoder]

I think it is sad, it comes from your own employer (I understand you work for Google, correctly if I am wrong).

[dilyevsky]

Not for a couple years now. Don’t know if they kept this program, I personally noticed only superficial improvement.

[ummonk]

Or it means the process is well defined enough that you can create a level field by telling everyone how it works through guides like this instead of giving connected people a leg up due to inside knowledge of a poorly defined process.

[doctorpangloss]

I can guarantee you that more than 90% of people working in highly compensated positions at the world's most famous corporations have had a lot of "leg up" benefits in their lives.

[ummonk]

Leg ups that have helped them become better at software engineering? Sure. Leg ups in the form of insider connections / elites? Less so, particularly for talent they're hiring today.

This is a significantly more meritocratic industry than most, and within the industry, the FANGs are relatively more meritocratic than smaller startups.

[Techonomicon]

Meritocratic in the most boring uninteresting sense of the term where you literally only work on things in a way which Google tells you will help advance you up their ladders while not actually working on anything in a way you would find interesting in general.

[YjSe2GMQ]

Yup. It's in th same spirit as SATs - people also practice for that.

[emmelaich]

On the contrary; the fact that Google recommends them indicates the process is not flawed.

That is too say, their interviewing process explores things at sufficient depth and breadth to make knowing "the" solution not a deciding factor.

[Gracana]

Maybe the sort of person who has the time/desire/interest to study a guide to figure out how to fit in at google is exactly the sort of person they want to hire.

[djakjxnanjak]

Yeah, I don’t think my whiteboarding skills are particularly useful at work, but the personality type that makes me obsessively practice whiteboarding for weeks before a job interview tour also makes me effective at work.

[0x8BADF00D]

The bikeshedding engineer is exactly what Google or Amazon is looking for. Nothing wrong with that either, I just take issue with the entire industry standardizing around that type of engineer.

[freyr]

My impression was the opposite.

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.

[tehsauce]

Sounds pretty accurate

[lallysingh]

Well, the (in house) recruiters recommend them. The engineering staff that does the interviewing generally don't get involved in this recommendations.

[BurningFrog]

The recruiter gets paid if/when they push someone through to get hired, which is a very different incentive from what the hiring engineers have.

[tamrix]

The real test is how badly you want the job.

[strikelaserclaw]

learn with the intent to become a better engineer, even if you don't hit the google mark (which is arbitrary anyway), you will become a better engineer. That is the philosophy most people should use when trying to aim for these companies. Don't cram, learn.

[ahelwer]

I disagree. Doing competitive-style programming and learning all sorts of weird algorithms has not made me a better engineer. I can count on one hand the number of times in my career that I have had to design or use an "interesting" algorithm - and no, not in the "not knowing what you don't know" sense where I could have used one if only I'd known about it.

[sanderjd]

I'm very critical of this approach to interviewing in general, but it also isn't the same as competitive programming and it isn't focused on "interesting" algorithms. It is far more focused on understanding how to use data structures and the trade offs between them. Chapter 3 of "The Algorithm Design Manual" (which is fittingly titled "Data Structures") is really the most useful reference for the majority of these interviews. I don't think this is the most useful thing for software developers to be good at, but it's definitely useful and worth learning. I was annoyed that I had to study for one of these interviews, but ended up being pleased that it forced me to review this material.

[blackflame7000]

Most algorithms focus on:

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

[sanderjd]

None of that rings true to me. Like I said, I really dislike the way we do interviews, but I find this to all be exaggerated to the point that it weakens your argument.

[int_19h]

I think the point is that you don't need to understand the gory details of how e.g. your hashtable works - for most coders, it's sufficient to know that it exists in the standard library; it's O(n) on space; it's amortized O(1) on retrievals and updates, but can be O(n) on some inputs; and that there is a class of security issues related to using untrusted data as keys. They don't really need to know why all these things are true, or know how to implement it from scratch.

[dominotw]

I think this might be better mindset to approach it, instead of pure will power. correct or not.

[dominotw]

I had a coderpad facebook phone screen last week, interviewer said " that code the won't compile, can you see why?" .. It was missing a semicolon.

on a related note, I write scala on daily basis but scala is not that well suited for coding interviews, I found.

[jammygit]

Facebook likes their interview nonsense, but stores passwords in plaintext. I think the credibility of the system is in question

[jensvdh]

They didn't store pw in plain text. Pw were accidentally captured in logs and those logs were stored in an internal DB. This happens often.

[chopin]

That's storing passwords in plain text. "Happens often" is no valid excuse, on the contrary. If it happens often you should know about it if you are a qualified engineer.

[sk5t]

That's because Scala doesn't have nearly enough semicolons.

Kidding aside, why do you feel Scala is unsuited to coding interviews, assuming the interviewer well-understands the language?

[dominotw]

hard to write heap sort in functional style with immutable collections. I guess you could write imperative style code.

[sk5t]

Well, ah... unless you're applying at Amalgamated SortCo Industries, asking for on-the-spot sorting implementation is pretty high on the list of absurd interview questions.

Anyway I'd think one might use an array and not some other list/collection.

[bm1362]

I used clojure once during an interview and bombed, passed again 2 years later at the same company with Python. Would’ve made a big difference in my equity had I just started then!

[dominotw]

Yea functional langs just get in the way during interviews. I can write same imperative code i write in java in scala but it just makes it harder( eg: remember to use var instead of val, mutable collections vs default mutable ect) at which point I am just better off practicing for interviews in java.