>"and seem to have followed the type of curated success-seeking golden path that used to be reserved for finance."
I am curious what you meant by this. Would you mind elaborating?
I am curious what you meant by this. Would you mind elaborating?
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.
If you are a good developer who sucks at whiteboard interviews, write open source code that everybody can see.
Otherwise there is no reason an interviewer can or should trust whatever story you tell of past successes.
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.
Also, some people have enough flexibility to learn new languages, technologies, frameworks, and such within the context of their day jobs.
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.
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.
It's been done, still doesn't get you a job.
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.
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.
Would be interesting to see which companies actually look at your github profile like they claim they do.
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).
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?
(S)he spends so much time playing translator that there's no time to sweat the details. That falls to the team.
Except that its pretty easy to see if someone is telling the truth about their area of expertise with a few open ended questions.
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.
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.
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.
[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 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.
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.
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 totally agree that it's a shot in the dark, though.
To be sure, some people take it too far. The "four months" figure does not come from me.
Curious if you have any examples. I have really hard time motivating myself to study same old ds and algorithms too .
Solving those problems gave me a reason to touch lots of parts of the language and was also intellectually interesting. See, for example: https://github.com/brianquinlan/learn-rust/tree/master/i18n
> 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.
I think that if you are working on some moderately challenging and varied personal projects, that's probably also a great way to prepare.
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.