Code Interviews
alaiacano.github.io
alaiacano.github.io
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 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.
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
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.
For the same reason that hazing has lasted as long as it has.
"I got hazed, so you will, too!"
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 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.
As soon as I listed everything I started getting calls back.
That's what big companies are all about, there's really nothing new to see here. It seem to be working well for most of them though.
It has to be a good CRUD kitchen recipe app if you want to show it off.
Bad - small coding project will show that candidate is a bad coder, even if the code works.
Bad - cover letter will show that candidate has bad grammar, even if person put in the effort.
Good - small coding project will show that candidate can get anything done.
Good - cover letter will show that candidate is willing to put extra effort to get the job.
Most inexperienced candidates...
One of my favorite pastimes, is following up on GitHub, with people from this joint, or others, that pique my interest.
There's a lot of really awesome stuff out there! You guys rock!
Of course, many of these folks, are...chronologically challenged, let's say. If you've already decided that you will only be hiring folks right out of school, then I can see the problem.
And...to answer the inevitable "You're likely an insufferable bastard" canard, that the conversation ends up at, after we've worked through the other things, I have a LinkedIn profile, packed with testimonials, from managers, former employees, and project partners.
Turns out, I'm actually a really decent human being, and play well with others.
I also worked for decades, for a Japanese company. You won't last long at a Japanese company, if you don't "team" well.
Most people have various interests and obligations. The number of people who after a day of work in software engineering go on to continue to do that in their free time instead of pursuing other interests is vanishingly small.
Additionally you have people who also just can’t do this, even if they wanted to, due to other obligations.
Obviously there are people who have a very narrow set of interests and leave their office to go to a hacker space but that is such an absurdly small group that it’s ridiculous to even consider them in hiring.
In fact you probably want to avoid having an entire team of people like this in favor of a more diverse group of people.
It is, however, an advantage that some folks have, and my suggestion is that we should not be required to deliberately hobble ourselves, just because everyone does not have the same advantage.
Of course, a hiring corporation has every right to ignore things like this, and they likely won’t go out of business, as a result. They, may, however, miss talent that could take their business to “the next level,” and risk hiring folks that have become expert at “gaming the system,” and presenting style, over substance.
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.
If you are self employed, you might not get the same contract. In our contracts, what has been discussed in the thread was clearly stated by our employer (I asked my colleagues about their older contracts as well).
I was fortunate, in that I didn't have a "shower clause" in my employment contract, so I was able to do a lot of extracurricular work.
In fact, it was a principal reason that I stayed at that company. They paid me...OK...for doing the work I hated (managing -but I was also a good manager), and let me have enough bandwidth to do my extracurricular work; which was my true passion.
Basically, the work I didn't get paid for, was what I really wanted to do. They were extremely happy with the work I did for them, which did not reflect my true, personal passion. I feel like I was "just going through the motions," as a manager.
But I also firmly believe that if I am given responsibility for a task, then I do it to the very best of my ability; whether or not I am passionate about it, and I'm actually a really decent manager (for the type of team I led).
After leaving that company, and learning (the hard way) that no one wants to work with a 55-year-old engineer, willing to work at half the wages of far less-qualified people (because I already had my retirement set), I was forced into early retirement, and actually achieved my dream, which is writing code to help out NPOs, for free.
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.
The job of ‘programmer’ takes on many shapes and sizes. Businesses evolve and are different from one another.
You may be very successful in some clusters of business, but how representative is this, let alone your unique experience, to the rest of the industry?
If you’ve never worked with anyone with “real” software training, why would I hire you into a senior position when there are plenty of candidates who have?
I’ve worked at companies back in the day where experienced non traditional programmers have both kick started and ruined businesses within the same job. You may be successful enough to grow a business, but that’s different from scaling or pivoting one.
If you can’t grok a homework program from the first week of a data structures course, why should I trust you to self learn more advanced topics? Why would I spend a ton of time evaluating massive GitHub contributions vs. just watching you code a problem your team would work on for 1 hour?
I have to pay smug kids 100s of g’s because the labor market is so fucked, and there’s no way I’d either trust them to evaluate candidates via code review, nor would I spend their time on that vs. building and learning.
I’d love to not pay children small fortunes, but most very experienced journeymen I’ve interviewed over the years can’t string together dynamic api calls or tell me how things scale, and I get to hire for experience first every time.
If you were able to self teach, then the kid that just spent 4 years snorting adderall and interning and google sure as hell has a chance to, too, and he’s willing to solve my dumb riddles.
The other thing you won’t read: firing people for most managers is awful. A manager only takes so many risks before they learn how to mitigate having to experience this horrible experience. I’d rather reject you than fire you.
Edit: I was one of the impressionable young readers once upon a time, and I set myself back quite a bit taking advice from strangers on the internet. Genius programmers on GitHub don’t sign your paychecks.
I was merely recounting my own personal experience, and, a bit more cautiously, opinions. I say “cautiously,” because I know that opinion is a different thing from fact, and I need to be careful to avoid presenting my opinions in a manner that frames them as “facts.” In another thread, I needed to do a mea culpa, where I did just that, and was [rightly] called out for it[0].
No BS at all. It actually happened. Are you calling me a liar? Because that is what it appears to be, and I was under the impression that we don’t do that kind of thing, here. One of my personal postures, is that I stand behind my own words. Please note that I have links to my entire portfolio, and many, many ways to back up (or refute) what I say. I deleted my last anonymous posting account, years ago.
One of the issues that I have, with today’s Internets Tubes, is that people like to anonymously spew out opinion as fact, and take every opportunity they can, to insult and demean others. I make every effort to avoid that, in my own interactions. Feel free to go through my posting history, and show me otherwise. If I am wrong, I live a lifestyle, where I am required to promptly admit it, and make amends. I believe that I do this.
I have merely written my own experiences and personal story.
It makes me very, very glad to know that I never have to put myself into a position again, where certain types of folks have power over me. I am quite aware that my own story is different from the run of the mill, but being called a liar for telling it, is beyond the pale.
This new world seems dark and depressing, to me. A Lovecraftian “food chain” world, where everyone is constantly battling everyone else; including their own teammates. I used to look forward to a career of excitement, adventure, learning, and being a member of teams, where I was the dumbest member, and it was an honor to be included. I have never been interested in competing with others. I have always wanted to collaborate with others. I am rather saddened to learn how unique this approach is.
In a lot of ways, I got that, and I’m grateful, but I now see that I probably dodged a bullet.
If there were anything I would say to “impressionable young readers,” it would be:
At one time, some of us looked forward to careers that were not gladiatorial arenas. We woke up, every day, anticipating learning new stuff, and felt honored to be part of a team, composed of people that humbled us, but never humiliated us. We made enough to have a comfortable living, never worried about putting food on the table, and didn’t have envy for our coworkers. We didn’t measure our own self-worth, by demeaning others, and we felt as if we were riding the crest of thrilling new discoveries and technologies. We stayed at companies for many years, because we believed in the aggregate mission, and liked the idea that we were making a positive difference in the world. We became lousy interviewees, because it was an unnecessary skill. We never “hazed” one another, and embraced our differences, as they brought new perspectives into our worlds, challenging us to constantly review our own opinions and worldviews.
There was, once, a happier time, before The Great Old Ones burst through the portal, and made the world as it is, today. I lived in that time, and am reporting from *experience*.
If merely recounting my own experience and personal worldview is considered a threat, I have no words, other than I truly feel badly for others.
Now, I truly am done with this thread. Have a great day! I sincerely wish you and your family, health, success, happiness, and fulfillment, in all your affairs.
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
And frankly, I'll happily take the L if the candidate rejects me as the interviewer at another position. I have no right to assert that I'm the best possible candidate for their role because the job at hand isn't strictly about quantitatively measured qualifications. Though, if I rejected a candidate for being unpleasant, chances are I'll withdraw my application upon seeing they're and interviewer. Why would I change my mind about working with that person?
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.
> 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
(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.
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.
leetcode interviews do not test if a person can reasonably code. they expect people to give a specific optimal solution to a specific question which you can only provide if you have solved the question before, in the way it is expected, within max 2-3 minutes. the process is broken.
the moment you ask a candidate to build something you could use in your codebase you should pay them.
> 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.
And I have no reason to waste my time spending a few weeks prepping for a code interview, either. I am who I am. Either you want that, or you don't. I'm not going to try to spend weeks studying so I can pretend to be different than I am.
(Disclaimer: I'm not looking, and I haven't been for a very long time. I've never been desperate while looking. I haven't even been unemployed while looking in over 30 years. If I were unemployed and watching the bills pile up, I might feel a whole lot less smug...)
Preparing for interviews isn't wasted time provided you have some chance of success. The signing bonus alone can be worth the time.
I've been in coding interviews that matched the work that the company is doing, and I've found those useful - I get something from taking the interview (an idea of what their codebase is like, working with a partner, maybe some interesting code design questions), but I'm never going to do another "code this CS algorithim that 100% of people use a library for nowadays" type questions.
Some
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.