This was a great read. Some commenters discussed the nature of the interview, and compared it to today. But personally I get this feeling that this was still in a time when software was developed mostly in bubbles. Knowing how to code was far less obvious back then than it is today, and knowing the right stack meant you could get hired on the spot. Also, I don't know of it's nostalgia, the way it's written or something else, but it feels like a lot of engineering stories from that period have a certain sense of pioneering or discovery, while it's definitely far reduced today.
It wasn't until the late 2000s when programming became easy enough for the mainstream and you started to see "coding camps," upwork and the like.
In the mid-90s, you had crazy demand for development but needed to be a brain surgeon to get hello world to work, let alone a website to be remotely reliable.
There was no automated testing, let alone CI.
Source control was sometimes used, sometimes not. There were LANs but there was no "web" let alone SaaS apps - there were maybe 1,000 websites and Yahoo! listed them all in a list. It was like Product Hunt, but even smaller.
You almost have to wonder how anyone learned to code? and you'd be right for asking: it mostly happened in top-20 colleges and a handful of companies. I remember showing PhDs about PKZIP and having them not believe it was possible to compress data without losing information - I had to literally show them the (rough) algorithm.
Truly, it was a time of magick.
(I don't miss it: the pay sucked, people treated "programmers" like crap, it was often impossible to reproduce issues, and of course you could only work in an office with dedicated hardware. Compared with today, it felt like the stone age of software development.)
> I remember showing PhDs about PKZIP and having them not believe it was possible to compress data without losing information - I had to literally show them the (rough) algorithm.
They were right; that is a well-known and trivial-to-prove theorem about lossless compression.
Lossless compression works because you only apply it to very particular types of data. It doesn't and cannot work on general data; that's why we have specialized compression algorithms for every different kind of data.
I took graduate compression in the mid-90s.. JPEG was already invented and we studied that.. there was some handwaving but it was not as primitive as some comments make it out to be today
of course -- JPEG includes means to adapt to the image data patterns, however, which is mentioned in these threads as architecturally important to useful lossless compression, too. (did you really think that 'JPEG is lossy' is more than a 'gotcha' reply?)
I did a CS degree in the UK in the late 80s. The introductory language was Pascal running on a Prime Mini Computer. ANSI C had just come out, but none of us had computers. You had to book time in a lab. The Aztec C compiler we used was on a floppy disc and horrendously buggy. All the coding we did was minimal exercises.
I didn’t even hear of object oriented programming until the 90s, and actually learned how to write useful programmes in Perl and C on the Sun machines at my first job. I learned Unix from scratch from the man pages. It was a different era.
Jobs were a lot more local, too. People didn't move around as much. In general, not just in software. You also couldn't just spend a couple minutes and get a ballpark for what employers were paying in another city, let alone get a decent sense of what a bunch of markets looked like—it'd take some real effort. Reduced mobility and information being much harder to come by kept salaries lower, I expect.
Was it? In 1995 I was shocked to discover what the “computer guys” were getting paid, and decided I ought to be writing code (etc) as my official job instead of just the thing I do within my other job.
There's a recent novel by Tamara Shopsin called "LaserWriter II" [1] that gives off that "sense of pioneering or discovery" feel for all ~200 of its pages. I highly recommend it if you're looking for a quickish read.
I think this is just an artifact of the pioneers/total body of engineers: having the numerator stay relatively unchanged but with the denominator exploding.
>I should pause here and point out that an interview at Apple was an all-day affair. Pairs of engineers would meet with and interview me for perhaps an hour. The first pair of engineers might grill me on some esoteric topic like code design, afterwards the next pair of engineers would sit down and maybe cover programming language specific questions.
This took place in 1995, and sounds pretty much exactly like a technical interview panel today. Were people similarly disgruntled about the process back then? The author certainly doesn’t come across that way.
I interviewed at Apple in 1987, and it was an all-day interview, but it wasn't much like the technical interviews I've done in more recent years--the ones characterized by brain teasers and whiteboard coding. There was none of that in my Apple interviews. They made me an offer and I worked there for ten years.
Now, we can't conclude from that whether Apple has adopted whiteboarding and brain teasers generally. In those days Apple did interviews the way they did everything else: each group at the company did things their own way. I don't know whether that's true anymore; I left Apple in 1998. All I know is that I interviewed with them again four or five years ago, and that was a lot of interviews over a couple of days, but still no whiteboarding or brain teasers.
The first time I encountered what is now referred to as the technical interview was at Microsoft in about 1990 or 1991. I bombed it. Turns out I'm worthless at whiteboarding and brain teasers. They gave me an offer, anyway. Two, in fact. I turned down both. Microsoft would have made me a lot of money, but I didn't want to work for those guys.
That pattern repeated several times over the years: bomb technical interview; get offer anyway. Finally I just stopped doing it. I don't like it and I don't think it measures anything relevant to my work. If it did, why would I get offers after bombing those parts of interviews? Why would most of my employers be people I've worked for before? Why would they ask me to work for them again?
So, generally speaking, I just don't do those kinds of interviews anymore. If you believe in them for hiring, knock yourself out. We're not a match.
I can’t speak for anybody who made you an offer, of course, but often these kinds of problems are just another way to witness first hand how the candidate goes about solving problems. Failing to solve the problem given a short window of time is indeed not relevant, but your problem solving process is _extremely_ relevant. I’ve spent a lot of time fixing crap because some engineer was engaging in “magical thinking” that the cost of not doing such screening is clear. Brain teasers can be hit or miss, so I don’t particularly like giving those to candidates (though as an interviewee I loved them), but you can get a great idea of someone’s appetite for doing the mental work of problem solving through a thoughtfully-designed code screening.
I covered this in another reply, but if you use this process to see how I solve problems, you will conclude that I don't. You will witness me doing nothing, because I can't do anything in that circumstance.
Edit: nevermind, you already wrote about this elsewhere. Leaving the below here for context.
I'm curious, is this more of a social block or is it specifically the work medium (e.g. a whiteboard) that gets you blocked? I personally would happily let you use a laptop with whatever tooling you're most comfortable with, for instance. IMO whiteboards are okay for communicating high level architecture/ideas but abysmal at writing complex solutions (and IMO whiteboards imply you ought to have memorized the thing because of how punishing it is to need to rearrange content).
This is the claim, of course, that solving the problem is not what matters.
However, in practice, it is what matters, There is a "minimum" threshold (I can attest to this because I've been on the other side having to conduct them) where you more or less, must finish at least with some viable answer - even if unrefined - or you won't be moving on, full stop
I mean, sure, if you boycott the question you probably won't move on. But I'm not sure I want to work with someone unwilling to be curious or participate in problem-solving together. To me this filter is a positive effect of the test. In the interviews I've given I'll even handhold an applicant through to the optimal solution if need be, because to be perfectly honest I'd much rather have a coworker who is enthusiastic about learning and shows the ability to collaborate than someone who can write code but refuses to do so in a social setting (i.e. an interview). I want someone that I can have an intelligent conversation with because _I need my ideas validated, too_.
> refuses to do so in a social setting (i.e. an interview).
Interviews are very different from working together collaboratively. They're very different from presenting work to or working with a client or stakeholder, too, and even very different from a sales presentation. The space of things that might come up is effectively unbound, how you're being judged is wildly uncertain, you are being judged, and you know almost nothing about the people you're "working with". As practiced in software, they're closer to being called in to give a thesis defense without knowing in advance which thesis you'll be defending—and also everyone in the room is a stranger, and also you have no clue which aspects of your performance are being judged or by what criteria, and even know for a fact that some of the people conducting these have completely opposite opinions about which behaviors are desirable and which are "red flags".
I don’t think based on what I’m reading here that this is a criticism of coding during interviews so much as it is a criticism of candidate-hostile atmospheres in general. I’d also point out that social interactions are predicated on judging each other, and that this is healthy. It’s also not all one-sided. As an interviewee I choose to approach interviews as a process of satisfying my own curiosity and the curiosity of the potential employer about our viability as partners. That process doesn’t have to be a negative experience, and I don’t think a code screen or brain teaser really contributes directly to whether it is or not.
> In those days Apple did interviews the way they did everything else: each group at the company did things their own way. I don't know whether that's true anymore;
It sounds like you're misevaluating your technical interview performance. You can feel like you're "bombing" an interview, while still performing above expectation. Some interviewers ask hard technical questions, don't expect most candidates to complete them within the allotted time, and give "hire" recommendations for some (but of course not all) that don't.
I can see why it sounds that way. Let me supply some context.
I cannot answer any question in conversation with a stranger unless the answer is something I happen to know off the top of my head, or the question is about what I can see or feel or remember in the moment. It's related to a general sort of cognitive disability I have that shows up in several other ways.
For example, if I'm driving and you engage me in conversation, we will get lost. Every time.
If I'm playing a multiplayer game with voice chat, and people are talking to me, I will lose.
There are just certain cognitive activities that I cannot combine successfully. The presence of a stranger in conversation forcibly occupies all of my attention. I am unable to think about anything other than interpreting the stranger's utterances and preparing my own. If I try to, for example, answer questions about FizzBuzz that require me to actually think about how things work, my mind goes completely blank.
"I'm trying to think, but nothing happens."
I presume that in each case where I received an offer, it was because the team had information from other channels that made me attractive. I know it for a fact in a couple of cases.
So in recent years I've mostly relied on those other channels, and just skipped the so-called technical interview. All it's going to tell you about me is that I can't do what you want me to in a technical interview.
Interesting. I have this exact same problem. I gave up applying for regular jobs eventually as it was so demoralizing. Only work contracts through contacts now. It pays the bills, so I can’t really complain I suppose
You're definitely not. I often hear people describe it as multitasking. My wife excels at multitasking but I perform better having my complete concentration on a specific task (the one exception being listening to music).
I can't even have the TV on for "background noise" like some people like to because you can guarantee it will completely take my focus away from whatever else I'm trying to concentrate on.
This is the best argument I’ve heard against whiteboard / leetcode interviews. A lot of people have trouble talking and coding at the same time, it doesn’t make them less smart.
I'm pretty sure choking is behind most of the "LOL I caught a faker" stories from interviewers. I think it's far more common than people who've somehow been employed multiple places and can "talk the talk" but can't actually handle a for-loop. Most of them are just choking, under a very particular kind of pressure that's pretty much only ever encountered in interviews[0] and certain academic situations.
Like, there's the trope of the kid being called to the blackboard and not being able to solve some trivial problem even though they're not an idiot—and it's based in reality. IDK why we assume that reaction must be rare among adults.
[0] In certain kinds of tech interviews, to be specific. Somehow most of the rest of the white-collar and professional world gets by just fine without these kinds of hazing rituals.
How about, "I’m just going to take this question home to my office and work on it while out of all contact on no specific schedule so that I am not involuntarily preoccupied by my perception of a stranger watching me?"
No? I thought not. That’s why I simply avoid those kinds of hiring processes.
I think a good interview puts you in a position where you are struggling and out of your expertise - being able to demonstrate you have a solution for a bunch of stuff is less important than being able to demonstrate how you do when you don’t know and have to figure it out.
In the general case, maybe you're right. In my specific case, "struggling" and "out of your expertise" doesn't describe it. It doesn't matter whether your question deals with my expertise or not; if it's technical and it requires me to actually think about it, I will be unable to answer in an interview setting. My mind will be completely blank.
Now, that's just me. Maybe I'm completely unique. Maybe there aren't any other programmers like me, and maybe nobody has to care about my individual quirks.
I don't have to care about them, either, because there seem to be enough people in the world who want to hire me. The only attention I need to pay to it is avoiding technical interviews to the extent that I can.
As a rule, when interviewing, I want to get to the boundary of a candidate's knowledge quickly. Questions they ace provide not much information (once it is established that they ace them), questions where they're totally out of their depth neither.
A bit provides maximum information when the chances for 0/1 are fifty/fifty.
So, agree with the sentiment
> a good interview puts you in a position where you are struggling and out of your expertise
as long as you are still at the boundary of your expertise, and have a realistic chance to make some progress.
> Questions they ace provide not much information (once it is established that they ace them), questions where they're totally out of their depth neither.
Agreed. The aim, for me, is to watch someone (try to) solve a problem and communicate about it. Ideally I'd like the question to rely on some previously unknown concept to see them pick up a new idea and run with it.
One of the best interview questions I ever had started with the interviewer asking me a fairly routine technical question, to which I gave a standard and acceptable answer. He then said, "Okay but what if I took away your ability to do X, Y, and Z - how would that change things?" He did that a few more times in different variations to really see how my answers would change especially as the tools/processes I would be forced to use started to stray from what I knew well.
Does anyone even do brain teasers anymore? I recall them being popular 5-10 years ago but when I did my last round of interviews I didn't get a single one (across full interview loops with 6 Silicon Valley companies)
What changed is the demand grew enormously and in response, as in every other business of life, a lot of people who only have passing interest in it got into it because it pays well.
So now you have companies have to sort through huge pile of mediocre candidates. This causes the process to be very noisy, a lot of screwed incentives and a lot of false positives and negatives.
Applicants are now hedging their bets and applying to multiple places means that they are unwilling to spend entire day in each one. And companies (those that do not understand how important hiring is) also have incentives to spend less effort on hiring.
And developers became much more cynical. Partly because of high demand they are aware of. Partly because companies do not treat them well (like not giving raises at a rate their potential salary is appreciating as the market and their experience changes). And partly because new generations are just much more disillusioned.
I had a person recently refuse to come to 2h interview. Apparently it was too much effort. Good riddance and thank you for saving my time.
Good news is that good developers can still easily find a good job wherever they want.
Bad news is that most people are not good developers and they don't even know about it because really good developers are so few and concentrated in relatively few places. In effect, most developers will never have a chance to work with one.
i don’t think you’re wrong, i just think you may have lost sight of some external factors. in 1995, the market was naturally filled with folks interested in computers more organically. now, software writing is the modern “factory floor” worker bee position. interestingly, a huge part of the field can’t accept that we aren’t especially unique or smart, just able to tell a computer how to process inputs. we take this need to feel as if we are a part of the intellectual class, based on a rose colored glasses view of a time 20 to 30 years ago when the only people that worked on software were all staff+ enigneers. then we create this perverse concept of a “real” engineer, and that engineer is just way more willing to aquiesce to _any_ thing you do, and therefore is a “team player”.
telling someone to interview for two hours, having them decide that of all the offers of interviews they had yours was least interesting with the highest barrier to entry, and you deciding they were at fault isn’t going to help you deal with the modern realities of software, and how far we’ve come for our idealized version of where we came from
> telling someone to interview for two hours, having them decide that of all the offers of interviews they had yours was least interesting with the highest barrier to entry, and you deciding they were at fault isn’t going to help you deal with the modern realities of software
But that is not my goal.
My goal is hire as good developers as I can retain.
I don't care about people bitching and moaning that the process is too arduous. Actually, I am happy about it because I can efficiently swipe left on them. If somebody does not care enough to work for us to put in couple of hours of work then they are very likely not a good candidate anyway.
And if they have to apply to a huge number of companies to get a job there is probably some problem with them. I mean... a lot of companies are happy to put a warm body in a chair. If you can't find a job as a developer in this economy then you have to take a serious look at what you are doing wrong.
> I don't care about people bitching and moaning that the process is too arduous. Actually, I am happy about it because I can efficiently swipe left on them.
And that’s how you know there isn’t really a shortage of developers.
My wife works in a field with a real shortage. When she gets interviewed, they fly her out and spend 2 days showing her around, taking her out, and trying to convince her to work for them.
Does your wife belong to some kind of professional guild?
You'll find most other high qualification professions require a body to certify them, conduct examinations, disqualify them for poor outcomes, organise ongoing training and so on. And most importantly (for guild members), limit numbers and ensure the government makes it illegal to conduct activities unless you are a guild member.
Developing has none of this - it's the unwashed masses. You get the full bell curve from useless CS graduate to genius high school dropout all applying for the same job, and everything in-between.
> When she gets interviewed, they fly her out and spend 2 days showing her around, taking her out, and trying to convince her to work for them.
This exact scenario has happened around a half dozen times for me as a software engineer over the past twenty years. Basically any time I’m considering a company based in another US state, they fly me out for interviews, at least take me to dinner (if not some larger group outing), and then have someone show me around the city the next day trying to convince me to move there.
I’ve flown out or drove long distance for many software developer interviews and I’ve never had anyone “show me around” the city. Although they’re usually fine providing an extra hotel night so I have time to do so myself. Sadly it feels like post pandemic the on-site interview (at least for software engineers) may be a thing of the past.
There is a shortage of actual developers. But there is no shortage of people who don't care about what they are doing or whether they can do it at all.
When you are looking through piles of thousands of people, you are looking for ways to pare it down so that you are left at every step with higher concentration of the first group. Because spending same amount of effort on everybody is not a viable strategy.
> There is a shortage of actual developers. But there is no shortage of people who don't care about what they are doing or whether they can do it at all.
In nearly 20 years of doing this I’ve have never had one of these dreaded fake developers make it through the resume screen, initial phone call, and a conversation with an engineer.
And if I did, we’d just fire them as soon as it was clear they lied about their ability.
I have had plenty of the other extreme, very technically proficient developers who turned out to be terrible employees for other reasons.
My initial point is that if you can afford to make your screening process arduous enough that you’re turning away otherwise qualified people because they don’t want to work for you bad enough to jump through your hoops, then there’s not a shortage.
If there was really a shortage, you’d do what every other industry does. Hire based on resume, and fire the fakers.
> In nearly 20 years of doing this I’ve have never had one of these dreaded fake developers make it through the resume screen, initial phone call, and a conversation with an engineer....And if I did, we’d just fire them as soon as it was clear they lied about their ability.
I've spent most of the last 25 years working independently. A large number of the 'fakers' (or just... currently-low-skilled) don't apply to large companies with screening processes. They build custom one-off software/websites/etc for small businesses. Those small business people have no ability to judge skills or quality. Some of the tech folks doing that may, at some point, try to apply 'up' in to larger companies, moving away from independent/freelance, and some of those may get weeded out.
Your goal is to enable your business to make more money, that requires hiring enough competent people that can do the work that needs to be done, to make that money.
Sometimes that work is really not especially interesting, or challenging. Nobody is going to love it, or be passionate about it, and it really doesn't require a person to be more than average in terms of skill, because it's just not that technically difficult.
And that sometimes is the majority of all salaried work, so statistically speaking, that's probably also you and your company.
Why pretend to be a unicorn and only insist on hiring passionate self motivated people who will be a bad fit anyway, and be bored after two weeks.
The hiring process is not for stroking the egos of middle managers who want to feel special.
I am not pretending to be unicorn by keeping high hiring standards.
It is a reflection on our strategy. Our strategy is that, long term, is better to have smaller, tight knit community of highly intelligent, capable and motivated people than try to throw masses of lower paid employees at the problem.
We are fighting complexity and having large team of constantly rotating people that never seem to bear responsibility for their decisions is one of the worst things you can do.
I prefer to spend more time on hiring, find people I am satisfied with and then pay them well so that they are not looking to change their job in two years as most IT seems to be doing nowadays. Retention is a hugely underestimated success factor.
Highly intelligent, (technically) capable and motivated people are probably not in any way correlated with the amount of complexity you are needing to fight with. And if it is, it's most likely negative.
Lack of intelligence is probably not your problem, the computer genius who swoops in and saves the day only exists in movies. You are probably in a much bigger need of accountable management who actually structures the work and aligns the team by making decisions.
There are plenty of reliable, mature, productive people with great team work and communication skills, who will get rejected because they say that they are actually passionate about playing guitar, not programming, and because they can't solve esoteric programming problems on whiteboards.
Your hiring process is not optimised to further business goals, it's optimised for acting out the big bang theory in the workplace.
Yeah, I'm speaking in general terms of the software industry, and common hiring processes, which according to your comments you seem to fit into pretty well.
I don't mean to criticise you but rather suggest that the hiring process should focus less on intelligence and coding skills, and try to hire people that have intellect. That can pair judgement with intelligence. That can relate decisions to goals beyond their own personal preferences.
I have too many bad experiences with highly intelligent, but myopic and immature software developers who are left to "self organise" and just end up being lose cannons of raw intelligence, that does much more harm than good.
Software development, is more an organisational problem than a technical one.
The organisation itself is already so vastly complex that no human being can comprehend it, and that's why you have a hierarchy of information and specialisation of roles. Even if your system by some miracle has zero accidental complexity, it's still going to overwhelm even the most intelligent person, just by the amount of essential complexity. So you will need an organisation of hierarchy and/or specialisation to manage this. And the biggest determining factor for how successful you are, is this organisation and how it works as a whole, rather than any individuals superior capacity.
I just think it's a really bad idea to try to hire "extra smart" people to try to solve these issues, because it won't work.
I think you have some good understanding of parts of the problem but the ease with which you generalise is dangerous.
Getting from "I have too many bad experiences with highly intelligent, but myopic and immature software developers" to "I just think it's a really bad idea to try to hire 'extra smart' people (..) because it won't work" is pretty poor logic.
I think much better and productive statement would be "Hiring intelligent people is not enough to solve the problem."
It is much more productive because from there you can go to actually discussing what else is needed to make good use of highly intelligent people.
What I'm trying to say is: it's a bad idea to hire extra smart individual contributors as a solution to managing complexity, because nobody is smart enough. The cult of genius makes the workplace dysfunctional and inefficient.
That extra intelligence is mostly irrelevant, and sometimes negative.
Managing complexity is done with hierarchy, specialisation and careful organisation of work from accountable managers. You want this organisation to work well, and then you want to hire people who can do an acceptable job and function well within that organisation. And if you are still finding yourself in a chaos of unmanageable complexity, the organisation of the team is to blame.
The hierarchy, specialisation and organisation of the work is not done well enough, and must be fixed. You don't need more horsepower when the steering of your car has broken, that's just going to get you in the ditch faster.
>If somebody does not care enough to work for us to put in couple of hours of work then they are very likely not a good candidate anyway.
[emphasis mine]
You compensate candidates for their time? I certainly assume you are compensated to interview incoming candidates, but its unusual for the candidate to be compensated (though not unheard of).
I agree with a lot of what you're saying, but I also get the impression having not been on the other side of the process recently has biased your viewpoint significantly. Please correct me if I'm wrong in my assumptions / impressions.
Interviewing is a mutual process. The company invests time and resources into finding employees and candidates invest time and resources into finding a good place for them to work.
I see no reason to compensate the candidate for the time they spend on interviewing and when companies do this I see it as a desperate marketing gimmick.
Now, I assume all is done honestly. I put up an honest job offer, I explain the interviewing process upfront, I try not to waste candidate's time and certainly I do not ask people to do any take home exercises.
And since I started to do all interviewing remotely there is even less cost to the candidate -- basically they only need to spend couple of hours on interview alone and no travel.
I also try to put largest filters at the beginning of the process so that if you pass first interview it means you are likely on a good path to get the job. This works both ways, incidentally -- as I would prefer to spend more time with candidates that are promising.
Do you interview one single person at a time for the job?
That's what has killed my desire for interviews with certain companies at times when they bring up long interviews as the next steps.
If I have a company say "the next round will be 3 hours of interviews, we're going to wrap up this round on all candidates then move on" I will 100% drop the interview process and not move forward.
On the other hand, if a company tells me "the next round will be 3 hours of interviews, you're currently the only candidate we are interviewing for this role" or "we're interviewing multiple people but have multiple roles open" I will gladly continue the process. (This is a question I always ask in interviews.)
It essentially comes down to "why waste my time continuing with a company when the end result could be 'oh we found someone that we feel is slightly better than you, but you're our backup'".
Have I given up on some jobs that would be cool? Yep, but I'm not going to waste my time with a company if they use a shotgun interview approach that will take my time and essentially turn it into a lottery system for them to pick from.
But programming is special! The same approaches to hiring used for accountants or electricians couldn't possibly work! Don't you know programming is like painting? That's why we make people regurgitate algorithms they memorized in a high-pressure situation, while pretending they didn't memorize them. It's just like painting. eyeroll
Yeah, people kinda forget that not every job is the same.
You can pretty much easily test if you have enough knowledge to be a good accountant or if you can play the violin well. There are couple smaller issues. Having knowledge will not tell you if they are hard working a knowing how to play violin well will not tell you if they will do well with orchestra and large audience. But in general you can do a testing period and be done with it.
With developers... the main issue is that it is super difficult to judge how good a developer is and that is IMO mostly because there is a huge delay between making a decision and suffering consequences of the decision and then it is frequently difficult to tell how the consequences are connected to the decisions and what were the alternatives.
And a lot of it is just opinions, so even if you hire a better developer you get into territory of trying to figure out whose opinion is right (probably the higher paid one? maybe?)
And so when I hire developers I am trying to look at various other things that I hope are proxies for what I really need. So maybe I will try to look whether they have good judgement in general, how they dealt with difficult situations in the past. Maybe get to know them a little bit as a person.
Which you don't have to do with an accountant or violinist.
There's no good test. Otherwise, that would be the interview process.
Usually, it is just others' opinions of you. You might try a bunch of different jobs, be bad at them, but eventually find a great fit where everyone respects your work. Those prior opinions don't really matter now, do they?
One of the other key problems why it's difficult to answer is that the standards of development change very rapidly. You'd likely find the same questions in the spirit of "what makes a good punch card developer?" when those systems were around. There were probably a lot of interviewers with a lot of heuristics to hire the best, but those specifics don't matter any more either.
And sometimes, it comes down to simply marketing yourself well or having good salesmanship or playing office politics.
It is an excellent question. Having an answer to it would be very valuable and I spent a lot of time thinking about it but found no conclusive answer. Sadly.
First of all, I do not condemn people trying to do their best to legally provide for themselves even if it means trying to get the job that they are not qualified for (as long as it is legal). Just look at our politicians. I might take an issue if you are straight lying about facts and your abilities.
But at the same time I think I am fully justified to politely refuse to be the sucker that hires them.
One reason you may want to know if you are qualified for the job is if you want to stay there for longer. Sometimes for some people stability over long term pays more than constantly getting jobs that are just above your level.
Keep a personal resume doc going. List out the projects you’ve done, how you contributed, who benefitted, and quantify the benefit if you can.
Keeping a running list like this is how you can build confidence and see a bigger picture to your career. I did this recently at my current job as I was approaching burnout. It helped me reset that tailspin.
Not an SWE here - I wonder if the process itself is seen as value-creating by either side, even if a job offer isn't placed? For example, discussing code design may keep the hiring party at the cutting edge / state of the art without having to undertake refresher training cost. The candidate also gets to understand where they stack in terms of hiring companies' expectations, and may opt to retrain as necessary.
(I'm reminded of the stories when FB was looking to make a smartphone pre-Oculus - it sounded like they were interviewing candidates but effectively getting design strategy consults out of them gratis, but that's probably more extreme than this).
> Bad news is that most people are not good developers and they don't even know about it because really good developers are so few and concentrated in relatively few places. In effect, most developers will never have a chance to work with one.
Yeah and having an outstanding skill or performance is not important in an average company/organisation, and will most likely give you only trouble. Larger organisations are risk averse, optimised for stability and longevity. Not short term performance. It's not a sports team.
My first interview out of college in 1999-2000 was something like this. A full day interview about designing the components of a TCP-IP stack interspersed with some personality/behaviour interviews. End of the day, you either knew you had an offer or you didn't. I had an offer. I would kill for such an interview experience now.
The last interview I attended stretched across a month or may be more. Glad I got the job but boy what a nightmare.
If someone told me today that I would finish all rounds of interviews in one day and this became a standard, even figuring out for hedging I would take a week off, schedule 5 interviews and be done.
Even fundraising for a startup doesn't take 2 months these days, whereas an interview will. That should tell you how broken the process is.
I would take a 1 day multiple round interview any day. Nowadays, it is like -
- Recruiter reaches out on LinkedIn. You reply.
- Call with recruiter, repeat every thing in resume. Recruiter says ok, sometimes they just say we were looking for X years in Python to a JS programmer.
- First call with a manager (after 1 week) to check fit.
- Take home programming assignment (spend 4-6 hours on weekend).
- If code review is ok, another call to discuss the solution or improve it (1 hr, after 2 weeks).
- Last call with senior manager (1 hr, another week wait)
- HR offer
All in all, it takes around 6 weeks and multiple calls (not to mention doing this for multiple offers). Worst case - you fail at the last round, or code is rejected due to some crazy reason and yes, even after all this you get a 10% raise :D
Europe where? I can assure you every European country is completely different. The tech scene is London is vastly different than Vienna, and so are the wages.
> The author certainly doesn’t come across that way.
1) The author got the job.
2) The author has kept that job ever since, for over 25 years.
Perhaps that was the last job interview the author ever had, in 1995? So there would be little reason for the author to come across as disgruntled in 2022 about 1995. Though the author does go on and on about the "Andy" interviewer...
There's a certain irony to this, because Apple itself was flailing and failing in 1995, unable to produce its own new operating system, and had to acquire NeXT and Steve Jobs to come back and save the company from bankruptcy. So Apple's hiring process was not necessarily producing results.
I think the "Andy" interviewer was key, and was a set up the whole time to see how the candidate would really perform under stress:
1) Previous interviewers set up Andy as the toughest part of the interview, preloading the stress.
2) Andy comes last, when the candidate is tired
3) Andy hits you with that wall of stress. Doesn't matter what it is. The candidate gave Andy an easy task by admitting he was weak on something right away.
The answer didn't matter as long as you didn't fold.
I went through the Apple interview process in 2006, and would say that my experience was definitely not predominantly a "technical interview panel". It was an all-day event, to which they had flown me in to do, and though I was asked technical questions by some of the interviewers, many of them were more interested in how I handled stress, or solved "political issues". A couple of them were more interested in answering any questions I had about what working in the group was like, in a way trying to let me know what I was in for if I got the position.
I got the position, and stayed there for 8 years. I remain relatively close to about 30% of the people that interviewed me to this day, and that concern for letting me know what I was signing up for was genuine. The stress of the job was at times pretty high, and keeping a cool head under circumstances where everything was going wrong was absolutely critical. I saw a number of people who came after me, leave before me for that very reason.
Since then, I've walked out of interviews where I felt like they were wasting my time. But I've also often had the luxury of not really needing the jobs I've applied for, generally, so other people's mileage may vary widely.
It's the employer's job to figure out whether you're a good fit for the position, but it is the potential employee's job to figure out whether you want the position in the first place. Being able to get an accurate read on what you're thinking about going into (and spending a sizable chunk of your daily life doing) can save you a world of hurt.
Provided I'm a significant way through the hiring process spending a day in person with people who seem relevant to he job would be fine provided I liked the company / had confidence in the process / liked the job.
A family member recently applied for a job and got invites for 12 hours of meetings over 2.5 weeks. No sense of where they were in the hiring process. No significant questions had been answered about the job. At least half the people in the invite were not directly involved with the job / HR types ....
I think what people get upset about is how seemingly meandering these interviews are now / interviewing with people who don't know jack squat and so on.
Anyone else remember playing Glider? As a young kid, I gladly lost countless hours trying to navigate a paper airplane through a Rube Goldberg mess of obstacles. What a fun, imaginative game.
Would be cool if there was an emulated version somewhere. Or we could borrow the author’s book and transcribe it to a modern language, ha.
> though not the cleverest engineer, [I] was one that worked quickly to prototype new ideas and took on some of the gruntwork that not every engineer wanted to work on.
This is basically all I want from anyone I work with.
My first manager told me: Grunt work is also work. Someone needs to do it. He was spot on.
What I observe with many founders I interact with is that they want to focus on the exciting stuff. Building the product etc. Most of them don’t want to be bothered with boring stuff like financial planning, which sometimes breaks their necks.
I’m a young engineer and I’m always happy to take on the grunt work to help the team as long as I get a little time to help on big picture stuff as well. I’m worried that I might be looked down on by more senior engineers who might think I’m just trying to avoid the more brain challenging work
A nothing is “someone else’s problem” is hallmark of the true pros. Intermediate folks might run into a broken build and be stuck until the build team can unfsck it. The OGs just fix it.
Very well. Grunt work is very appreciated and it not only allows you to start working without pressure it endears you to the other senior engineers as a can-do person. As they will feel grateful and released from the grunt work they might even start doing direct mentoring. They also will start to get to know you, with all the benefits it brings. That has been my experience in both professional as well as open source development.
Funny I worked there in 95-96 for half a year as a contractor (DTS), and the interviews were fairly simple, the hardest thing was looking at a page of source code and finding all the bugs. Otherwise most people knew the Mac software I had lead or worked on, so it wasn't a big deal. I left because I didn't want to be there when Apple crapped out as seemed likely.
Steve came back a year after I left. Oh well, I might have stayed there for 25 years too.
I really enjoyed this read. The author printing out his source code so he could have a physical artifact signifying the end of the journey for that game really resonated with me for some reason.
