Examples include: How would you solve this at a high level, here's some code we know is broken, how would you both fix and improve it etc.
After all, both parties are being screened.
The other upside is that we also get to gauge communication and analytical skills not just production line coding.
Even after doing this, over the years I have seen a good 30% refuse to do it or just ghost at this point for whatever reason. Afterall, I've done it myself a number of times.
I'll do reasonable take homes, but I'll often pass on interactive coding sessions. I don't like coding in a browser, and I use my dev tools as a major crutch.
"Why did you store that value as a string instead of a long?"
"Because it's a string from standard in and I have no idea what bullshit inputs there will be so I can check it before casting it."
"But the user story said it will be a number."
Well if I had more than 15 minutes maybe I would have been able to gain confidence in the input. Something like that comes from many years of experience getting burned yet it's considered a negative mark. Some of these places are actually selecting for recklessness.
But it was never to get a job or a promotion. I was already the Dev lead at the company working on an on prem system and they wanted to “move to the cloud”. I just wanted to get an overview of the landscape.
As far back as 2000, “brain dumps” of MS certifications were a thing.
It has worked for me so far in my 15 year career.
So the interviews were more about finding out if I would fit within the team than hard technical interviews. People knew me, and knew what skills I brought to the table.
Your network matters. And if you think it doesn't, stop, think again. Your network matters.
One final note. I have interviewed people. Never oversell yourself on your resume. Don't put down that you are an 'expert' at this or an 'expert' at that, unless you really are. Because you just may end up being interviewed by someone that is. And nobody, absolutely nobody, is an expert at fifteen different unrelated things. Don't do that. I have been doing this for 38 years, and I am pretty good at about five things. And those five things that I am good at have changed on a regular basis since the day I started.
You have some good friends are they are high up the chain I guess.
I then joined the next company when the people who started that company started a new one.
When that startup failed, I was going to take a break and maybe start my own company, but a guy who had worked for me at the failed startup invited me over for margaritas and to check out his new company he had joined, and next thing I knew I had accepted a job offer.
I have been at the last job for almost 10 years.
I now have a ton of connections from people who I worked with and they then left the company. I am sure if I was interested in getting a new job, I could put some feelers out and have some offers right away. I have had people try to recruit me, but don't have much interest in leaving my current place.
I don't think my experience is that unusual. It is so hard to find good talent, sourcing from people you have worked with before is extremely valuable.
People's own interviewing styles aren't any more valid, of course, but they operate at small enough scale to escape the kind of scrutiny that a standardized test would attract. People also don't like to admit they're wrong, and might be applying a kind of halo effect to colleagues who have passed their personal interview questions. Whereas people love to dunk on prestige, and will eagerly seize on anything they can count against someone with a prestigious credential.
It a small company not specialized in education and examinations can set a test and deduce if I am good enough to code, then this can be standardized. And there could be many certs: 1. can code, 2. can code c++, 3. understands multithreading … and so on.
Now i for one dislike leet code and coding challenge interviews. I think it's silly, plain and simple. What i would look for instead if i was an employer would be curiosity. Nothing is more important than insatiable curiosity. A curious employee will learn everything about your whole stack in the first week... just out of curiosity. And if they do hit a leet code like problem during day to day work you best believe their curiosity won't let them rest until they've solved it, be if with prior knowledge and experience or without.
He was unable to execute a .py file.
A PhD doesn't mean that a person knows everything. It means they made progress in understanding in a narrow area. Might not have included Python.
It's almost certain some of then (maybe most of them) would have fared just fine if they were left with the problem alone, not in a high pressure setting like a job interview.
I don't know how you test for the ability to do real world stuff - I always think of doctors, they have a system of proctoring they've developed over the years, where you're judged by your peers and rated accordingly and even then its not 100%. I think this is the only way to do it in real life, but I don't know if programming will ever get to that point, it probably will be necessary sometime - when everything is driven by computers.
I'm guessing your in the under 40 camp, but interviews did used to be better.
In the early days of the startup explosion interviews where much better. The biggest signal at the time was having an active github profile or otherwise existing portfolio of code. The strongest signal back then was serious contribution to any open source projects (strangely today that almost seems to count against you). It also wasn't required that you had these, but they were a very strong signal.
Interviews were largely technical conversations, to see if you understood the concepts, and even more importantly, it was okay if you didn't know. I remember being asked a question about TCP vs UDP. I didn't know much networking at the time, and explained what I knew about TCP but admitted my understanding of UDP was basically non-existent (admitting ignorance used to be a huge plus back then). The interviewers then explained how it worked and asked if I could explain when and why this would make for a better solution than TCP. I answered about the obvious application to media streaming and passed. Interviewers didn't care that you knew everything, they wanted to see how you think.
Even the original predecessor to our current leetcode nightmare, fizzbuzz, was never supposed to hard it was meant as a basic sanity check. There were some devs who had just followed the flow at some big bank and literally couldn't code on their own. Fizzbuzz was just to make sure that given a blank page you could implement basic code.
Of course as tech started to boom, so did the bootcamp/interview industry. People were trained to do fizzbuzz, instructed how to create a github repo filled with meaningless, half started project (or forks of other projects), and people where told how to flood OSS projects with minor pull requests so they could claim to be contributors. Then companies wanted to be like Google and have hard white board challenges.
Then you had a generation of engineers that never knew any different and largely had forgotten (or never known) how to assess technical competency anyway than through a series of hazing rituals.
2007: this is when I first encountered fizzbuzz as an idea https://blog.codinghorror.com/why-cant-programmers-program/
2005 article linked from there: https://www.joelonsoftware.com/2005/01/27/news-58/
That second article is interesting in this conversation because it's main contention is that the vast majority of any applicants to any position you're trying to hire for are going to be terrible.
Which is the phenomenon seen by others as well and discussed in Atwood's 2007 one.
They don't really talk about the Google style DS/algo problems, so yeah, seems like those became popular later.
But it suggests the hiring experience for companies has long been awful.
The sort of experience you had - a good conversation about a detailed relevant technical area - is something that I've never personally found common when trying to hire. Most candidates still aren't great if you're looking to do even moderately greenfield development (even if not particularly interesting - just being able to put together a decent scaffold of an idea).
Leetcode - the site - is an interesting phenomenon because it's full of problems far harder than any I've seen in practice at FAANGs and similar. Stuff I've encountered in the real world seems to fall into the Easy or Medium buckets.
After being at a BigCo and hiring some people who aced whiteboard coding and failed on simple everyday things, though, I certainly would never again use something like that as the only factor.
Would you mind sharing why contribution to open source might have a negative impact for an interview?
If you truly hate the way interview processes have run for you, it’s worth considering if you feel strongly enough about it to seek a different fit in the market. You might not, and that’s fine! But alternatives do exist.
its actually based on personality + a convoluted code challenge that has no bearing on the actual job.
I understand that it feels like its waste of time with no practical use but the upsides are that they make job hopping trival because you know what to expect and feel confident.
I think its a tiny investment for big returns. unparalleled to any other activity you could invest your time in.
Huh. Never heard that before.
I invest my time in writing "shippable" code. Even my "farting around" projects are done in a manner as if they were to be released by a Fortune 50 company.
That means that Every. Single. Line. Of. Code. that I write is "ship" code. There are a number of projects that I've stopped working on (I archive them, but leave them out there), and a few that were never really meant to be sent out to fend for themselves, but I still make the effort to write tests and documentation for them.
I'm so used to delivering software, that I've almost forgotten what it was like to play around; which is actually a bit of a shame. It could easily be said that I "take things too seriously." I can tell you that my employers liked it, though.
My GH Activity Graph is solid green, and I wouldn't dream of "gaming" it. I don't especially care whether or not anyone thinks I'm "l33t." I'm an old fart that has no intention of working for anyone, ever again. I write code for myself, and that I want to see. Most of the folks that I care what they think of me, have no understanding of my tech work, and that's fine.
It makes me feel good to make good, well-tested, well-documented, well-architected code that solves problems.
I guess you could call me a "completionist." I like to finish stuff.
Right now, I'm working on a data parser for a backend API that fetches a JSON response, using the built-in NSURLSession stuff, turns it into a Swift Dictionary, then I sort through that Dictionary, and emit a bunch of Swift struct instances for use by the API consumer.
The reason for this, is because the API that I wrote about seven years ago, is giving us performance problems. I wrote about that in this comment[0].
The NSURL stuff has all the sockets and whatnot, as well as all the transport stuff. I've written that stuff before, but I guarantee that the deep geeks that wrote the system have done a far better job of optimizing that stuff, than I ever will.
The JSON parser (built into the OS, but I may think about maybe licensing another one, if this doesn't do what I want) has all the recursive-descent, tree-crawling stuff in it, so I don't need to worry about that. Since this is a multi-threaded system, almost every school algorithm is worthless, but I guarantee that the deep geeks that wrote the system have done a far better job of optimizing that stuff, than I ever will.
I want to get the hell out of this API, as soon as possible, and return to writing the UI stuff that will make my app sing.
The API is being developed as a standalone SPM package that will work on all the Apple systems (iOS, iPadOS, MacOS, WatchOS, and TVOS). The one that it's replacing only worked on iOS. No excuse. I know better, now. I'll also be structuring this to be a lot "swiftier," and more "reactive" than the original API.
The app is a native Swift UIKit app. It's a big mofo. At its peak, it was over 40 screens, but I'm trying to get it down to half that. I've been working on it for a couple of years. It's had a couple of pretty massive pivots, in that time.
UIKit is a big framework. It takes years to learn. I'm looking forward to SwiftUI, but SwiftUI is not at the point, where I'm comfortable committing to a project of this scope.
I've been working with UIKit since 2012. I barely understand it, and they keep adding new stuff, as fast as I can learn it.
Swift is an excellent language. Like every language, you can get the basics down in a few weeks, but it takes years to get the advanced stuff down.
I've been working with Swift since 2014 (the day it was announced). I speak it without an accent.
The project I'm working on has been a wonderful masterclass in Apple iOS development. I also wrote a fairly massive PHP backend, but that was years ago, and it is, I guarantee, not as cool as a really good PHPista could do. That said, it works great, is maintainable, secure as hell, and fairly well-structured for scaling and extension.
The app is gonna be great. Its approaching ship (still a ways off, but we can see the harbor lights, from here). I've been releasing it on TestFlight since it was a month old. By now, I've probably made over 800 TestFlight releases to the team. That's how come we can be so confident in the UI and the Quality. It gets banged on a lot.
But maybe I'm doing it all wrong, and I should stop working on this to practice leetcode.
Junior here and not as experienced as you are but I resonate with a lot of what you have written so far. I'm more of let my work and projects speak for itself. I also hate leetcode or code challenge kinda interviews. So far I haven't have to take any to get a job and I plan on never taking or doing any. If I see that an interview involves such I will reject it. I can accept a decent take home assignment or technical questions in areas that I will likely encounter on the job.
[1] https://blog.pragmaticengineer.com/software-engineering-sala...
You're not "wrong" per se. If you want a pure Swift job it would be very reasonable if the hiring company tested you on your very broad and deep Swift knowledge. However, if you ever wanted to do anything else job wise you'd be screwed. Leetcode gives you a chance to become a Java/PHP/C++ dev somewhere. That's the only plus for me. I'm mostly a Ruby/Rails dev experience wise and I get a real chance at different stacks because their hiring process is Leetcode (or something of the sort) and general design questions. So sure I'll never know as much about Swift as you but I do think that a hard working engineer who takes his craft seriously can pick it up and become productive in a couple of months. Not an expert, productive. I can join your company/team and then someone like you can make sure my code doesn't suck. For many companies that's good enough. Others can't or don't want to mentor anyone for more than a week or two so they only accept someone who fills all the requirements of their stack. Mostly startups, and in general not my cup of tea.
I love this, and I’m stealing it. it’s a perfect description of competency in a language, imo.
I absolutely understand the emphasis on shipping, and i actually have recently come to lament some of my unshipped projects lately (I’m in a phase of finishing instead of starting projects myself, and sometimes have felt like I haven’t gotten to ship anything in my software career, but that’s another story for another day) but part of the core skills I attribute to allowing me to finish are the same ones leet code interviews helped me polish. how one works on a low-level data structure is one of the core aspects of software engineering i examine in a new hire.
What I think I’m trying to say is, I don’t mean to stop working on shipping a project to focus on leet code toy problems, but rather that a lot of leet code interview problems have given me better insights on how to focus and solve problems im trying to ship. I have found great value in going back and rehashing leet code interview problems and turning them into tiny libraries after i was given them. So much so that I’ve turned it into an exercise. I’ll have to write a full post about it sometime, but writing tiny libraries has been one of the best things I’ve done for my technical skills.
I'd read that.
> but writing tiny libraries has been one of the best things I’ve done for my technical skills.
I do that all the time. When I get to a bunch of code that I think has reuse potential (like, say, a backend connection SDK), I break it into a standalone GitHub repo, set it up as an SPM package, and give it The Full Monty for testing and documentation. The testing code usually dwarfs the implementation code, and the documentation is...well, you can see for yourself. Here's a few of the packages that I've written: https://riftvalleysoftware.com/work/open-source-projects/
I usually take a few days off the main project, write, test, document, and release the subproject, then re-absorb it into the main project.
It’s just that when interviewing, it can few easier to evaluate some algorithm puzzle than to figure out what it means and whether it’s true that “the app is gonna be great.”
I used to hire pretty senior-level engineers. They would be writing C++ image processing pipeline code, to some insanely exacting standards.
My technique was usually to get them relaxed and comfortable, then start asking them for stories about the projects they've worked on. It was always a joy, when I could get them to start chattering, like the post above. I would look at the enthusiasm, and the passion, as much as the technical detail. I'd love hearing them talk about discovering problems, and how they addressed them.
There's a lot of similarity between that, and UI work.
I trained as an artist, way back in the Paleozoic Era, and that gives me "airs" about things like graphic design, and data presentation. I've spent a good part of my career, unlearning that crap. I'm usually best off, leaving the defaults in place, if possible. I write about that here[0].
I think that UI needs to be treated as seriously as possible. It should not be an "also" thing. I think it needs to be the starting place for the work, and I tend to develop UI pretty quickly, in my work.
I feel like SwiftUI still needs a lot of fine-grit sandpaper. I have every confidence that it will get there, but I don't feel confident in committing any project at scale to it.
[0] https://littlegreenviper.com/miscellany/the-road-most-travel...
Obligatory ask, bullet list of "the advanced stuff", please?
There’s an excellent book[1], called “Advanced Swift,” by Olle Begemann, and Chris Eidhoff, that gives a far better breakdown of the more intricate parts of Swift than a simple bullet list.
Like many languages, Swift is a deep rabbithole. Heck, you can get lost, just in the way it handles strings[2].
[0] https://littlegreenviper.com/series/swiftwater/
It's also possible that I didn't "miss the point."
They did ask "Why not". It may have been rhetorical, but I pretended that it wasn't.
Of course, like all these types of things, I have my own approach. It's fine, if others don't want to do things the way that I do, but I'm not into playing "Me Big Man on Campus" games. I just talk about the way that I do stuff, and my own approach.
For me, I can't even imagine "job hopping." I stayed at my last job, 27 years.
If "job hopping" is someone's idea of a career, then I guess leetcode is the way to go.
But if we want to stick around, that means that we can't just have a veneer of competence. We need to actually have it.
I’m lying, I would have hated working for any large tech company as a software developer after spending decades at small companies.
i have over 200 repositories etc. its redundant, and random code challenges that differ from employer to employer prove next to nothing.
20 years ago it was the norm for interviewers to ask brain teasers / riddles in interviews ffs.
edit: perhaps this is my own personal struggle as I did not attend University.