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.
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.
I'm a unique talent. I'm not God's gift to Programming, but I have a very different kind of backstory from most that you find. I had a hard road, and the uneven terrain that I traveled, has a lot to do with how I became as good as I am. When no one gives you breaks, you are forced to make your own, prove yourself, at every step, and accomplishment becomes habitual. You learn not to overpromise, figure out how to learn new stuff, and check your own homework.
Many of the team I led, had similar eclectic backgrounds. They were all senior-level C++ algorithm developers, with decades of experience. Most were smarter and better than I am.
We all would have been immediately rejected, in barbarous fashion, from today's hiring process.
As it turns out, they have all gone on to do very well, and that makes me happy. I am glad to have been a part of their career. Working with them was a signal honor. They are making their new employers quite happy, indeed, but it took each of them over two years (in a couple of cases, well over two years), to really land, which is quite telling.
In my first three jobs, I never worked with one single engineer that had actually had real software training. I worked with astrophysicists, mathematicians, MBAs, chemists, designers, economists, teachers, electrical engineers, and even other high school dropouts, like me. Even my last, long-term job, was mostly with EEs and physicists, but all the Japanese folks had serious sheepskins. It was a fairly marquée corporation.
Not sure about US, but in EU, the contract from employers doesn't allow you to contribute code without permission (e.g. contributing to OSS, working on side projects, etc), it's very very rare to find an exception.
You can check this discussion few weeks ago: https://news.ycombinator.com/item?id=27843198
> I have to rely on that ..
By doing this, you are not considering employees who are doing nothing wrong, but follow the rules and respect the contract terms.
I was a hiring manager for 25 years. I would have killed for this kind of information.
The people I hired were no slouches. It was a big deal, and not to be taken lightly. I loved multi-page résumés.
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.
* not trying to imply that there is no objective way to define/measure decency
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.
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.
2) again, see 1)
3) they don’t need to remember everything about all algorithms and data structures, just like lawyers don’t remember all details about the law either. that is what books and the internet are for. you just need to know what exists and where to find it, and should have implemented some of it in your career and while in college.
4) i think that that is a typical mistake made by managers and HR. it takes years of work to enter a particular niche and gain experience in it, and it’s unrealistic to think you can just quickly train someone on the job. apple is the example here - most people there are highly specialized in exactly one thing and have long careers related to that.
passing on experienced people because they don’t care about your stupid binary tree trick question or are just tired of going through another leetcode circus act is a costly mistake - there are only a very limited number of highly specialized people available in the market, and it is these people who will make the difference between a “meh” product and something truly incredible.
hiring is broken and will remain so until the coding interview bullshit is replaced with something better.
That's me! But...wanna see something cool?[0] That's a link to the maintenance manual for my very first engineering project, started in 1986-7 (PDF doc). I wrote it, as well as the project it describes. It contains full source code for the firmware OS, strategic discussions, user guidance, chassis, and electrical diagrams.
My very first project. At the time, I was a high school dropout, with a GED, and some tech training school. I'd never attended one single "core comp sci" class. In fact, I had no idea that "core comp sci" even existed. The engineering team I worked with were all EEs. The firmware team was separate (and a bit arrogant -hard to work with), and my team liked having their own firmware geek, who was quite grateful, for being given the chance.
Not too shabby.
> 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.
I code every single day. How's that work out for you? In my experience, others have a hard time, keeping up with me.
> 3) Very experienced and skilled people sometimes forget how to do the basics but with a little practice do fine.
Define "the basics."
If you mean LeetCode school curriculum algorithms, then, guilty as charged. Also, guilty of not being particularly interested in "a little practice." These represent things that I have seldom encountered, In Real Life. I won't bother wasting time practicing them, if the only place they have utility, is in a conference room that I'll never enter.
If you mean "the basic structure of iOS applications," "device I/O concepts," "Shipping to the App Store," or "idiomatic Swift," then, you're in luck! Since these inform the work that I do every single day, I happen to be pretty up on them. No practice necessary.
Although, TBPH, I frequently google even the most basic stuff. This will continue for the rest of my life. If you can't deal with that, then we're better off not interacting with each other. I forget stuff, all the time. I google it.
This Internets Tubes thing is the pants!
> 4) Those who are experts at the fundamentals tend to learn any new product area relatively quickly
People who solve difficult problems -every single day- can also be pretty fast on the uptake.
Just sayin'...
[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
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.
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.
(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.
It’s actually pretty easy if you’re comfortable with recursion and traversing trees. The tree questions Google asks in its interviews are usually much harder- it implies they were giving softball questions to him.
> But ultimately, should Google have hired me? Yes, absolutely yes. I am often a dick, I am often difficult, I often don’t know computer science, but. BUT. I make really good things, maybe they aren't perfect, but people really like them. Surely, surely Google could have used that.
Hmm so he fully admits that he made a bad package manager and is often a difficult dick. He sounds pretty arrogant too. I wouldn't have hired him.
And yes it is bad (try installing an old version of something). Just because it is popular doesn't mean it is good. It only ever had one competitor (ports) and that wasn't really Mac focused.
It's of no interest to Google that something bad you made happened to become popular. It's not like you can repeat that on demand.
Would you hire the person that wrote Bash? Or YAML?
> I am often a dick, I am often difficult
If that came out during interview, it could easily have sunk their packet
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.
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.
None of these are hard. Should be pretty much covered by any good algorithm class.
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.
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.
I'm sure most of us would fail high-school trigonometry (or spelling and grammar for that matter) if given one.
Not if we had a few weeks of prep time.
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.
The problem is when you get 1000s of such resumes, but only a few positions to fill. Also, not everybody has time to spent on github projects. It can be even more time consuming to work on personal projects than brushing up your algorithmic skills. Not saying these interviews are perfect, but I do believe that they are a good solution for a very big company.
Talking about system design interviews, I had the feeling that they were less useful than algorithm interviews, especially for a senior SWE. You can nail them with only theoretical knowledge, even though you've never worked on the systems they ask you to design.
Some