I’ve seen this a lot. Hire older dev. Older dev has decades of experience. Older dev creates new product from scratch in a couple weeks.
Another issue is that mentoring is focused on junior devs by senior (6-8 years of experience) devs. So you’re less likely to have a senior dev (6-8 years experience) mentored by a dev with 20 years experience.
While I’ve got a pretty good memory, a lot of the times I don’t have a direct or complete answer for their question. I’ll have a tingle of a memory that is similar to their question. So I’ll give them that as a starting point and tell them how I’d approach the solving the problem. But they get frustrated that I didn’t solve their problem immediately. That I can’t point them at a blog post of Stack Overflow answer.
But a dev with 1 to 3 years experience? They’ll take that non-answer and run with it.
And I get it. The 1 to 3 probably has 1 maybe 2 tasks they’re working on. The 6 to 10 (to 15) has probably a half dozen things they’ve got to keep track of. Researching is probably pretty low on their list.
I spent hours fixing his code and hand it back to him and it's broken again in a week.
I had to wash my hands of it. The only advice he's getting out of me now is to follow a single tutorial all the way through until he gets that one tutorial working and then compare the tutorial to his code. I'll answer specific questions, but I'm not going to try to mentor him until he's ready to receive the wisdom.
The reality is that half of the tutorials and answers you can find won't work. Either because they're doing something entirely different or because they're for a tool/framework that's deprecated the functionality.
A beginner won't be able to tell this simply because none of the pieces are known to them.
When a person with more experience finds these tutorials they'll likely know within seconds if a given answer or tutorial is even remotely applicabe, which enables them to be much more thoughtful about what to do.
You'll potentially waste weeks on trivial tasks if you're hellbent on actually fully understanding something right at the start, and if the beginner does this the more experienced ppl will complain how inapt they're.
Honestly, you both just sound like toxic people in that regard and should not be allowed to work with total beginners. Which is fine, but the issue really isn't with the pupil that's just clueless. They need somebody to give them a tutorial and guide which is applicable and they'll learn how that piece works, now keep repeating that until they've got a basic understanding of the system and only then can they work on their own
The same. Especially under pressure. Which makes it virtually impossible for me to pass an oral technical interview.
It's crazy. I sometimes get the itch to learn a new language like Rust, but I haven't even come close to reaching the bottom of all the languages I already know. They are inventing new things faster than anyone can acquire them.
Well: I have recently been teaching programming to a 10-year old kid, and this morning he told me about the syntax {X..Y}, which expands to the range of characters between X and Y. I have likely typed {0,1,2,3,4,5,6,7,8,9} a thousand times and now I know you can write {0..9}. I was floored and have it on my todo list tomorrow to see if that is a new feature or if I simply somehow missed it in the man page--which I thought I had carefully read multiple times and which I additionally have skimmed many times--consistently for decades :(.
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.
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.
In my own case, when I have enough money to retire it’s going to be hard to convince me to keep working.
A programmer is told what to do, and half way thru development they have the boss show up and say 'I just read of this brilliant idea in BusinessWeek, lets add/change the code to do .....".
My basic philosophy is that I'd probably be sitting in front of the silly thing anyway. Might as well be paid for it.
Programmers are in a bubble. Head over to the local grocery store. The person bagging your groceries is 63. There is no retirement plan for him - as well as most Americans. These "old" people will end up working until 70, on their feet. If I can find someone to pay me to write CRUD apps all day in whatever hipster framework, I am fine with that, no complaints here. Beats working at HomeDepot.
While brutal, there is something to working later from a health perspectice. When I was young, retirees played tennis and golf but I dont see as much of that in my cohort.
I was contracted to create the backend for a SaaS platform, from scratch. It runs on AWS, using a lot of AWS services, and is django based. The thing is - I'd never used AWS before, nor django. (I'm not sure how they chose me, to be honest.)
Picking all this new stuff up at my age it's nowhere near as easy as it used to be. But the process of writing software is not just learning libraries - and the rest I have down pat now. I immediately set designing the data structures and databases, wrote a spec based on those structures and got the spec reviewed before I started (I had to pound the table to make that happen). Then head down, arse up writing code as fast as I could. I had to deliver it all without an AWS platform to run it on, or a front end to drive it - but you don't get to my age without knowing a thing or two about unit effective testing.
Then after delivering, I was told it had all been changed by the UI guy, so massive refactoring. Unit tests are worth their weigh in gold when that happens.
All the while I was told I was talking too long, which ramps up the pressure and self doubt even more. (But with me muttering - what did you expect when change the UI I had based the spec on without telling me, ffs.) Boy do you lean on unit tests when that happens.
Then the first code drop, which was few tens of thousands of lines of code done in a few months. Which if you crunch the numbers, was 20% of the size their existing code base, delivered by one guy, in 5% of the time it took several people to develop the existing thing. Bug rate after unit tests was below 1 bug per 5k LOC.
Turns out they were begrudgingly impressed by that. So right now it seems I still can match it with the young guys. Yes learning new stuff is harder and slower, but I make up for it very efficient software methodologies honed over decades, which when I can apply them for a few weeks straight leave them in the dust.
The way I feel now it seems when I'm 70 pulling that sort of stunt will be impossible, so I don't have too many more job changes left in me. But at 50, you have a while to go yet son.
https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
There is also a massive increase in the number of 25-35 programmers in the same time period.
My interpretation is there are definitely forces that push against older programmers staying in or re-entering the profession, but they aren’t as severe as they appear to be just looking at the raw numbers. Generally, programmers who want to remain the profession are going to be about to, but it is harder to be a programmer over 40.
This is especially tempting if someone’s skills start to diverge from what’s in demand.
The number of "jobs" added doesn't quite double, but if we think of it as "for every 4 that retire, five take their place" it would definitely feel like what you're saying.
Same. In my case, I paid my way through law school doing software development contract work, which paid better than entry level lawyer work. Now I do a mix of software consulting/contracting and IP technical expert work (patent/copyright infringement analysis, claim charts, etc). I enjoy doing both kinds of work, though I really enjoy legal writing and I'd like to get more into IP litigation, writing pleadings, motions, oppositions, etc.
For most of my career, I've been told (and I believed) that I would probably get forced out of a hands-on individual contributor role as I aged. During the late-2000's, I even had an early midlife crisis and earned a law degree, expecting that I would need to make a career change into IP or something. That hasn't been the case.
What I think people missed is the compounding effect. The supply and demand for computer programmers seems to double every decade (maybe the interval is even shorter). With each doubling, the older cohorts become a smaller and smaller share of the whole. People look around and think, "There aren't many older programmers here", and base predictions off that observation. However, the more accurate observation would be, "There have been A LOT of younger programmers added here!". I don't believe that it's actually a zero-sum game, though.
I don't know if this human resources cousin to Moore's Law will continue indefinitely, but it's certainly held up through my career. Even when it inevitably slows down, I think that just means you'll see the age cohorts balance out more over time.