One of the things I learned in the classical music world is that the things we ask people to do in auditions–play the hardest parts of all the most difficult orchestral music without any context–is really creating a new problem that doesn't need to exist.
And in my experience listening to auditions over the last several decades, what you have now is a bunch of musicians who can only do what's on the test. When you try to plug them into an orchestra, they are completely fucked.
My experience interviewing and hiring tech people is that this is one of the worst possible approaches. Anyone who needed to could figure this out. It's not relevant. What you need to figure out in an interview is if the person is curious enough to find the answer.
I don't ask for code or algos in my interviews. I ask about the person. What's your favorite programming language? Why is it your favorite? What do you not like about it?
What's the project you are most proud of? What was hard about it? What made you happy? What did you find challenging about that project?
These are 100% totally humane questions that tell you everything you could possibly need to know about a candidate in about a half hour. Maybe less.
If you can't figure out if this person is technically competent from this set of questions then you aren't competent to interview or hire.
Interviews don't have to be only about how good you are at interviews. They could be about trying to understand if the person would be good at the job and fit in well with the team.
I think your approach is fine, but I should mention that it will, like any interview approach, misfire with some people.
Episodic recall and emotional recognition are both talents that vary across the population. If I want to do well at an interview like this, I will have to spend a bunch of time in advance refreshing my memory of various projects I have worked on so that I can simulate a neurotypical response to those questions. If I don't, I may just stare at you nervously and break out in a sweat when I realize I don't have anything filed under, "project I am most proud of". Or that pulling up the narratively engaging details of a project I haven't thought about in years is a process that will take me hours of specific effort. And it's not just me; I've hired great developers who were also terrible at "humane" interview questions but who did great when we just sat down and coded together.
This very thing happened to me recently in an interview. This was my first interview after not having actively interviewed for a few years now, so I was quite rusty. I was asked what some issues were that I worked on at an initial phase of the project and I blanked the fuck out and then instantly went into self-scrutiny and sweating as I spiralled into "oh crap I should really know this" and "this is making me look stupid" and wondering how I was coming across to the interviewer. I have some anxiety problems, that's there too - but point is that if you're not really prepared with answers to questions like these, it can seriously throw you off mid-interview.
And lots of good developers skew anxious! What in normal life counts as being overly careful or or overly sensitive is just good practice in coding.
That's why I think it's especially important to make interviews as low-anxiety as possible. They'll always be worse than the job, of course, but the closer you get them, the more you're likely to see how people will really perform on the job.
I too have to prepare for such questions. I thought everyone else also did.
Not only do I not remember past successes very well, preparing for these questions is literally the first time I asked myself what I'm proud of. I didn't even consider doing this and reject it as irrelevant before. It just never came up.
I have arbitrarily terrible episodic memory, especially so for professional stuff. If I don't have the commit history to check, I have trouble describing what I did in the last month in anything like a lucid level of detail.
I've always had trouble with the kind of behavioral interviews that are "Tell me about a time when . . ." since I can often recognize that I've been in relevant situations but can't for the life of me remember the details (even with time to prepare).
This honestly makes me more nervous about interviews than leetcode shenanigans. At least with those, I know how to improve.
(At work I rely on a combination of having the code in front of me, written notes, and whatever project management tools we have so it's not much of an issue, but most of that isn't available to me in an interview setting.)
I agree this is true, but I think that's in contradiction to the notion that one can just ask some breezy "totally humane questions" and then make optimal hiring decisions. The more separate the domain, and the more preparation helps, the more you're testing for something pretty different than the work.
You don't make "optimal" hiring decisions by just talking to someone. I would say whether your hiring decision was optimal can only be judged in hindsight. Hiring is getting a limited pool of people and filtering down to find the ones that fit the role most.
In the end all you could actually do is guesstimating who would do best at the job. And sometimes the answer is: "none of the ones who showed up".
If you are a good engineer or programmer yourself you can tell a lot about a person by talking to them for an hour. You can learn what is important to them in the craft, how they deal with criticism, what they aspire to, what kind of problems they tend to work on, if they are more autodidactic or more influenced by other's opinions and so on. This is all knowledge directly inpacting the question whether they are the right person for the job.
And who the right person is depends on the job, so there might not be "right" answers to the questions. For a very niche database job you might actually want someone who is very accurate, very in the detail and very focused. For other jobs maybe some entirely different traits are better.
Of course the problem here is that the people you hire could just be very good actors or liars who cannot do the things they say, so a little technical testing might also be needed.
I think the issue is that, and I'm paraphrasing something which someone else said but which I think reflects what I've seen, nobody (at least in larger companies) wants to be responsible for a bad hiring decision.
While yes, you can get someone who has a good track record of being a good judge of character to make hiring decisions. If that decision goes wrong and the blame game starts then you inevitably ask this person to explain their hiring decision. This person will then reply: well it was my opinion that X, Y and Z.
In the alternative case where you just get someone to follow a rigid process you can answer: Well he scored well on this exercise and the opinion of the team was in his favour and the work history ticked the right boxes. This effectively dilutes the responsibility. You can no longer blame one person for the bad hire.
Lastly there's also the diversity aspect. With companies increasingly being scrutinized for their hiring practices, "it was my opinion" just gets translated to "this person's internal biases guided the hiring process and as such it was not fair."
I agree this is all making hiring much harder than it needs to be. And certainly you can still find companies where the hiring decisions are made on highly experienced and well honed gut instinct (its the only kind of interview I have been a part of) but it also makes sense how in our increasingly overcomplicated world we are developing increasingly overcomplicated hiring processes.
My recommendation is if you want a sensible hiring process (with maybe a telephone screen followed up by one normal interview) you should stick to smaller and less corporate companies.
Unfortunately, "gut instinct" is just another phrase for "unconscious bias". Sometimes those biases are helpful, some less so. And some can result in hiring results that are unfair enough to invite lawsuits.
I know plenty of smaller, less corporate companies that still use careful hiring processes with thoughtful rubrics. They do that not because of risk avoidance; they are generally still ok firing people who don't work out. They do it because they want to run a fair process while maximizing ROI.
Out of curiousity, did your high school or college teach you much about interview prep?
Both of mine did. Much of their advice was irrelevant (nobody in tech gives a shit about your suit or how firm your handshake is) but they both stressed the importance of preparing in advance to show how good your skills are; and giving thought to cliche lines of discussion like 'what's your biggest weakness?'
I love the comparison to music auditions, and I mostly agree with the advice.
I would still require the candidate however to write some code. Something rather simple, not leetcode, ok, not fizzbuzz either, and something that proves their familiarity with at least one language and platform.
I should be a GM by now simply watching chess analysis videos on Youtube, learning the names of some openings etc. I can talk about it all day long. But since I don't play at all (I'm not interested) when I actually do play on occasions I revert to 500 ELO...
You can easily tell a seasoned veteran from a rookie just by looking at them code for a few minutes, working on a simple task. If you can't, you have no business in interviewing others :)
Aesthetic judgements, and the ability to justify and defend them, are very important, but not the only important thing IMO.
Someone who can explain why they love Rust and hate Python (or vice versa) is a convincing candidate but I think you need to see a couple of other things from them. In addition, sometimes you just don't hit on the right question to get evidence of their aesthetic judgement. (Like the candidate who doesn't care about Rust vs Python, but who hates Postgres and loves MariaDB..)
From what I've seen, getting a regular job in classical music is difficulty and pressure on a level few of us can imagine. Might be easier to get tenure at Harvard than a rostered spot in an orchestra.
I think the odds of getting a high-profile orchestra slot are far lower than that.
Source: Multiple orchestra musicians and management speaking about the audition process and the now-defunct myauditions.com website
Process:
Show early talent
Get the right instruction
Get into a preparatory program
Make it into a conservatory
Do well once there
Get a spot in an ensemble, probably lesser-known (not easy) and establish a reputation
See an audition notice with repertoire to prepare, apply
Spend a few weeks or months intensively practicing (on top of other commitments)
Maybe get an audition, realizing the Music Director may be promoting his buddy past these rounds
Travel at your own expense to the audition
Play demanding repertoire behind a screen and respond to any directions
Most likely get rejected
Play in any following rounds
If not rejected, maybe you get a qualifying week rehearsing with your potential colleagues and playing a couple of concerts when the Music Director is in town
If you beat out the couple of stellar artists who've also gotten that far, you may get an offer
Or, the MD's buddy may get the offer
Or, there may be a no-hire
If you get and accept the offer, you are "on approval" for a couple of years at which point there's the Tenure Decision
One technique I've used as a team lead to limit tech debt that makes it into production is to have devs write prototypes in a different language than what we actually support in prod. This has a few really nice advantages.
1. Devs enjoy getting to use new languages in the real world, and helps keep us learning.
2. The better you know a language, the more tempting it is to take shortcuts. When you don't know a language well enough to write really gross things that work "for now", you have to think carefully about the simplest possible solution to a problem that you can express clearly in an unfamiliar language.
3. You learn tons the first time you solve a particular problem. At the end of the solution, when all of your hacks and tradeoffs are fresh in your mind, you are the best possible person to tackle all the shortcomings and immediately do a rewrite in a language you are expert in.
3. Management really can't twist your arm to just go ahead and transition the prototype to MVP. All you can really do is throw it out there as a public beta with no guarantees while you build the MVP properly using everything you just learned from doing it the first.
4. You can start collecting feedback on what users want included in v1 and get an idea of where the user base is heading with their desires and plan some of that into your design, again reducing long-term tech debt.
If your prototype sticks the landing well enough for management to decide to move forward to MVP, then it's good enough to mark your territory in the problem space while you do the rewrite. You won't lose competitive advantage while it's sitting out there in a separate VPC collecting users and activity.
In a healthy company, this isn't a difficult sell to management. They'll understand the short and long-term value to the company. In more toxic environments, it will look more like you're throwing a poison pill into your dev process—which you kind of are. So, you know, tread carefully. But when people buy in to this process, it works really nicely and has far better long-term outcomes.
> The better you know a language, the more tempting it is to take shortcuts. When you don't know a language well enough to write really gross things that work "for now", you have to think carefully about the simplest possible solution to a problem that you can express clearly in an unfamiliar language.
This has not been my experience. Much of the worst code I've run into was written by engineers that were new to a language or framework (including myself).
To be clear, I am not suggesting that the resulting code will be good. But it tends to be more basic and not rely on weird tricks that deeper knowledge of the language will allow you to do.
My larger point is that the first attempt to solve any problem in code is going to suck, so you might as well suck in a different language that won't ever have a chance of being deployed into prod. You learn some things, you get some exp with a new language, and a better frame of mind for solving the problem in a better way.
Moreover, what's idiomatic in one language isn't in others.
Non-idiomatic code is one type of technical debt, and you can get that when translating code from one language to another.
That's because developers see early-stage startups in the same way musicians see dingy pubs: a badly-paid and generally unpleasant venue to learn your craft and make all your beginner mistakes with minimum responsibility and damage to reputation. You don't want to be playing in dingy pubs all your career, though.
> The better you know a language, the more tempting it is to take shortcuts. When you don't know a language well enough to write really gross things that work "for now", you have to think carefully about the simplest possible solution to a problem that you can express clearly in an unfamiliar language.
I have the opposite experience, the worst performance bottle necks I have had to trouble shoot are from principal engineers (and tech leads) that use medium to high level abstractions in a ruby on rails that don't actually understand what how many sql commands they are triggering by writing clever one liners that taco my db, from a rails 2.4 method that has a much better rails 5 system they don't know about.
I'm confused by your example. Sounds like someone who knows (or thinks they know) a language well writing code that is "good enough for now" and causing problems down the road?
> The better you know a language, the more tempting it is to take shortcuts.
I used to work with experienced and passionate Scala developers. On the one hand, their expertise helped them to avoid common language and runtime pitfalls.
On the other hand, the desire to produce elegant, pure functional code, experiment with and utilise powerful abstractions slowed the development down, led to the code that was hard to understand and jump on for new team members.
The time consuming aspects of new product dev are normally not around the time it takes to write the code. It's translating product requirements into solvable problems, logic flows that solve those problems, bumping into unseen edge cases in the product concept, and coming to consensus about what compromises are acceptable in the prototype, bumping into sharp edges while you flesh solutions out because you didn't anticipate a thing when you started your base design or didn't understand the relationships between objects and functionality when you kicked the project off.
These problems that take the most time in any project are mostly human, conceptual, product, and communication problems. Not code problems.
Once you have sorted out all of these problems and solved them, a rewrite in a different language with a better design moves very quickly. You don't have to double the runway or the time to MVP. Time estimations are always wrong anyway. But in my experience when I've gotten buy-in for this approach I would guess it adds 25-30% of actual time overhead to a roadmap. Prototypes always take longer than expected, and an immediate redesign/rewrite takes less time than expected.
Selling this approach to leadership really boils down to clearly identifying the value of developer time. It's not code; it's solving business problems. Once those are conceptually identified and solved, the design and code tend to fall into place without a ton of trouble. The problem is that no one really knows what the business problems are until you try to solve them and really dig into the details.
Prototypes should be understood as the process of defining the problem space and uncovering all the hidden issues that people haven't really thought through just yet. MVPs should be an actual product based on that exploration and problem definition and solving. What I'm suggesting here is really just a process boundary that reflects the difference between the two things.
"Can runway handle that?" is really a lot like asking if you can afford to build a product at all.
It really does depend on the management and environment of the company as you’ve stated. I might be more cynical about this, but I see it more likely that management would just leave the project at the prototype stage, release it, and move dev resources to other things.
This is a definite risk if you haven't planned for it and got buy-in. But it's a risk that's also fine with me: I don't want to support and develop shitty prototypes that I've whipped up and know to be awful from a maintenance perspective. So if my garbage gets sidelined and I go work on something else, that's also a win and also not my problem anymore.
I will never again work in a company with a dual CEO/CTO. No matter how well-intentioned and talented that person is, it always leads to a toxic environment. It's an instant red flag that the person is incapable of delegating responsibilities. Separation of duties at the C-level is important. There needs to be some amount of healthy friction in the leadership team to make appropriate compromises. Hope you are able to get out of this situation soon.
That's not how green/blue deployments work. You don't keep both colors up unless you have completely failed to understand the concept.
Green/Blue is all about saving resources and costs, not keeping them around. You misread the cause here. It has nothing to do with deployment strategies.
That's not how I read what the OP's doing in the article. Sure, maybe he's not doing "proper blue/green", but that is what he uses to explain running a duplicated pair of web/app servers full time...
In C, NULL is equal to itself. In C++, nullptr is equal to itself. In Java, null is equal to itself. Same in C#. In JavaScript, null is equal to itself, and so is undefined.
> You're confusing None with NULL, like everyone else. Only a very few programming languages make this error.
Not so, as I've just shown.
SQL takes the philosophy that NULL isn't a value, but a marker for the absence of a value, and gives it special treatment so that it is not treated as equal to itself. Most programming languages do not take this approach, they instead treat null as a special value, special in that dereferencing it is disallowed, but it's still subject to the usual comparison rules (i.e. it's equal to itself).
Your contrasting of None again NULL isn't meaningful. They're just words. The semantics depend on the language.
> NULL is undefined
Depends on the language. In C it's defined as 0, roughly speaking. (Curiously the bit-pattern used to represent NULL is not required to be zero. [0])
As a curious aside, in C, the special float value NaN is not equal to itself.
Maybe if you introduce the concept of a mathematically-principled empty set, you can do away the unprincipled concept of NULL. Empty set equals empty set.
I'm going to sound like a very grumpy old man—because that's what I am—but if you actually need a tool like poetry, you've really fucked up.
I have a ton of respect for the author. It's really good code and solves a hard problem in elegant ways. But it's a problem that we shouldn't let ourselves have.
It's like a patient talking to a therapist:
patient: I'm really depressed.
therapist: Why do you think that is?
p: Well, I've been having an affair with this woman, and my wife found out about it.
t: How does she feel about that?
p: She's pretty angry at me. It's affecting our relationship.
t: How is it affecting your relationship?
p: Well, she doesn't want to have sex with me anymore, and things have gotten a little weird with the kids.
t: How do you feel about not having sex with your wife?
p: It's depressing.
t: And the kids? How do you feel about them?
p: They'll grow up and understand eventually.
t: Here's a pill you can take every day that will make you feel better.
There are two ways to address this kind of situation. The first way is to give the patient a pill to fix the symptom of depression. The second way is to fix the behavior that's causing the depression.
Poetry (and Cargo and other package/dependency managers) are a little pill you can take to make you feel better about stuff.
But there's another school of therapy. I'm maybe going to sound a little like Zed Shaw here, but there's the "Don't fucking do that" school of therapy.
It's possible to fix the underlying behavior that's causing the pain instead of taking a pill. It's harder and requires more work, sure. But in the long term it is a better, more stable solution.
Since I'm already on a bit of a rant, I'll go ahead and say it out loud: agile is the source of many of these types of problems. You start out with good intentions and then one day you end up married to a thing that was only supposed to be a proof-of-concept, but it got shipped because product team and velocity, and now your life is hell, and that POC now has kids, and you're legally responsible for them, and fuck it, just give me a pill, doctor.
Poetry is a brilliant solution to a problem we shouldn't create for ourselves.
This is the forth-is-my-chisel vs node-js-is-my-glue-gun worldview collision. It's bigger than vi-or-emacs, it's older than functional-vs-procedural. There's no bridging it with contextual examples.
