I won't bother with coding interviews. I consider them to be "hazing rituals"; not actual qualification assessment. I am very, very fortunate, in that I don't have to deal with them. I am not looking for work, and plan to never look for work, ever again.
I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built, and submitted to the App Store, or SPMed into your own work, in about thirty seconds.
I've written stuff that is now a worldwide standard infrastructure, and the links to that work is in my portfolio, as is a blog entry, where I discuss the strategic thinking that informed its genesis.
I've written dozens of articles, tutorials, and blog entries, that detail the way I think, work, document my code, evaluate and implement architectures, and work with others. Links to all that is...you guessed it...in my portfolio.
There are years of checkins, so things like development velocity can be measured. My GH ID is solid green.
If you aren't willing to even look at it, then we probably won't get along, and we're both better off, avoiding each other.
You are proving exactly why we need a standardized way to judge whether a candidate is hirable. All the candidates I see have almost zero history of contributing to OSS or maintaining side projects. Their work history usually consists of some run of the mill experience.
I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm.
That is why we need to ascertain coding signal. And that is why we need some contrived problem to provide to ascertain within a reasonable amount of time whether a candidate is a yes/no.
You are a unique data point and hundreds and thousands of other developers just don't have that kind of clout (I didn't look through your resume thing).
Also, from a hiring perspective, it's not scalable going through a candidates repos and verifying their worthiness. However, it is fun to talk about them during interviews.
On the flip side, an interview where you're doing relevant work with another engineer is a way to evaluate whether you're a decent person to work with. I've hard-passed on candidates with immaculate resumes and huge open source portfolios because they were rude and insufferable. When you're hiring, you're building a team, you're not hiring individuals who work in isolation.
In a previous life, I was forced to work under a very senior engineer who was/is a well-known thought leader with a handful of books published. His leadership was nothing short of abysmal: he had no people skills, answering questions with links to e-books he'd written for O'Reilly in lieu of responses. The best engineers got tired of being micromanaged and nit-picked and left. It doesn't matter how smart you are if the other people at the company hate working with you.
There are many coding interview objectives (and I won't defend interviews which try really hard to ensure you know how to code) but pair programming and systems design questions are absolutely necessary to understand whether the person you're hiring isn't just qualified, but rather the kind of person who will make the team better overall.
I can understand why big companies use LC type of questions to assess coding skills of those who graduated recently or didn't enough experience to show their work, but I struggle to understand why many Startups adopted such way of evaluating engineers. I see many startups nowadays asking to candidates to reverse a tree, a task that doesn't reflect the daily work in a startup (where people change gears frequently). I understand that people interview to join the big company, pass a certain bar and then get matched to a team, the startup is too small to not have clarity on what skillset they are looking for.
As an experienced engineer Apple I'm sure that you've noticed a few trends such as.
1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work.
2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very familiar with when to use what or how to make something that does one thing do another.
3) Very experienced and skilled people sometimes forget how to do the basics but with a little practice do fine.
4) Those who are experts at the fundamentals tend to learn any new product area relatively quickly, which is a much better approach to hiring than looking for Go + AWS engineers with 20 years of experience ;)
As an interviewer/hiring company hiring many engineers you then have to decide whether you should have a different process for hiring experienced engineers compared to junior engineers or otherwise deal with the awkward circumstance that an experienced candidate maybe isn't just rusty but doesn't have the knowledge or execution ability to code. When hiring an internal transfer it's fairly easy to vet the latter criteria, but when hiring externally it's substantially harder.
I'm in the same boat. Fortunate to have worked at startups that exited succefully and now in cushy corporate job. If I went out and did interviews I would just make enemies.
> All job interview processes are flawed. They're just flawed in different ways, and some of those flaws work to your advantage and some don't.
Ways in which the flaws of interview process have helped me:
* I'm very good at "conversational" interviews. I have battle scars from years in industry. Higher-ups at companies want to hear about that, and they make me strong offers. But technically, I could completely suck at my job and the discussion could sound exactly the same.
* Most of my money is stock growth from my initial packages. No way I would have this $$$ from bonuses.
* My title-bump came during hiring, not promotion.
It's also frustrating for job mobility, as you need to move jobs (or at least have offers) to get employers to pay your market rate. But in order to get offers you need to basically start a part time job studying and interviewing. If you just interview with a company you want to work for with no competing offers you will get lowballed - you might also just get rejected because companies prefer high-false positive rates and most interviewers do not get any sort of continual training, feedback, calibration or standardization. It's also unfortunately standard that your compensation doesn't keep up with your market value as companies would rather hire-in than promote internally.
Max Howell's tweet gets pasted on every article talking about code interviews as some kind of exemplification of the problem of whiteboard/algorithmic interviews.
That's debatable. I've never had to implement a from YAML task execution system for work. I've used them a lot but that's a very different task than writing one. In fact given how many exist writing one seems very much a bad case of NIH syndrome.
Agree that 99% of the leetcode interviews are divorced from everyday coding work.
However, this article goes in the wrong direction in trying to keep the LinkedList premise - how often do programmers see a raw linkedlist anyways?
Directly ask coding questions from your everyday work, and skip the linkedlist stuff as 3rd level detail questions; the signal that the candidate can do the job is much higher then. Ex: here’s an API and it’s json response: write some code to parse it. Add extensions like paging, network failures, etc. Let the candidate google everything, and if your question is good, it can’t be copypasta from StackOverflow.
> It is increasingly common to use this kind of “pipeline-as-YAML”
> configuration to piece together a workflow of pre-built
> components 1. Some real examples of this are TFX components,
> scikit-learn Pipelines, or Airflow DAGs.
Airflow DAGs are Python objects, defined in Python code.
There's add-ons that let you define them in yaml. Which I find hilarious since one of the original selling points of Airflow was that the Dags aren't in XML.
I took Adam’s point here to be that an Airflow DAG author primarily concerns themselves with the configuration of those objects, since the underlying components (Celery worker, Python execution process or K8s pod; data warehouse; RPC) have been abstracted in the form of Operators.
> There are a few questions that people like to use as punching bags. Invert a binary tree. Reverse a linked list. Perform breadth-first and/or depth-first tree traversals. Anything to do with heaps.
None of these are hard. Should be pretty much covered by any good algorithm class.
The problem is that however distasteful or lacking the current situation is, it’s been adopted by most large companies and is seen as standard now so nobody has any incentive to improve it and it self perpetuates akin to hazing rituals at fraternities . Google got us into the current mess with their claim to have found the only difference between good performance and bad performance at Google was the ability to do algorithmic problems. If only they published that research! Before Google was Microsoft. The only thing that would incentivize employers to change now would be engineers refusing these interviews en masse or a small company becoming an influentially big one that has a different hiring scheme altogether.
it's just a matter of time before the workforce will be replaced by shitty engineers who all grinded leetcode and are good at that but are not capable of actually creating anything good on the job. eventually, FAANG will realize they have a problem on their hands and fire everyone and hire experienced people who have no interest in leetcode, and the cycle starts over.
they don't need research, they had that person who became part of the hiring committee overnight and who sold them all on the magic leetcode formula and they bought it.
As a data scientist, I regularly get asked at least a subset of questions that are more suited for real software engineers. Very few interviewers get around to asking relevant things (for me/my job).
My day-to-day is messing around with pandas and matplotlib, mostly, but I never get interviewed on that. It's usually brainteasers, time complexity of some algorithm, and an invariably-rigged machine learning thing I can never get right.
That may be because I'm young, but the idea of studying for a few months and get a salary that's triple of what I currently make, or double of what starts to be the high barrier in my country (France) is extremely appealing to me. I understand that I may not feel the same way in 10, 20, 30 years but until then it's a golden opportunity.
> a decent evaluation of junior engineers without industry experience, but it’s a common complaint among senior engineers that they have to study material that they haven’t used in years to get a job where they won’t use it.
Counterpoint: some engineers with industry experience may have been working on very specific tech that doesn't readily translate to a new position. Actually, I'm sure some companies wouldn't even consider them for that reason.
Big companies need some standardized way of interviewing people if they want to maintain some level of fairness. At least, algorithms and data-structures provide a common denominator.
No. Senior engineers are expected to have different level of skills - project management, leadership, and ability to identify problems that matter, rather than blinding solving problems that are given to them. You're also not going to be able to test their ability to learn by giving tests.
I'm sure most of us would fail high-school trigonometry (or spelling and grammar for that matter) if given one.
I think it's worthwhile looking at what you're going to accomplish out of an interview. For systems design type stuff, I think it's reasonable to always ask, since it's useful to know how someone approaches problems, and it's not necessarily a given that someone would have needed to deal with architectural / design questions regardless of seniority level.
If you're hiring for a senior position though, and the purpose of your question is "can this person code?", you should be able to get enough evidence from their resume / github / references. If you genuinely can't, then I'd question why you're interviewing them for a senior position in the first place. Strict adherence to standardization leads to absurd scenarios like giving basic "can you code" interviews to the authour of Homebrew like the article states.
[+] [-] ChrisMarshallNY|4 years ago|reply
I have a giant portfolio[0]. It has links to 40 or so repos, with tens of thousands of lines of code, spanning decades. Just about every project can be cloned, built, and submitted to the App Store, or SPMed into your own work, in about thirty seconds.
I've written stuff that is now a worldwide standard infrastructure, and the links to that work is in my portfolio, as is a blog entry, where I discuss the strategic thinking that informed its genesis.
I've written dozens of articles, tutorials, and blog entries, that detail the way I think, work, document my code, evaluate and implement architectures, and work with others. Links to all that is...you guessed it...in my portfolio.
There are years of checkins, so things like development velocity can be measured. My GH ID is solid green.
If you aren't willing to even look at it, then we probably won't get along, and we're both better off, avoiding each other.
[0] https://stackoverflow.com/story/chrismarshall
[+] [-] _skhan_|4 years ago|reply
I have to rely on that and absolutely do not expect them to have a green GitHub. I would hate for that to become the norm.
That is why we need to ascertain coding signal. And that is why we need some contrived problem to provide to ascertain within a reasonable amount of time whether a candidate is a yes/no.
You are a unique data point and hundreds and thousands of other developers just don't have that kind of clout (I didn't look through your resume thing).
Also, from a hiring perspective, it's not scalable going through a candidates repos and verifying their worthiness. However, it is fun to talk about them during interviews.
[+] [-] bastawhiz|4 years ago|reply
In a previous life, I was forced to work under a very senior engineer who was/is a well-known thought leader with a handful of books published. His leadership was nothing short of abysmal: he had no people skills, answering questions with links to e-books he'd written for O'Reilly in lieu of responses. The best engineers got tired of being micromanaged and nit-picked and left. It doesn't matter how smart you are if the other people at the company hate working with you.
There are many coding interview objectives (and I won't defend interviews which try really hard to ensure you know how to code) but pair programming and systems design questions are absolutely necessary to understand whether the person you're hiring isn't just qualified, but rather the kind of person who will make the team better overall.
[+] [-] ___luigi|4 years ago|reply
I can understand why big companies use LC type of questions to assess coding skills of those who graduated recently or didn't enough experience to show their work, but I struggle to understand why many Startups adopted such way of evaluating engineers. I see many startups nowadays asking to candidates to reverse a tree, a task that doesn't reflect the daily work in a startup (where people change gears frequently). I understand that people interview to join the big company, pass a certain bar and then get matched to a team, the startup is too small to not have clarity on what skillset they are looking for.
[+] [-] lumost|4 years ago|reply
1) There are those who are unfamiliar with core comp sci concepts, and are still very productive in many kinds of engineering work.
2) It can be difficult for a team that codes frequently and sometimes does need to deal with algorithms and other items to onboard a new team member who's not very good at the act of coding or very familiar with when to use what or how to make something that does one thing do another.
3) Very experienced and skilled people sometimes forget how to do the basics but with a little practice do fine.
4) Those who are experts at the fundamentals tend to learn any new product area relatively quickly, which is a much better approach to hiring than looking for Go + AWS engineers with 20 years of experience ;)
As an interviewer/hiring company hiring many engineers you then have to decide whether you should have a different process for hiring experienced engineers compared to junior engineers or otherwise deal with the awkward circumstance that an experienced candidate maybe isn't just rusty but doesn't have the knowledge or execution ability to code. When hiring an internal transfer it's fairly easy to vet the latter criteria, but when hiring externally it's substantially harder.
[+] [-] leet_thow|4 years ago|reply
[+] [-] adxl|4 years ago|reply
[deleted]
[+] [-] khazhoux|4 years ago|reply
Ways in which the flaws of interview process have helped me:
* I'm very good at "conversational" interviews. I have battle scars from years in industry. Higher-ups at companies want to hear about that, and they make me strong offers. But technically, I could completely suck at my job and the discussion could sound exactly the same.
* Most of my money is stock growth from my initial packages. No way I would have this $$$ from bonuses.
* My title-bump came during hiring, not promotion.
[+] [-] siliconc0w|4 years ago|reply
[+] [-] b20000|4 years ago|reply
[+] [-] carlosrdrz|4 years ago|reply
What some people might not know is that he reflected on that tweet two years later (3 years ago), in this Quora question: https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
He even explains how he actually did well in the software engineering interviews in the process.
[+] [-] yongjik|4 years ago|reply
(1) Most of Google's engineers didn't even know Homebrew - it just wasn't something Google used on its notebooks.
(2) There's no such thing as "inverting a binary tree." At least I haven't heard about it anywhere else.
Maybe Google's interview process is broken, but the tweet isn't really explaining much. It's just a nice soundbite.
[+] [-] gallamine|4 years ago|reply
[+] [-] marcinzm|4 years ago|reply
That's debatable. I've never had to implement a from YAML task execution system for work. I've used them a lot but that's a very different task than writing one. In fact given how many exist writing one seems very much a bad case of NIH syndrome.
[+] [-] dharmab|4 years ago|reply
[+] [-] bfung|4 years ago|reply
However, this article goes in the wrong direction in trying to keep the LinkedList premise - how often do programmers see a raw linkedlist anyways?
Directly ask coding questions from your everyday work, and skip the linkedlist stuff as 3rd level detail questions; the signal that the candidate can do the job is much higher then. Ex: here’s an API and it’s json response: write some code to parse it. Add extensions like paging, network failures, etc. Let the candidate google everything, and if your question is good, it can’t be copypasta from StackOverflow.
[+] [-] b20000|4 years ago|reply
[+] [-] legerdemain|4 years ago|reply
[+] [-] marcinzm|4 years ago|reply
[+] [-] achompas|4 years ago|reply
[+] [-] 908B64B197|4 years ago|reply
None of these are hard. Should be pretty much covered by any good algorithm class.
[+] [-] gcheong|4 years ago|reply
[+] [-] b20000|4 years ago|reply
[+] [-] b20000|4 years ago|reply
[+] [-] toddm|4 years ago|reply
My day-to-day is messing around with pandas and matplotlib, mostly, but I never get interviewed on that. It's usually brainteasers, time complexity of some algorithm, and an invariably-rigged machine learning thing I can never get right.
[+] [-] Zababa|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] yodsanklai|4 years ago|reply
Counterpoint: some engineers with industry experience may have been working on very specific tech that doesn't readily translate to a new position. Actually, I'm sure some companies wouldn't even consider them for that reason.
Big companies need some standardized way of interviewing people if they want to maintain some level of fairness. At least, algorithms and data-structures provide a common denominator.
[+] [-] a_square_peg|4 years ago|reply
I'm sure most of us would fail high-school trigonometry (or spelling and grammar for that matter) if given one.
[+] [-] ryanbrunner|4 years ago|reply
If you're hiring for a senior position though, and the purpose of your question is "can this person code?", you should be able to get enough evidence from their resume / github / references. If you genuinely can't, then I'd question why you're interviewing them for a senior position in the first place. Strict adherence to standardization leads to absurd scenarios like giving basic "can you code" interviews to the authour of Homebrew like the article states.
[+] [-] tchalla|4 years ago|reply
Some
[+] [-] adxl|4 years ago|reply
[deleted]