For anyone who missed this piece of gold from the comments:
> The William Gibson version would begin thusly:
> It was hot, the night I burned the Seeker. Moths batted themselves to death against the humming neon signs just outside the single window in the cramped room. There were ancient electronics piled to the ceiling in here, hot new chipsets from Taiwan still unwrapped distributed unevenly amongst them.
> The Seeker put his hands on his hips, brushing aside the corners of his Sukajan jacket bomber jacket replica. "I heard you and Bobby were hotshots, once. Real.. artístes", he said, the last word paired with a smug grin. "Heard you could do things."
> "Things like what?" It's been 20 seconds and you've already wasted too many cycles with this guy.
> "Things like making lists, just, fold up inside themselves. Come out the other way around. Crazy things."
> You grit your teeth. The dex has left your system and you're starting to feel a massive drug deficiency coming on. "Crazy things cost money", you manage. The lists already unfurling in your head, you start typing as quickly as you can to hide the microtremors.
> After the candidate took his leave the interviewer being bombarded with questions by the holders of steak stared out from inside the bustling warehouse wondering if he would ever truly understand what a list really is.
I just wish someday I could write like this. Beautiful.
This is beautiful. It captures the spirit of wizardry and wonder that brought me to programming in the first place, juxtaposed against the reality of interviewing at "top" tech companies where the interviewers more often than not have only a fraction of my experience, and seem to have followed the type of curated success-seeking golden path that used to be reserved for finance.
> and seem to have followed the type of curated success-seeking golden path that used to be reserved for finance.
Finance cares that you have past proven experiences in finance and they'll hire you for it.
Breaking into finance is the hardest thing to do, once you're in, you're good and you can have a great career.
Tech companies don't care what you've done and they rarely, if ever, ask about it.
Breaking into tech companies is only about rehearsing Cracking the code interviews, and once you're in, you have no guarantee to make any sort of career. You'll probably be out soon because things move too fast and the turnover is insane. Your next job is gonna be difficult to find because the next tech company won't care about experience and will try to pay you with free food.
> Breaking into tech companies is only about rehearsing Cracking the code interviews, and once you're in, you have no guarantee to make any sort of career. You'll probably be out soon because things move too fast and the turnover is insane. Your next job is gonna be difficult to find because the next tech company won't care about experience
As someone who's worked as a software engineer in the bay area in tech companies this is 100% not my experience at all. Though tech interview definitely matters, experience also matters and the turnover is not insane. All of my coworkers who I have made friends with are still in this business and I've worked at a few different places. I just don't think you have any idea of what you're talking about.
> you have no guarantee to make any sort of career.
I'm not sure where you've interviewed but everywhere I've worked we always ask what you've done, and at my current company we have no whiteboard interviews. Tech is learning, slowly, how to give proper interviews.
I suppose asking about the applicant's past experience isn't the kind of thing that "scales" in some organizations, because then you've gone from a double blind experimental procedure to a freewheeling conversation between individual humans.
As someone at a major tech company that is routinely involved in interview loops, I spend at a minimum 25-30 of the 55 minutes I have asking about specific items on the candidate's CV. When white-boarding, I'm interested in two things: a) can they actually write code, and b) how well do they ask questions and collaborate with me when working through the problem.
That said, having gone through loops from the other side, I know this isn't always the case and that your mileage may vary.
Well, shit. I had a whiteboard interview earlier and I was silent while working through the problems. I had a lot things going on in my mind but hadn't taken the time to verbalize them at all.
If the only thing the interviewer has to judge your skill on is what you wrote on the board, that's what will be used. When I'm interviewing, I'm trying to gauge how they approach a problem, how well they can reason through a solution, whether they see the assumptions they're making and the impact those have on the solution, what the limitations are of the algorithm they came up with, etc. It's really hard to see most of this if the candidate doesn't talk at all.
> Breaking into tech companies is only about rehearsing Cracking the code interviews
Actually, all of the jobs I've had have cared very much about past experience and have asked about it in the interview. If I weren't actively contributing in certain open source projects, and hadn't worked with certain technologies, I wouldn't be where I am.
For getting a job at Google/Facebook/Amazon/X cool startup, it's a lot more important to do some narrow-minded rote-memorization of algorithms and data structures and hone the skills talked about in a small set of books like Cracking the Coding Interview than to learn something really interesting, or become good at a certain thing, or build some cool shit.
Most interviewers aren't really interested in figuring out "is it worthwhile that you built this thing / did you do it right / why do you think this was something worth learning?" when it's so much easier to evaluate your whiteboard code on a narrow problem against some ideal standard solution.
You can tell them about how you were able to learn enough about a particular database in a couple weeks to be able to cut 90% of the runtime out of a hot query in your first few months at a job, since that was an area that wasn't scaling well and it was something your boss asked if you could take a look at, and they'll be like "ok that's nice, now implement a trie." What's the point of even having experience building and running real systems if that's the process?
If you'd rather be building than practicing whiteboard questions, your best path to success is probably going to be a less predictable one where you need to come across one of the right companies willing to work harder at interviewing because they have to find the best candidates who fall through the cracks at the places with the name recognition.
That is one case. I've specifically hired somebody before who was so/so in the interviews but was the main contributor to a wonderfully written open source project. And was and is a great developer and great hire.
So there is a conflicting case.
No company is going to be perfect at hiring just the same way as no person is going to perfectly crush every interview. But there is no world where having contributed quality code to an open source project will hurt your chances.
There isn't data available on the general case, of course. But data from personal experience indicates: (1) many companies -- I'd say at least half of 'em-- still never look at portfolio code† (which -- even it's just a small personal project or two -- should provide plenty of conversational material for a perfectly decent and rigorous phone screen), or (2) if they do give you a take-home, they never attempt to use that as discussion fodder, either.††
Instead it's usually "Huh, you seem like you just might not be a complete dullard. Would you mind proving it to us by taking this 3-hour HackerRank test? 'Coz we know you've got nothing but time. And you'll go through just about any number of hoops to get us to pay attention to you."
† Even the ones who ask for it.
†† Even when we patiently and politely point out the gaps and ambiguities, sometimes quite glaring, in their cute little "challenge" problems. Which, again, many to occur in at least around half of these exercises.
Are you still hiring by any chance? I am looking for a new gig and I have bunch of open source work but no one is actually looking at it all, one interviewer even admitted 'oh we don't look at that much, maybe towards the end'. Even though they asked for it in their hiring page.
You are definitely an exception.
Would be interesting to see which companies actually look at your github profile like they claim they do.
I'm not involved in any package manager development, but this strikes me as extremely arrogant. Successful package managers are most definitely not a dime a dozen, and the skills required to make one and maintain it over years are something which the majority of engineers at Google (or anywhere) do not possess. There's a lot more to software engineering than working on the hardest of the hard tech problems, and being very successful on the social side is a huge asset that no company should discount based on the theoretical difficulty of the problem being solved.
Yeah right. Most developers wouldn't be able to even start writing a package manager, let alone maintain it for years as it becomes the most used one for a particular platform.
While that was true 10 years ago; I don't think it still holds. Google is more big generic enterprise now with all trouble innovating that comes with that. Hence, why they must buy to be able to push innovation forward. This is just part of the natural life cycle of a company as it gets big and successful.
That's why the interviewer needs to be competent enough to be able to sniff out BS. Falling back on algorithm questions instead is a form of laziness. That's what the "curated golden path" comment is all about - there's a known standard way to get a job at one of these companies, and following it is not a very intellectually interesting exercise.
It doesn't sound like you fully disagree, because writing OSS isn't that curated path, but sadly none of the devs I know who focus heavily on algorithmic whiteboard question performance look at open source projects. And they could justify this with the same one you give: people lie, people copy/paste code...
I've pushed my team quite a bit away from where they were when they hired me in terms of whiteboarding focus, and we're better able to hire senior candidates now than they were back then. The BS detection is a big part of this: ok, you were on a team that did [really cool sounding thing]. What part of it did you do? What specifically did you learn from it? Even in aggressively paced interviewer loops you probably have at least 45 minutes to get them to answer those questions, if they're ducking and dodging, or answer back with wrong information, or with stuff that makes it clear they used the wrong tool for the job and didn't know how to find the right one, then there you go.
It's easy to present code, but it's also easy to copy or memorize code. Some of the most impressive candidates I've seen are the ones where the "let me ask you this stuff about your past experience" discussion expands to fill the whole time slot and we never actually look at any code, because we're too busy talking about how you took a service from a single database to a multi-master geo-distributed easy-failover alerted and monitored system, or how your random side project to look for Hidden Markov Models in baseball player's batting results went (how'd you store the data? what libraries did you use? did you implement your own versions of algorithms? what made it hard to draw conclusions? etc).
> ok, you were on a team that did [really cool sounding thing]. What part of it did you do? What specifically did you learn from it?
Exactly this.
The memorable example for me was someone that worked on a military helicopter training simulator, and specifically, they worked on connecting the physical radios (used for internal communications between the crew) to the simulator. Sounds cool, involved network experience that was entirely applicable to what we were hiring for, and personally, I have a fascination with and have done a lot of interfacing of physical human-interface hardware to software.
However, the candidate was unable to explain details. What type of I/O hardware was used? Did you have to poll or did it push/stream changes? Did you run into anything weird with bad signals or missed state changes or restarts that posed a big challenge? No answers to this, because apparently they "just worked on the protocol".. but then couldn't remember anything about the details of the protocol (HTTP or something custom? Text-based or binary? TCP or UDP?). It was frustrating, because I remember otherwise liking this person.
They had similar responses for their most recent job (that they were at literally a few weeks prior).
I have a terrible memory, but even I can remember some of the biggest challenge highlights of my career. If I start talking about them, especially when asked probing questions, I will remember all the little details and could go on for hours.
I don't get it. Were they just coasting in the background, not really contributing anything meaningful, doing just enough to not be fired? Did the interview make them so anxious that they literally couldn't remember any details (it didn't seem that way)? Were they outright lying about what they did?
There's a trap that some small subset of seniors fall into where there's a lot of projects going on and their role becomes to play architect, provided minimal directions and manage expectations. Nobody tells them they're a manager and everyone thinks they're responsible for the development work that gets completed. Nobody else wants to manage the developers (the good ones ask tough questions about spec. they're "hard to manage"), but nobody respects this guy enough to treat him like a real manager.
(S)he spends so much time playing translator that there's no time to sweat the details. That falls to the team.
Exactly. Making a good hire is a management skill. Is it acceptable for managers to measure the productivity of their team by counting the # of line of code the team produce? or # of bugs the team fix? If not, why is whiteboarding with algorithm questions acceptable?
Eh, I disagree. A good interviewer can dig into past experiences and pretty quickly get a sense of a candidate. Interviewing is a skill that can be acquired and developed.
Problem is, the skills you need to be a good interviewer don't necessarily overlap so well with the skill set of a good software engineer. It's much easier to get people to ask about what they know, irrespective of whether or not that will be an accurate indicator of technical skill.
For most software engineering jobs, the implementation of tries and whatnot is completely divorced from the actual day-to-day work, work that's generally on a much higher level of abstraction to the interview questions. It's the equivalent of interviewing a chemist based on his knowledge of physics.
If you're a Google or HFT firm working on massive scale or optimizing super low latency systems, sure it very well may be critical knowledge. If you're some random company with a CRUD app, this kind of hiring process isn't going to optimize for the most qualified candidates for the job.
> If you are a good developer who sucks at whiteboard interviews, write open source code that everybody can see.
Not good enough for me. My engineers need to be able to collaborate with customers, management, and each other. They need to come up with ideas and explain them, advocate for their ideas. They need to be able to think, code, and collaborate.
Writing code is the easiest part of software engineering. In the environment I work, our engineers can't sit in isolation and submit pull requests. So while open source contributions are nice, being able to interview successfully is still required.
I completely agree that this is sometimes the case.
The hardest project I've worked on so far was a CubeSat project where I had to collaborate with Electrical/Computer and Mechanical engineers with specialized knowledge (orbital mechanics, the design of the custom boards, etc.) to develop the software. I had to communicate why certain hardware elements are absolutely needed in their design, why certain elements of the Attitude Determination and Control System need to be optimized, and so on. As well as why we needed many of software engineerings best practices, which when you step back and look at them from the outside some do seem fairly odd.
But on the other hand, it is not always needed. Also, I'm confident I could prove my capability without a whiteboard because I could probably talk about the problems and collaboration to resolve them on that project for well over 30 minutes.
Have you tried it? You might be surprised at how easy to tell when someone is lying, once you learn to ask the right follow-up questions. It's difficult to fabricate experience for an entire 8 hour interview loop.
Err.. I'm not a prolific developer or something, but most of my interviewers refuse/don't look at the github profile links I put in my resume. Instead they want me to spend time on whatever custom problem they've pre-decided and solve it (and worse not put it public..duh..)
I'm not saying you have to write open source code on your own time.
I'm saying that you can't complain that an interview doesn't show you are good coder if there is no other way for somebody to look at a project you've done.
Saying you did X/Y/Z at your last company but can't share the code since it belongs to them isn't a valid excuse for why you have no code out in the world to show off.
Maybe in California, where contract terms around owning your products outside work aren't honored, but in most of the rest of the US and the world, this is still a valid excuse.
Can't exactly contribute to open source if my contract says my employer owns everything that I do, and even if you think that can get tossed out, you'd better have a good legal fund.
Yeah, you do. You can't rely on your employer to continuously retrain you through your whole career. Show me an engineer with 10+ years of experience who refuses to ever learn anything away from work, and I'll show you somebody working on old tech.
"Can't be standardized" is something of a red-herring, as I've encountered a huge variety in how even algorithmic questions are presented and judged.
[More] prone to biases and opinions? Let's assume this is true (I'm not convinced that it's such a slam dunk - someone who wants to say no to a candidate can find a way, especially if they aren't being shadowed or recorded (which would feel pretty draconian for the interviewee too)). Isn't it still just a way of making a lazy complaint, "but that's harder!" You as hiring manager are responsible for knowing yourself, knowing your interviewers, knowing their strengths and weaknesses, and knowing your own.
That makes it hard to assembly-line interview fresh graduates, but maybe you should have a separate process there anyway because they won't have much in the way of useful experience yet anyway.
I met a young guy at the hotel diner where I was staying for google interview( there were like 50 of us in that hotel). He told me he has been practising algorithm questions on a whiteboard every day for past 4 months for tech interviews. He had a degree from a top school ( don't remember which one ), did an internship at some other top tech company in the valley. needless to say, that didn't help my confidence in the interview that morning :D.
I don't understand people who don't do prep for interviews. I'm a self-taught software engineer with a mostly irrelevant degree but I for sure work through practice problems before interviews and I've had success with some of the "big 5" or whatever they're called. If I hadn't done the practice, I doubt I would have had any success at all.
It's a bit of a slog but it's not that hard if you're motivated to get a new job. My girlfriend has gone back to school for nursing and she works a shit load harder than me all the time, while I just do a month or so of ~ten hours a week of prep for every round of interviews I do.
unless you're interviewing at one of the big companies with a known interview process, you'd basically be wasting your time.
I've done hundreds of tech interviews over my career, and especially in recent years (now that companies are trying new things), it's completely random.
Some will do "Cracking the coding interview" type shit, some will do code reviews, some will give you a take home thing you have to present, some will do pair coding. Some do algorithms only, some do design discussions only, and so on and so forth.
So any prep I do will be a shot in the dark and 99% of the time I'll have to do something I did not prep for. So I don't bother trying.
Notable exception is my current job, which is a big tech co with a semi well known interview process (not as infamous as google or facebook, but still), and they gave me a fair amount of info up front. I also -really really really- wanted to work there because the team I wanted to work for did things no one else does. So i bit the bullet and studied/practice.
That was literally the first time (and probably last) time I did.
I guess I just think of it as limbering up the brain, even if what I "studied" isn't directly useful. I'm going to be a lot more effective at basically all the things you mentioned if I've been solving tricky problems in my spare time for a few weeks.
I totally agree that it's a shot in the dark, though.
Just out of curiosity, are you relatively young? Memorizing the same material for four months every time you switch jobs gets tedious after a 15 year long career.
I've been in the industry for about 10 years. Like I said, it's more about limbering up my brain. I have a good time with it, and usually learn some new things. Memorization is pointless, so I try to solve new and interesting problems rather than re-implementing the same old data structures and algorithms every time.
To be sure, some people take it too far. The "four months" figure does not come from me.
In my life I have interviewed at Amazon, Facebook, Google, 1Energy, and Redfin. 100% of them did standard coding interviews, including the last two. Claiming that preparing for whitebord algorithms interviews is a waste of time outside the big N is a gross exaggeration at best.
> Some will do "Cracking the coding interview" type shit, some will do code reviews, some will give you a take home thing you have to present, some will do pair coding. Some do algorithms only, some do design discussions only, and so on and so forth.
"Cracking the Coding Interview" and algorithms are the only things you mention that you don't spend all day doing at your day job. Spending time studying algorithm questions will be hugely beneficial for some interviews. For others, they'll quiz you on stuff you (should) already know.
It makes complete sense for your first job and when you're unemployed, but as someone with a couple jobs under his belt already, I have no interest in interview prep anymore unless it's relevant to my work and there's a clear ROI.
The way I see it, no experienced candidate should have to do "interview prep" because the work that he/she does on the job should be more relevant to his/her ability to do the job than any form of interview prep.
To make an extreme example, John Carmack's work time is probably better allocated actually doing work than brushing up on "Cracking the Coding Interview" problems. In an ideal world a software engineer's candidacy for a job would be based strictly on his ability to do the job, not academic trivia questions.
This got me thinking. Since John Carmack is a person we can probably all agree is a talented programmer and all round smart guy ... I'm curious how he would fare if he was handed a standard set of Google/FB interview questions
I have a hard enough time trying to fit my own personal projects into my schedule, much less doing mind numbing memorization. It's funny that unless you teach CS, none of our jobs actually prepare for an interview.
I used to think so, but I've found that small amounts of memorization alongside actually working with topics is so much more effective that I have started doing it outside of interview crams - such as when I am trying to get to grips with a new library's API.
It's really at the point where you need to prepare/review for the technical interviews at most companies. If people are going to review coding interview questions/books/strategy then to compete we'll have to do the same.
I myself have been working through cracking the coding interview in an attempt to migrate from upstate new york to the bay area. Maybe I wouldn't bother with positions that demanded white boarding if I already had a position over there and could be selective but maybe not. It kind of feels like it's all part of the game at this point.
Good for you. If you want to work at the circus, you've gotta jump through some hoops. It's true that for most jobs, most day-to-day work doesn't involve knowing standard algorithms and data structures. But being willing to crack open a book and learn something new shows you're willing to prepare when it counts, and that you're capable of learning. Plus you get to learn some cool things along the way, some of which may even be useful some day!
Accepted criticism. At times I wonder if it's worth it or not but I think the preparation is warranted considering how I have to just kind of commit to this whole thing if I play on moving cross country with my fiancee.
Thank you. I wish to someday walk into an interview and pull out Clojure as my language of choice and write every bit of code they ask me to as a pure function - and then look into the interviewer's eyes and try to decipher if they had seen the eternal light of Lisp yet.
I did an on-site this past Monday. They allowed me to code the homework in whatever I wanted. I used Haskell. We code-reviewed it in Haskell, with a guy there who knows Haskell.
I had that happen to me once. A candidate (college hire) chose to code in Haskell, which I had a passing familiarity with. We offered him the job, and he was definitely a strong hire, and we used Java mostly.
I also got a homework which I could implement in whatever I wanted and knowing they are a Clojure company… I chose OCaml. We did the review of the code, explaining the interviewer enough of ML to make him being able to understand the code and why I solved things this way. Was a fun day, would recommend it.
Follow-up: someone saw the above comment, asked who I was, and it turned out my middle-school friend worked at the company. Interviewing somewhere new now.
I've done this by deriving most of the functional constructs in the language. At the end the guy was finally like, do you know lisp? Most people just don't have the knowledge base and think you don't know what you're doing.
That sounds like a reasonable question to me. If you're rolling your own versions of built-in constructs then you're writing code that's hard for other people to maintain. It's a bad sign when the interviewee writes weird, non-idiomatic code. I interview people all of the time who say that the programming language they're most familiar with is Java but use classic Java 1.4 style iterators to loop over a List. It's a huge red flag.
1. Simple iterators vs Syntactic sugar both pass the same unit tests
2. The 'Java 1.4' style closely matches idiomatic golang code, which has high adoption and maintainability
3. People who want better iterators, also want better everything, leading them to use more progressive JVM languages like Clojure and Scala rather than just waiting for the Java spec to move forward
I don't see a 'red flag', just simple contextual differences
Item 46 in Effective Java is to prefer new-style iteration. I think dismissing best practices is a warning, though perhaps not dire (it could just be ignorance / oversight / the pressure of that interview).
I see plenty of red flags, starting with a developer who hasn't kept herself updated on a technology she uses every day.
Sure, she might be forced to use 1.4 in her job but surely, any developer who's a bit passionate about what they do would be aware of the more modern version of their tool of choice?
If we use 1.8 where I work, I can't really evaluate whether she'll be able to adjust since she didn't make any time to adjust these past ten years.
Rephrased: 'I prefer the 1.8 style and I hire people based on that'.
For interviewing, the 1.4 style is totally valid, works in more environments and achieves the same result. I don't red flag folks who answer questions based purely on small preferences, in the same way I wouldn't red flag you for writing these loops instead of using map / reduce concepts instead.
If this is what you care about, then ask questions that lead the interviewee to demonstrating knowledge of these skills. Demonstrating skill with functional-ish "stream" APIs means the developer is a lot more likely to understand any impl's built on functional paradigms (e.g. Spark, actors, etc.), or at least can pick them up very quickly since the APIs and semantics are quite similar.
A candidate who writes list.stream().filter(...).map(...).collect(...) gets big bonus points in my book. I'll ask them about efficiency, to see if they know when to drop to for-loops. If they write a 1.4 for-loop, I'll ask them to evolve or parallelize it to see if, at some point, they stop adding complexity to their loop and instead switch to a cleaner functional style. Starting from a for-loop and asking to implement some simple transformations like filters, reverse, group by, map, etc., does wonders to separate the wheat from the chaff here.
What about JS with multiple idiomatic styles? I was asked what filter and each do, which I wrote out because they are super small. Easier to show a little code to explain.
Nothing wrong with functional languages, and from my experience an engineer who knows one or two functional dialects tends to be pretty good. Exceptions exist but they are rare. We also give our candidates the freedom to use any language they want. After all, there are only four language families; the rest is mostly syntax.
But I do carve out a special exemption for myself when[+] I interview someone. I kindly request the candidates that they don't use Scala or Prolog.
A buddy of mine, for fun, has learned how to hand assemble X86_64 ELF binaries using a primitive line oriented text editor and arcane keyboard sequences. He's used this technique to bootstrap his own stack based programming language and tools.
He's got an interview coming up, where he can work in the programming language of his choice. I tried to talk him into doing his coding problems in hand assembled X86_64, but he apparently wants to get the job and doesn't want to come off like an arrogant jerk, so it's going to be Python.
ummm.... okaaaaay.... so in past live's I've managed processor validation groups, including at Intel, so if somebody came in and hand-assembled X86_64 code right before my eyes, I'd think "Great! Most people have to learn that on the job." Being able to disassemble X86_64 in your head is a valuable skill, too. For my next question I'd probably move on to asking them how to create a particular pattern of I-cache misses. And for bonus points, write out the bits of pi as a 32 bit float.
Because, IMO, it combines the worst aspects of Java, Delphi and FP family traits in the same package.
Trying to follow what a Scala program does under the hood makes my head hurt. Following the edge cases through a forest of syntactical candy-floss is just too much. The plain Java parts are not bad, but the moment you pull out and nest all the special lispy shortcuts... from that point onwards I need to expend a big fraction of my brain cycles trying to figure out just what the hell the piece of code is actually doing. Or trying to do - because I can't properly trace the subtler logical parts.
And the end result is that, with Scala I do not feel qualified to assess your problem solving approach. Code should be written for computers to run, but for humans to understand.
if you ever care, the wizard book[1] can get you started with a toy implementation of prolog. it's just searching through a big state space, really not much to it. The key idea is unification. PAIP builds up to it in a nice way, and the scheme language spec has (had?) a nice unifier as an example[2].
it's also pretty reasonable to just say to hell with prolog, and go do other fun things with your life. But if you do care at some point, it's not magical. it's just a fancy search.
> But I do carve out a special exemption for myself when[+] I interview someone. I kindly request the candidates that they don't use Scala or Prolog.
What if I offered to teach you basic Prolog for an hour ;)? One of my favorite side projects was playing around with it and seeing how clean and concise it could make the rules for T9-style (this was like ten years ago) predictive text matching, going from digit -> letter.
In most cases when a company rejects you because of "culture fit", chances are there's something wrong with yourself. Not the other way around.
Companies are NOT out there to bring you in, waste several collective hours of their employees time who could be working otherwise, just to reject you. They WANT You to pass the interview.
If you don't pass the interview because they think you are not qualified, then that's something that can be fixed. You just need to study more and get more experience.
But if you don't pass because you're not a "culture fit", it means you probably came off as a difficult person to work with. And this article shows why.
Or you made the person feel insecure,
you were poorly understood in the 45 minutes they had to talk to you in between meetings and a hard problem they were working on,
you didn't have the right clever data structure shibboleth that their Cs 101 course taught, etc etc.
There are a lot of reasons you can fail the culture fit. Doesn't mean you aren't the problem, but as someone frequently interviewing candidates I can tell you blame also rests on the other side of the table.
This comment has been rejected because it has poor cultural fit. :)
A job interview is a social game. An interviewee coming in to an interview thinking this is purely about their ability to whiteboard a solution or solve a puzzle may end up a "poor cultural fit". The main deciding factor is whether you can get along with the people interviewing you for the duration of the interview. The secondary factor is that you meet some minimum bar of smart/skills/knowledge.
Companies are NOT out there to do anything. They don't want you to pass or fail. The person interviewing you, who may have had a good day, a bad day, may have a certain background or certain preference, may know the hiring decision has already been made, may have another candidate they already prefer, may have their own little special FizzBuzz, or whatever. This person and you have to sit down for an hour and you have to convince them they should hire YOU. Even if they had a bad day. Even if you think vi is better than emacs and they prefer emacs. Even if they like object oriented programming and you're a functional programming guy. Even if they think you're too old to know how to code. You CAN do it. Then it's up to you to decide whether you want to work for a person who prefers emacs ;)
"Culture fit" is typically a thinly-veiled excuse for age discrimination. Or other kinds of discrimination, for that matter.
Or they're the kind of company that will ask you about your hobbies and then reject you if you don't have the same hobbies as the rest of the team. If you're a mild-mannered, introverted enterprisey person, and the company is a hip young startup staffed with extraverted brogrammers, you're going to be rejected for "culture fit". It's toxic.
Being rejected on "culture fit" is a generic response companies give because they don't want to risk a lawsuit. It's not the actual reason for the rejection.
>But if you don't pass because you're not a "culture fit", it means you probably came off as a difficult person to work with. And this article shows why.
I don't think that's necessarily the case. A lot of companies have very strong cultures tailored to certain personality types. Company A may encourage bluntness and risk taking where Company B may encourage more tactful feedback and careful planning of any task. It depends on the market the company operates in and the ingrained culture.
Relative to that culture? Yes absolutely. Not being a "culture fit" can be a boon for the candidate if they are not compatible with a culture in which they would be miserable.
I've noticed a lot of tech companies now starting to adopt psychometric testing. So you might be bloody good at balancing an AVL tree on a whiteboard but a pretty difficult person to work with so they won't hire you. We place a lot of emphasis on psychometric testing in combination with how good a candidate is technically. If you fall into the wrong quadrant (generally indicating you are difficult to work with) we won't hire you.
You also won't hire me and many others because we run as fast as we can from the rare companies that give personality tests. The moment that gets mentioned in a job description, I laugh and close the tab. My view is that if somebody thinks a bullshit personality test is a good way to assess a candidate, they're the crazy ones, and they may as well propose a polygraph too.
I say go for it, you are interviewing them just as much as they are interviewing you. In the same context on a simple application form I was asked what my previous compensation was, and what I would expect. I ended up cancelling the submission due to many other questions. But in regards to compensation my answer was "That is a second date sort of question"
As an interviewer if I was ever asked a whiteboarding question it would be an instant rejection, regardless of your performance in the interview. It shows a lack of social awareness and I wouldn't be comfortable working with you on my team.
Can you explain more why it would indicate a lack of social awareness? If I am interviewing at a company, I want to know the kind of people I'm going to be working with/for. If the person who does all of the technical interviews lacks technical ability, then what does that say about the people he/she hired? If they think a solution to a whiteboard problem is essential, how can they judge a particularly creative solution if they don't have intense technical experience above an beyond the people they are interviewing?
That's an interesting way of looking at it. I've interviewed plenty of candidates in the past, and if someone I was interviewing asked me a whiteboard question when I asked 'do you have any questions for me?', I'd be amused, pleasantly surprised, and impressed.
And I'd probably be more likely to want to hire them, too! Asking their interviewer a technical question would show me that the candidate cares about the quality of his or her future co-workers.
I want this to be funny, but even the simplest of LISP is foreign to me.
So I'm kinda like an English only speaking expat at a Hong-Kong Bar, where a local guy tells me a (dirty?) joke and I laugh, even though I didn't quite get all the details.
Meta: I've noticed over the past few weeks that any post that is critical of whiteboard interviewing has the highest points/hour of anything on the front page but is almost never at the top and usually slips away quickly.
This post included, it's currently at #11 but is clearly more popular than the 10 above it.
What's up with that? Why is this obviously popular subject on hiring practices (which I would think is prime HN material) being effectively censored?
Stories with lots of comments are rank-penalized. "Whiteboard coding is bad" submissions attract a lot of "me too" comments and quickly fall off the first page.
I think part of the problem is that everyone that comments then upvotes. Same as askreddit, for instance. Plus I wouldn't be surprised if these are manually pushed out of the top, there's like one a week and the mods must be getting sick of it
It seems to me that they may be trying too hard to intuit the quality of a thread based on behaviors which don't explicitly indicate it. I think that the only behaviors that should push a thread down are downvotes and flags, not upvoting and/or commenting in the wrong order, or only doing one but not the other.
OTOH, I have definitely noticed that stories with a high upvote/comment ratio seem to have better quality. In the absence of story downvotes, it makes a certain amount of sense to regard a comment without an upvote as a weak signal that the story is low quality. Penalizing stories with lots of comments relative to votes makes sense to me. (I don't know if that's what actually happens, just saying it wouldn't surprise me)
I like the style, but I felt as though I only caught a third of the references (technical and literary).
Was the naming thing a reference to William Gibson, or Rumpelstilskin? Is there really a language named after Le Guin? What other references did I miss?
In Le Guin's Earthsea series, magic is based on knowing the "true name" of a thing (this gives the wizard/witch power over it). The K language (https://en.wikipedia.org/wiki/K_(programming_language)) is famously impenetrable to read but is not named after Le Guin as far as I know.
It comes from ancient folklore (see https://en.wikipedia.org/wiki/True_name). I mention Earthsea here because Aphyr is referencing Ursula K. Le Guin specifically.
> Was the naming thing a reference to William Gibson, or Rumpelstilskin?
Much older. The idea that knowing a being's True Name gives you power over it is common to many human cultures.
There is not actually a language named after Le Guin (at least, not that I know of). However, she did write a fantasy series (Earthsea), in which wizards gain their power from the use of names.
Charles Stross's Laundry series is great. A talented programmer accidentally rediscovers a CS theorem which allows the summoning of demons and is immediately press-ganged into mandatory employment with Britain's occult secret service.
His wife plays the possessed violin from Lovecraft's "The Music of Erich Zahn".
When you say 'this style', what do you mean? The subversive intent or the elegant phrasing? If you meant the intent, search and read the BOFH if you haven't already
"“To know a thing is to name it,” you advise. True names have power. The K language was invented by Ursula K. Le Guin, and is among the oldest and tersest forms of magic."
Beautiful.
I think the first time I learned the value of knowing the true names of things was here:
This was so amazing I actually had to start up an interpreter and write my own implementation. This was extremely fun and it blew my mind. It's one of those obvious things that's only obvious after you see it. Others are calling for you to write more of these and I definetly feel the same.
If I could se a new one of these every week and play along in the terminal I'd have a a lot of fun (all in the name of learning to!).
Some background: I have had 3 jobs (not including assistantships) till now - two were at the big companies mentioned below (MS/Amzn) and currently am at Snap for the past year or so. Before joining Snap I did interview around and had offers from the likes of FB/Twitter/Oracle as well - So I guess I have relevant and recent points here.
- Almost all the interviews followed the same pattern maligned a lot in HN.
- Almost in every one of those loops, I felt like my current experience building storage systems and replication wasn't examined very well.
- I had many other informationals where the company felt completely borgish (no one knew what the other parts were doing), where the recruiters were clueless, where they were trying to undercut me by 50% or so(We have the smartest!), under level me (We always under level outside hires!), where they had no real reason to hire me (We are always looking for smart people!), where they were just trying to prove that they are smarter and so on. All this when I had 5 odd offers in hand and actually told them that to see if they would have a productive conversation rather than wasting everyone's time.
But I do have different takeaways from these though:
- For every guy like me, there are a lot of other folk who can probably spend the whole hour with you and make you leave ambivalent. You will never know whether you hired him because you liked him or because of his skills.
- An actual (even a flawed one) datapoint is better than nothing.
- If the guys interviewing me are anything like me, They probably spend 5-10 hours a week on interviews already. This means custom tuning a process for each candidate is exorbitantly hard. I mean we do look at resumes and try to calibrate what we expect from a given candidate and we do assign certain folk to get information about their current positions - but a completely personalized loop is still in the zone of people who have been the top 1% of any company. If you aren't there, you gotta expect the rote process.
- I don't have a week to fully dedicate to each company. I currently have a hard job - and I prefer to prepare for a generic process rather than custom one.
- It isn't really hard to prepare for this anyway: In fact the rote process makes it so much easier. There are set concepts and websites. I built my own list, filled them in with actual notes, practiced a 100 problems to get into the mode and was in.
- At the end of the day, all these companies have great people in great teams solving great problems. It is very very hard to distinguish one from the other, There is a very high chance you will end up doing very similar work for one or other. So now the distinguishing factors become something else.
- The recruiters in general are just trying to meet a quota.
Wow! Is this a reply to yesterday's discussion about white boarding?
The Python list should have printed out [0, 1, 2] ... so (print "[") and (print ", ") ... Maybe that's why we didn't get invited to the next interview :)
For a moment there I thought some Python in Lisp thing was going to get pulled out of the hat.
Umm forget about the content, I got hooked in the first paragraph itself on the style! Not many put effort into writing these days. The flavour of that phrasing was pleasing enough for me to come back and write this.
What about an array of tuples where each tuple stores something and a reference to an index in the array? How about a dictionary? Can you implement a linked list using a dictionary? Everything can be a linked list if you try hard enough.
Interviewing is not exactly top priority in a company. Sure, management will say that it is, but projects will in fact have priority, so it tends to be neglected and just grows into a series of decisions based on personal experience, internet stories and "best practices".
It really takes a lot of effort to be a competent interviewer. One needs engineering skills, but also soft skills, empathy, teaching skills.
Doing interviews doesn't count in one's performance evaluation, especially given that it's almost impossible to figure out whether an interview was performed in a good or just average way, so for the typical engineer it's a PITA with no upsides.
Candidates will be treated respectfully, but the process is what it is. There are no incentives to improve it, especially for companies that are in demand.
Just so you get an idea how hard it is to manage hiring, when we came up with our interview process we more or less had to do the following:
1. Selected a group of competent developers with interviewing experience. They were then responsible for the whole technical side of interviewing.
2. Convinced management to offer support for the initiative.
3. Evaluated multiple options on how to structure the interview and chose one (e.g. phone + several face to face).
4. Prepared guidelines on how to behave, overcome typical biases, evaluate candidates.
5. Prepared a pool of exercises.
6. Added verification steps to make sure that nothing went wrong in the phone interviews.
7. Ensured that there was always a mix of experienced vs. unexperienced interviewers in face to face interviews.
8. Set out some rules for offering feedback to interviewers after face to face interviews. I have to confess that this never really worked properly. Offering negative feedback is particularly difficult.
9. Checked all of the above with management and implemented.
Then we had to adjust based on practice:
* added guidelines on special situations such as timezone differences, interviewer mistakes, insufficient information gathered during the interview, replacements, interview preparation, offering feedback, offensive remarks, etc.
* scheduled weekly review rounds for all phone interviews and made sure that people took part and took things seriously
* tinkered a lot with the candidate funnel to ensure that interviewers aren't swamped by inadequate candidates but also that we don't miss competent candidates with unusual applications
* balanced between growth goals visible as management pressure to hire and ensuring that the process stayed true to its goal to demand certain technical standards from the candidates
* experimented with various ideas such as homework, different interview structures, laptop vs whiteboard vs paper, access vs no access to docs, etc
* made sure that office management personnel understood the above and was able to work with the process.
When you think about it, this was "just" a typical phone + face to face interview, not rocket science. And the description covered only the technical part, there was also HR, sponsoring conferences and job postings, managing invitations and organizing the appointments, expenses reimbursement, preparing reports for management, etc.
Such an interview method is not typically designed to find what's unique about each candidate and allow them to best express their individuality. It's a machine designed to answer to answer the question of whether someone is (probably) able to work productively in the organization.
The process starts decaying the moment it's not supervised. People come up with brilliant ideas about what could be improved (let's ask candidates to solve problems from programming competitions!), don't stick to the reviews, reuse leaked exercises, become too lenient or too harsh, don't prepare, etc.
Every few months I think to myself "maybe I should learn Lisp," but then I see things like this, and my suspicion that Lisp has been fetishized beyond all reason starts seeming more likely, and I decide to put that exercise off a while more.
At this point, I suspect I'm never going to choose to learn Lisp.
I don't think you're missing out on much. Lisp is probably the least interesting of the functional programming languages. I think Haskell has more interesting ideas if your interest is purely from PL research standpoint. For practical purposes, I don't even consider those languages. Their main value for me is the slow cross-pollination and trickling down of ideas (such as lambdas, type inference, algebraic data types, etc) to more practical, mainstream languages.
Lisp languages are not even functional programming languages, they're mostly general purpose. Lisps are interesting for other reasons such as the s-expression syntax being similar to the AST, lists and other data structures as first class entities and so on. Also they are very practical languages. Clojure and Common Lisp are used in real world production systems for example. Missing out on lisp is missing out on a lot of interesting ideas.
One of the things that slows me down is that whenever I see Lisp code, my mind goes to the equivalent Haskell code, and the comparison is basically never favorable.
I'm a firm believer in the value of learning a functional language, and I totally understand that from a historical perspective Lisp is important, but does it really have much to recommend it over modern functional langauges?
You can write functional code in Lisp. But Lisp isn't really a functional language. That is, you have to kind of fight the language to write non-functional code in Haskell. In Lisp, you don't.
So if you learn Lisp, you learn a language that transcends programming style. It's much more universal than Haskell.
Just read On Lisp and find a primer on Scheme macros. Then if you're still interested read Let Over Lambda. Few languages do macros like lisp, so it's worth looking at the macros to understand a new concept. Besides that, though, I don't think lisp has anything world shaking.
Also if you happen to like what you see in macros, try also checking out parsing words from forth or factor.
The LISP guys spent 40 (50 now?) years telling the world how good lisp is, the ruby and python ones went and actually build cool shit with the language. The later is a better strategy.
On the other hand the one lisp guy produced cool working programs you are not able to understand, while the ruby and python guys solved trivial problems with 100 fragile dependencies, need 10x more time and people to support it.
The first is the better strategy.
> On the other hand the one lisp guy produced cool working programs you are not able to understand,
It's this precise attitude that turns me off Lisp. First, it's not actually that hard to understand. Sure, it's harder than most other languages, but if you've done programming in half a dozen languages (some functional, etc.) Lisp holds no real mysteries.
More importantly, being hard to understand is a bad thing. A large part of what makes a good programmer is the ability to write clear, robust, easy to understand code. Yet Lisp advocates seem to love to talk up how hard the language is to learn and how subtle and mysterious it is. I'm sure that appeals to teenage boys, but it is objectively a bad thing! Like, literally - hard to understand code has all sorts of obvious disadvantages, and no compensating advantages over easy to understand code. It's a bad thing!
I've never heard any Lisp advocate talk about it being hard to learn or use (let alone in some bragging terms). The most memorable advocacy quote for me is "cuts through hard problems like a hot knife through butter".
When the language is easy to work, you delve into harder problems.
What cool working programs (emacs aside) would these be? For such an old and constantly promoted language the list of working programs is incredibly sparse.
lisp programs are used in the industry mostly. everything which is bit more complicated, and is happy with a one-man dev team. extremely cool apps.
open source I only know gmane and sawfish.
emacs and autolisp certainly not, these are atrocious dialects.
Yeah, because you come off as completely nuts. Oh, and an asshole since you chose a language the interviewer didn't know then refused to answer basic questions.
> The William Gibson version would begin thusly:
> It was hot, the night I burned the Seeker. Moths batted themselves to death against the humming neon signs just outside the single window in the cramped room. There were ancient electronics piled to the ceiling in here, hot new chipsets from Taiwan still unwrapped distributed unevenly amongst them.
> The Seeker put his hands on his hips, brushing aside the corners of his Sukajan jacket bomber jacket replica. "I heard you and Bobby were hotshots, once. Real.. artístes", he said, the last word paired with a smug grin. "Heard you could do things."
> "Things like what?" It's been 20 seconds and you've already wasted too many cycles with this guy.
> "Things like making lists, just, fold up inside themselves. Come out the other way around. Crazy things."
> You grit your teeth. The dex has left your system and you're starting to feel a massive drug deficiency coming on. "Crazy things cost money", you manage. The lists already unfurling in your head, you start typing as quickly as you can to hide the microtremors.