the thing that gets frustrating as i age are interviews and code challenges. i'd really prefer a certification that proves i can do xyz which i take once (per year? in my life?). then just decide if you like me based on personality and communication.
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.
I'm an older engineer too and I am very aware of how frustrating this can be for techs of all ages so I made our screening test less fizzbuzz, do my work for me and gotcha questions and more real world, challenging, engaging and most of all interesting.
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.
over the years I have seen a good 30% refuse to do it
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.
A take home that can be done in an hour or two is fine in my book. It’s problematic when they assume way too much background on the part of the interviewer. I had a take home from a small local embedded devices company want me to write a 2D DCT algorithm from first principles in C (absolutely no use of external libraries or code copied or based on any existing code) and I noped out pretty quickly. Unless it’s something I’ve done before, doing it honestly without consulting any existing code would probably take me days.
As someone who is very “certified” when it comes to cloud, I can tell you that certifications mean absolutely nothing and can easily be gamed. I went through the certifications route only as a guided learning path so I would know what I didn’t know. Anyone can pass a multiple choice certification. I got my first AWS certification without ever logging in to AWS.
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.
So I’ve heard. If someone passed the K8s cert, you expect them to be somewhat competent. If someone honestly studied for AWS certifications without experience, you expect them to be conversant. I have nine of them now (out of 10). But just so I can be conversant. It’s definitely not prove competence in areas where I don’t have real world experience.
I have avoided this problem by not interviewing anymore. Every job I have had after my first one has been going to work with someone I worked with before, and they recruited me so I didn’t have to do any formal interview process.
I have had to interview for jobs, but the four jobs I have interviewed for since 2000 were all in response to requests to join companies, either from friends, or (once) from an internal HR employee (and to this day, I have never found out who gave him my name).
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.
Dang those are amazing connections.
Even with good connections I can only get my CV to the top of the pile and maybe some more leeway from the interviewers (which is a lot!), but never was I just skipped through the whole thing and gotten an offer.
You have some good friends are they are high up the chain I guess.
Well, I have only had 3 jobs after the first one... I tend to stay at places for a while. My first company was shut down suddenly by the parent company, and I was recruited by a consultant we had worked with to join a startup he had joined.
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.
I think interviews and code challenges have to be be decentralized and unscientific. Assessing likelihood of success in a software engineering role is genuinely difficult; any single well-known credentialing program is going to generate experiences of its graduates being incompetent in the wild. And then no one will trust it anymore.
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.
I've interviewed people with computer science phd's from schools with good reputations that couldn't program worth a damn when it came to some simple algorithm and practical coding questions in person so, I don't have a lot of faith in certs/degrees for this.
Computer science PHD is to professional programming what a food science degree
is to being a head chef: the wrong credential to rely on, even though it sounds
related and is somewhat transferrable.
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.
I could see this being ok if the certs were retaken regularly. Passing a cert at one point in time doesn't mean you've retained all the knowledge that cert is suppose to assess after some time has passed. This is essentially what TripleByte does for its process to find good engineers for startups.
These types can't usually think clearly under pressure. Besides, answering coding questions is very, very different from inventing those algorithms. It's a completely different way of thinking. That's why.
But does that mean they're bad programmers? I don't think so at all.
As a young person, we grew up with the internet so we're conditioned to just know the "pointer" to the information and then have to google/search for it.
Now I've learned all the algorithms and data structures at uni too and passed the exams but what remains are the names of them and roughly when they are needed. It may be unfortunate but that's what it is like to study nowadays. It's all about cramming everything into your head and passing. Distractions absolutely everywhere and anxiety that we won't live up to and have the lives our parents had.
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.
I could spend a day doing the hackaton project or I could spend it teaching basic computing to someone who thinks himself an expert and is unwilling to learn. But I can't stop time, so can't do both.
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 agree pressure can play a part, but thinking clearly under pressure can be a very important skill to assess in a candidate depending on your company. For a high growth startup, there is often a lot of pressure to deliver effective code quickly. I also think retention of knowledge plays a large part.
I'm currently working on an old cad sort of program, its a mess, 20 years of kludges. Working on it is hard - you have to keep all this stuff in your head and I keep saying why the f did he do that, as expected really. Recently I had to add a new bit and use some computational geometry algorithms, it was like a step into a clear dark pool, everything was ordered and nice, which is probably the world of the phd.
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.
No the general sentiment is that the interview process for software engineers suck but almost no one wants to take a chance trying to develop a new way to interview. It’s somewhat understandable though since devising a new process can’t be to people focused less you inherit too much bias from the interviewer, nor can they be boiled down to a objective metric or else people may fall into inflexible dogmatic practices that use metrics that don’t directly or accurately measure a candidates ability to perform the job applied for
> almost no one wants to take a chance trying to develop a new way to interview.
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.
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.
That’s truer and truer the more generalized the position/hiring pool. “Developer at GiantCo” will end up doing leetcode interviews by default. Cofounding as a technical founder will be pretty much all about personal fit. Between these two extremes is a wide continuum (smaller companies, tech positions at non-tech firms, freelancing, consulting…) that’ll have different processes for finding a fit between someone with a problem and someone proposing a solution.
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.
I think Leetcoding is a worthy investment for career. Why not .
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.
> 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.
I have to agree with parent comment. Leet code interviews, while sometimes obnoxious, are still good exercises. I have learned a lot of nuanced takes from a leet code interview with an interesting question.
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.
>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.
Just be aware that by doing so you are ruling out a huge swathe of companies, typically the ones who pay much more than the rest [1]. It’s fine to do so, money isn’t everything, but I think it’s worth being aware of the trade off. FWIW I think any reasonably competent developer can master Leetcode to a good enough level in maybe a few months (outside of work)… The Manning Grokking Algorithms book is a nice simple intro.
Bad move imo.
You're only a junior, you have your whole career ahead of you. You're ruling out more than 50% of companies by deciding not to do live coding on an interview.
> But maybe I'm doing it all wrong, and I should stop working on this to practice leetcode.
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’ll have to write a full post about it sometime,
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.
If you’re looking to get hired as an individual contributor somewhere else, maybe you should. But judging from this and other posts of yours, you’re not, so you’re probably not doing it wrong.
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.”
Well, that screed I wrote, is a fairly typical "geeky conversation" that can be invaluable, in an interview.
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.
I currently started a basic iOS project with SwiftUI and it is just utterly painful to work with. I kinda hate mobile development because of this reactive roadmap shit. Why would anyone code a UI. I’m old now and I realized I’m getting resistant to changes.
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.
I’m not really up to doing that kind of write-up. However, I did write this series[0]. Some of it might be a bit “dated,” but it probably has what you want.
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].
I think you’re missing the point of the parent post. In terms of an investment in your career, if you’re optimising for money, it’s hard to argue that learning to do Leetcode can have huge returns. Whether it actually makes you a better developer is a different issue entirely
> I think you’re missing the point of the parent post.
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.
Even though I had other means to get into BigTech and still stay hands on technical, if I didn’t, I definitely would have spent 3 months “grinding leetCode” to get a six figure increase.
I’m lying, I would have hated working for any large tech company as a software developer after spending decades at small companies.
Totally agree with this, although I do see some more alternative methods used by non FAANGS (e.g with f5 it felt like they actually tried to determine my actual knowledge as a SWE). But solving a few Leetcodes every now and then (even outside of interviewing season) is probably a very profitable habit.
In theory that’s what TripleByte was supposed to be, but it didn’t really work out in practice. At best being screened by them got you past an initial screener call but you still had to go through the full gauntlet of interviews at most companies. Then they realized they weren’t making money and started doing shady stuff with personal data: https://news.ycombinator.com/item?id=23279837
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.