There are only two stories in the collection that feel a little further out:
"Best Practices for Safe Asteroid Handling" by David W. Goodman feels like a smart, polished successor to golden age space opera, it's set in a future where the solar system is colonized, but not thousands of years out.
Grant Collier's "The Best Version of Yourself" is also not set very far into the future, but it's a kind of post-human future so it might have far-future vibes for you. This specific story is actually available free online, so you don't have to purchase the anthology to read it: https://clarkesworldmagazine.com/collier_07_24/
Nowadays I am on the other part of the fence, I am the interviewer. We are not a FAANG, so we just use a SANE interview process. Single interview, we ask the candidate about his CV and what his expectations are, what are his competences and we ask him to show us some code he has written. That's all. The process is fast and extremely effective. You can discriminate week candidates in minutes.
How do you expect them to get access to the property internal Git repo codebase and approval from their employer's lawyers to show it to third parties during the interview?
Sounds like you're only selecting Foss devs and nothing more.
Most people have still written code for school or a hobby project. Maybe I'm missing empathy, but I cannot understand how some developers have no code to show.
If that's the case however, just let them make a small project over the weekend and then do another interview where you ask stuff about what they've made. It's not that deep
> Most people have still written code for school or a hobby project. Maybe I'm missing empathy, but I cannot understand how some developers have no code to show.
First: they might have private code, but not necessarily code to show (I, for example, am rather not willing to show quite some of the code that I wrote privately).
Second: the kind of "code" that I tend to write privately (and into which I invest quite a lot of time) is really different from what I do at work, and what is actually considered "code" by many. It's more like (very incomplete) drawings and TeX notes about observations and proofs of properties and symmetries between some algorithms. Once finished, they will be very easy to systematically transform into a program in a computer language.
This is about very novel stuff, which to explain would take quite a lot of time.
The objective in an interview like this shouldn't be to grade the quality of the code you bring in any sort of scale, but to have a discussion about the options you took. In that sense, it really matters very little what you present as long as we can do a small back-and-forth that lets me into what sort of person you are.
> but to have a discussion about the options you took
I can clearly state that this is not I commonly think about code that I write privately (and also for code that I write for the job only if I must). For private code, I rather commonly start with a "gut feeling" about some unexpected symmetry that the problem that I am working on likely has, then try to formulate these "gut feelings" as mathematical properties, and later theorems. At the end, everything "fits (for outsiders: unexpectly) together".
Thus, there is hardly ever a "option that I took", but rather a "I let everything flow: from the source [my gut feeling] to the sea [which is - ironically - the source (code)]".
> Most people have still written code for school or a hobby project
School was years and years ago, and has nothing to do with my current skills.
From the people i personally know, most do _not_ have a hobby project, even fewer have hobby projects that showcases their technical skills. Nor should they be expected to. Most people have non-programming hobbies.
> I cannot understand how some developers have no code to show.
It's really not that deep, I'm worried if you really cannot understand. I don't code outside of work, I'm not interested in doing it. I'm good at software engineering, not passionate about it. I have a bunch of other hobbies. There's no reason I'd have any code to show now or at any point in the future.
> let them make a small project over the weekend and then do another interview where you ask stuff about what they've made
If I'm paid for it, sure why not I could do that. I won't love it but hey I'm looking for a job, I'll put the legwork in.
But if this is the only or the "preferred" interview process for a company, I need to point out that it is deeply discriminatory as it advantages people who have the time to do a weekend project: for example it benefits males disproportionally (women do most of the care work in any country, also the most house work, also have a higher chance to be a single parent, all of which impacts the time they can put in a "weekend project" if they can do it at all).
> It's really not that deep, I'm worried if you really cannot understand. I don't code outside of work, I'm not interested in doing it. I'm good at software engineering, not passionate about it. I have a bunch of other hobbies. There's no reason I'd have any code to show now or at any point in the future.
It's like asking a dentist interview candidate to show you examples of fillings and crowns they did at home as a hobby. I don't understand why there is this automatic assumption that people who program at work also do it outside of work.
I ask for code, and if they have none prepared I ask that they spend at most two hours building something they enjoy.
I expect a decent developer to be able to bootstrap and write most of a fun toy project in a domain they know well or at worst some kata from the Internet within half an hour. Then we spend some time screen sharing and talking about it, similar to pair programming but less problem focused.
If you can't do it you'll likely struggle a lot when working with us because we commonly use throwaway prototypes.
Sure. A bigger organisation with more layers in their technology department could treat candidates better that would struggle with a hiring process like mine. More detailed tickets, more mentors available, bigger cashflow, things like that.
In such settings it's also somewhat common to hire consultants in bulk, like 5-10 at a time, try them out for six months and keep the ones that enjoy the work and fit well in the organisation, and over time try to employ some of them directly.
I realize it's a rhetorical question, but pretty much everybody in the arts? I'd be very surprised to find a professional musician that doesn't play as a hobby.
Artists and musicians surely have portfolios to show, but I don't think those are usually composed of things they're doing in their free time. Maybe? I'm not an artist so maybe I'm wrong. I guess then we're back to "you should have a portfolio" rather than specifically "you should do your job in your free time." I can agree with that!
If you're not interested, you're not interested. Not even about "passion" at that point, but the bare minimum interest in your industry. I said it better previously: https://news.ycombinator.com/item?id=15553482
I don't code much outside of work. I have hobby projects from 10+ years ago, but they're not much more than landing pages copied from templates and wordpress installs. I mostly work in backend/data/platform engineering professionally.
If I were asked to make a small project over a weekend, I'd be likely to decline rather than doing a more standard interview, or I'd use AI to do it in a reasonable timeframe (which seems to defeat the purpose as it relates to this discussion)
This points to another issue - when I do code outside of work, it's often specifically to try out things I don't do at work. After a day of doing backend work, I'll maybe put together a basic web UI for something. That code is likely awful because I just need it to be functional more than good, and also probably not related to the work I'd be hired to do.
My most recent real "side projects" are a terrible OSS monte carlo simulator tool that I contributed to, but cannot explain most of the code for, and a half-working React application that has performance issues I never fixed. Both are years old at this point. I'm not sure what an interviewer would gain from those.
This relates to another issue of using people's public github as a hiring signal. I don't share any of these repos because at a glance the code is ugly, broken, incomplete.
Below the surface, I'm probably scratching a very interesting itch. Exploring a specific idea or problem, and then I stop when I get my answer.
I’ve been working professionally for almost 30 years. I have never written a single line of code “for fun”. I write code for money. I then take that money to fund my hobbies. The absolutely last thing I want to do when I get off work is stare at a computer.
If I already have a job, unless you are paying top of market, why would I spend my weekend writing code?
It looks like you professionally sold 30 years of your life for money with no fun. You could have done something for fun all this time, and got payed for it, too. Much better that way.
I did no such thing, I spent the first 15 years as a part time fitness instructor mostly for the social aspect, hanging out with friends and training for and doing group runs and a little travel.
I spent the next 8 years married (still married) and raising two step sons and spent the last two and half years traveling extensively including over a year doing the “digital nomad thing”.
We have been averaging getting on a plane to do something on average over a dozen times a year since late 2021.
Of course the Covid lockdown slowed us down for two years.
When I am at home in Florida, I go swimming at one of the multiple pools or workout at one of the two gyms that’s part of our complex. It’s warm enough most of the year at least during the day.
During the weekends, I go downstairs and hang out at the bar and just sip soda while hanging out with my friend the bartender and whoever else is down there.
I “retired my wife” in 2020 when I was 46 and she was 44 8 years into my marriage so she could pursue her passion projects and we could pick up and travel as often as we wanted to - the joys of working remotely.
School was a few decades ago, and the code I have on Github is mostly toy stuff I do in rainy weekends, most of us have a life without room to code outside work most of the time.
Like many of the other commenters, I have no code to show. I'm strongly motivated at work to solve problems and create correct, performant, maintainable code. I appreciate a job well done.
Outside of work, I just don't have the motivation to code anything. I don't have sufficient at-home problems where code will fix them.
In an interview, ask me anything! ... except to show you code on Github.
Who are these "most people"? School was over 10 years ago for me when schoolwork was not posted on GitHub nor is it relevant to my current job anymore, and I don't do hobby coding since I have other hobbies and responsibilities.
WTF is this hobby coding bullshit expectations? What other professions expect you do more work after work as a hobby and show it? Do bus drivers film themselves driving busses after work as a hobby? Do surgeons cut up people in their spare time as a hobby?
It's that trimodal-comp thing. The 6-hour leetcode gauntlet is only the overwhelming norm in the top hump of that graph. It's not normal in the other two (not that it's never seen, but the companies dumb enough to do it without offering FAANG-tier comp are shooting themselves in the foot). I've had, IDK, ten plus tech jobs and have been solidly in the middle comp tier for most of those, and have exactly once encountered anything resembling a leetcode question in the wild.
I've also done hiring, and have no idea what good leetcode would do me. I'm convinced these people thinking they "dodged a bullet" on "fakers" either spotted a real faker who they would have caught with a normal conversation anyway, or else are assuming someone with a good resume who failed their test did so because they were lying and not because they choked under the unique sort of pressure interviews present when you turn them into a dancing-monkey routine (it's approximately the same kind of stress as doing an open mic night or karaoke in front of a crowd of strangers—most people have trouble with that and lots of them fall apart at least some of the times they try it). Meanwhile, anyone who can talk about the job and their career in any depth, convincingly, without giving away that they're actually either very-green or have no idea what they're doing, while in fact not knowing how to do the job, possesses a skill at least as valuable as programming, and I find it hard to believe most such folks haven't figured out they can apply that skill directly in exchange for money instead of trying to fake their way through conversational tech interviews.
I do see how leetcode is valuable if you want to ensure that most of the candidates in your pipeline would do fine before you even evaluate them, because you offer high comp and need a way to discourage candidates who definitely can't make it before they even apply, and/or if you want to make job-hopping painful as a wink-and-nudge collusion way to keep comp suppressed. It makes sense for FAANG, in a certain way, but not because it's a good way to evaluate candidates per se.
> WTF is this hobby coding bullshit expectations? What other professions expect you do more work after work as a hobby and show it? Do bus drivers film themselves driving busses after work as a hobby? Do surgeons cut up people in their spare time as a hobby?
I think programming has more commonality with other creative, 'soft' jobs like graphic design (which itself can involve programming), architecture, media, marketing, etc than meets the eye.
Many of these roles require that applicants have some sort of portfolio that can be perused by the interviewer freely. I feel co-opting that word—'portfolio'—would do us software developers a big favour instead of trivialising outside-of-work programming as 'side projects' or 'hobbies'.
>architecture, media, marketing, etc than meets the eye.
I disagree. Programing is more engineering than art. Art doesn't have source code. You can show the final painting and I can show the final product I worked on but not the source code I wrote as that belongs to my employer. Also, most art like paintings are not done by large teams, so you can show what you did in that painting but in a large SW projects, I can't show what exactly form the final product I did and what else was done by my team.
Most of my valuable work in programing is engineering, especially fixing bugs, not creating portfolios to show off. I have nothing publicly to show off, mostly because firstly, it's private to my former employers, and secondly because code gets outdated and replaced fast, most of what I worte in the past probably doesn't run today anymore, but have made my employers happy and wealthy.
Sounds like you just treat programming more like engineering than art. Some art does have source code, there is plenty of room for creative exploration with code.
>there is plenty of room for creative exploration with code.
That also pays the bills? That's not my experience. That's what hobbies are for. Jobs are for paying bills. Paying bills with hobbies an art are a luxury for privileged.
I said neither 'art' nor 'paintings' which you have fixated on for some reason. I mentioned creative endeavours that are generally team-based but all generate some sort of portfolio. Whether that portfolio is from work or done in one's personal time, it is still a portfolio of past work.
Plus, software engineering is absolutely a creative endeavour. And I daresay normal 'engineering' (civil, mechanical, aero, etc) is a creative endeavour too; it's just a matter of egos and that seem to separate STEM versus non-STEM. There are portfolios for everything. I don't understand the desire for software engineers to just waltz into an interview, claim to have done X, Y, Z, with no proof, and secure a job.
The proof part is interesting. Civil is easy to prove because of its artifacts. Someone from Netflix or Meta layoffs, what proof do any of them have? Do some people defensively maintain background proof other than paycheck stubs?
It could be considered similar to scaffolding or boilerplate in code, except usually none of this is visible in the end product, while the code boilerplate is always there. These lines are drawn light and completely covered up by the end result - sometimes even manually erased depending on the medium.
I can empathize with your position if you are also against expecting candidates "prepare for the interview" by leet code grinding or "brush up on CS concepts".
Hobby coding is million times better than that crap.
At least leetcode is something somewhat standardized (algorithms don't change). Hobby coding is not, it's something subjective and varying between the interests of each candidates and often have nothing to do with a job.
I don't like writing code for the sake of it, and have gotten a lot better, over 25 years of writing code, at evaluating whether I need to write code or whether I'd be better off using something that already exists and putting up with its limitations, or even just doing nothing (see that XKCD comic with the time-savings payoff chart).
The result is that I don't think I've written anything longer than about a ten-line shell or python or JS script for my personal use in... a decade or more.
Frankly I probably think you shouldn't be paying anyone to do the thing you're wanting to pay me to do, because computers are likely just an expensive distraction that management's pursuing because the promise of legibility, even if in-fact pointless in this case, is incredibly enticing to them, but also I like money and will build the thing you shouldn't be building for you if you pay me. I'll even do it well, if you let me. But I don't make the same mistake (much) in my own life, any more.
Would I write a bunch of code on my own if I thought it'd be worth it? Yes, but that'd almost certainly mean I had a product idea. If I were any good at thinking of product ideas, I'd long since have had my own business. I'm terrible at it. That's literally the only reason I'm applying for a job. If I had a pile of decent code to show you, it'd be because I didn't need your job.
I started writing code when I was 12 and started doing it professionally at 22. I'm now in my mid-30s and outside of work, I haven't written anything more than one-off scripts for my homelab in close to a decade. I'm already spending upwards of 50 hours with code each week and I need to do something else at night and on the weekends to release my brain from it. I also didn't go to school for CS, and even if I did... it was over a decade ago. So I have ~25 years of experience writing code but could not show you a single line of it. And even if I could, how would you know I was the one to write it?
This is an extremely flawed interview process in my opinion and the last time I encountered it led to an awkward scenario that led to me walking out. Personally, when I conduct interviews, it's a mix of things. We talk about your past work, I quiz you a bit on some topics you'd encounter in your day-to-day here, and then we'll spend an hour doing some combination of a code review of a working-but-flawed demo project I created, a 30-40 minute coding exercise, and/or a problem-solving scenario where I give you a problem and then we talk through how, as a pair, how we could solve it.
My worst code is always what I wrote yesterday. Often what’s missing is context, unless I comment ad nauseam. Sure I didn’t write complete test, obey open closed principles abstract into factory functions. The code I send from my hobby projects is likely a mess, because finishing on my own time by my own unpaid constraints wills it to be so
Maybe you forked a library because of reasons. You can tour the original repo and explain the problems. I have at least one of those examples for each time the legal or confidentiality department stepped in.
The word maybe is doing a lot of heavy lifting here. What if you never had to do that? Not everyone's work is public. Inf act I'd say most people's work is not public. Sometimes even the product is not public since it's B-2-B.
But if you’ve worked on something mature and nontrivial, you’ve forked a dependency and are able to tour it. Looks like I’ve done it on average twice per year.
That process might work for your company precisely because you are not FAANG. You don't get hundreds of applicants that are dying to get in, so people don't have that strong of a motivation to do anything it takes (including lying) to get the job.
I’ve worked at a company with 150,000 employees. The interview process was pretty much as described here. There is absolutely no reason a Big Co needs to operate any differently.
We do this too, works fine. We ask open ended questions like, "What's your favorite thing you've done in your career and why?" and "What was the most challenging project in your career and why?" If you listen, you can get a lot of insight from just those two questions. If they don't give enough detail, we'll probe a little.
Our "gotcha," which doesn't apply to most languages anymore is, "What's the difference between a function and a procedure." It's a one sentence answer, but people who didn't know it would give some pretty enlightening answers.
Edit: From the replies I can see people are a little defensive about not knowing it. Not knowing it is ok because it was a question I asked people 20 years ago relevant to a language long dead in the US. I blame the defensiveness on how FUBAR the current landscape is. Giving a nuanced answer to show your depth of knowledge is actually preferred. A once sentence answer is minimal.
I'm editing this because HN says I'm posting too fast, which is super annoying, but what can I do?
> We do this too, works fine. We ask open ended questions like, "What's your favorite thing you've done in your career and why?" and "What was the most challenging project in your career and why?" If you listen, you can get a lot of insight from just those two questions. If they don't give enough detail, we'll probe a little.
The problem is: there is a very negative incentive to give honest answers. If I were to answer these questions honestly, I'd bring up some very interesting theorems (related to some deep algorithmic topics) that I proved in my PhD thesis. Yes, I would have loved to stay in academia, but I switched to industry because of the bad job prospects in academia - this is not what
interviewers want to hear. :-(
> "What's the difference between a function and a procedure." It's a one sentence answer
The terminology here differs quite a lot in different "programming communities". For example
says: "Procedure (computer science), also termed a subroutine, function, or subprogram",
i.e. there is no difference. On the other hand, Pascal programmers strongly distinguish between functions and procedures; here functions return a value, but procedures don't. Programmers who are more attracted to type theory (think Haskell) would rather consider "procedures" to be functions returning a unit type. If you rather come from a database programming background, (stored) procedures vs functions are quite different concepts.
I could go on and on. What I want to point out is that this topic is much more subtle than a "one sentence answer".
> I'd bring up some very interesting theorems (related to some deep algorithmic topics) that I proved in my PhD thesis. [...] I switched to industry because of the bad job prospects in academia - this is not what interviewers want to hear.
In my experience you'll be fine giving that answer assuming you're going for the kind of programming job that hires PhDs.
You remind them you have a PhD - and in something deeply algorithmic. You can successfully answer any follow-up questions from them, as you literally have a PhD in the topic they're asking about. There's no shame in entering industry because you want jobs and money - in fact, those things are precisely what the hiring manager is able to offer you.
You'd rather be in academia but it doesn't have the pay and job security? Well, the hiring manager would rather be a snowboard instructor in Aspen but doesn't for the same reason. So you've got common ground with them.
>The problem is: there is a very negative incentive to give honest answers. If I were to answer these questions honestly, I'd bring up some very interesting theorems (related to some deep algorithmic topics) that I proved in my PhD thesis.
This is unfortunate that you would get that response. FWIW, I would be interested in hearing all this in an interview and I would look at it favorably.
>What I want to point out is that this topic is much more subtle than a "one sentence answer".
Yes, you would definitely get bonus points for nuance. The one sentence answer was minimal. What it filters out are people who don't know anything about Delphi but applying for the job with highly embellished resumes hoping to get lucky. This was for software used in hospitals, so bugs or errant code could have pretty drastic consequences.
> Yes, I would have loved to stay in academia, but I switched to industry because of the bad job prospects in academia - this is not what interviewers want to hear. :-(
I would love to hear that from a candidate I'm interviewing. Who can't relate to the distinction between your ideal job and the job that will actually pay you money?
Here's an interesting thought on your "gotcha" - I'm 57 years old, been programming as a career for over 30 years, a lot of languages and I have no idea what the difference is.
If I'm applying for a Java position and I claim to have Java experience on my resume, it's perfectly valid for them to ask me the difference between an int, an Integer, and a BigInteger.
But it's certainly not a universal question applicable to all programming languages.
Likewise, Clubber says in their post that their 'gotcha' question doesn't apply to most languages.
It's a question to filter out people who don't know a lick of Delphi for a position where the person was coding Delphi. It's like level 2 after the hello world chapter. It's easier than asking a database developer the difference between a query and a view. It's a bonehead simple question that 70% of applicants couldn't answer.
You would be surprised how many bad applicants interviewers get. It's only gotten worse over the last 20 years.
I have no idea either. I can easily look it up though. You can often tell an inexperienced interviewer from the extremely domain specific question they ask which _they_ are familiar with.
There are some absolutely ridiculous qs I've been asked like this and they've all had no followup question to illuminate why it would have been relevant
1. what version of java do you use? we used 8 at the time
2. what is the engine and version underneath your sql db?this was not for a dba role, just standard backend engineer
3. why did you use python instead of r for x project? this was about a gui automation script
>You can often tell an inexperienced interviewer from the extremely domain specific question they ask which _they_ are familiar with.
Lol a bit touchy aren't we?
Like I said, it's not really relevant in today's languages. It was for a Delphi/Pascal position. If you do any type of database code (like T-SQL), you would also know it. If your experience is mainly in C type languages, everything is a function so it doesn't apply.
If you hired a guy for a Delphi position who didn't know the difference between a function and a procedure, you hired the wrong guy.
procedure Hello;
begin
ShowMessage ('Hello world!');
end;
function Double (Value: Integer) : Integer;
begin
Double := Value * 2;
end;
Function or procedure is defined in every subroutine. It's a very basic question for Delphi, like what's the difference between an integer and a string.
No. I just looked up other responses to your post. It's obvious you got exposed as being inexperienced (or an idiot), while posing to know the definitive with your "gotcha". Being inexperienced (or ignorant) is not a problem, but being cocky is.
I think you're projecting. You aren't posting this using your real name are you?!
Here's something to consider, Dennis. Instead of using any type of reasoning that maybe I'm interviewing for a language you aren't familiar with where functions and procedure differences matter, you decided to just go off the handle and call me inexperienced and/or an idiot. This is what we call in the hiring business a "huge red flag." I recommend maybe use some of that big brain you have and apply some deductive reasoning instead of just calling people names.
Look up my other responses - I decided to call you names _later_ . Other people also pointed that out to you. I'm sure you would thick twice before asking your 'gotcha' again (the question is fine in general but not as a gotcha).
>>You can often tell an inexperienced interviewer from the extremely domain specific question they ask which _they_ are familiar with.
>Lol a bit touchy aren't we?
You lost your composure and decided to start calling names after this. I haven't asked it since the late 90s, early 2000s. It was a for a Delphi position. It's a bonehead easy question any Delphi developer who got to chapter 2 of any Delphi book would have understood. It's still an applicable question for a SQL developer and it's just as easy. I even showed you sample code. I don't see why you aren't getting it.
I'm not getting it, I also see that 2 other people are also not getting it.
>I haven't asked it since the late 90s, early 2000s.
You overall gave the impression that you are currently asking it.
And a personal rhetorical question - aren't you too old to even state this 'gotcha' business _today_ about what you did in the past? What made you state it? If I gave you the benefit of doubt - that was slip, where you omitted the past tense.
(If I did that in the 90's I'd be a embarrassed to even mention it today.)
> Our "gotcha," which doesn't apply to most languages anymore is, "What's the difference between a function and a procedure." It's a one sentence answer, but people who didn't know it would give some pretty enlightening answers.
If you're asking this question (by virtue of the present-tense "is") in the year 2025 even though by your own admission
> it's not really relevant in today's languages.
then you aren't giving candidates a good impression. Even though I would have nailed this question I would have serious reservations about any job that would ask it in an interview because it means that the person interviewing me has more concern for legacy minutiae than broad technical knowledge or problem-solving skills.
Words like functions/procedures tend to have different connotations across languages and once one crosses one's 15th language, and each having some 20 different keywords, it become difficult to remember what the exact connotation of a word is, in a specific language/framework. This is the most likely situation of the guy whose post I responded to.
The exception to the rule is, if you have been working quite a bit _recently_ on a specific language. You are presumably talking about this situation.
It’s ok to say that it’s never professionally mattered. No one has ever been paid to know that. “Are side effects a bad pattern?” Lotsa people have needed to know that on day one.
> Single interview, we ask the candidate about *his* CV and what *his* expectations are, what are *his* competences and we ask *him* to show us some code *he* has written
You... might want to think about what implicit biases you might be bringing here
I am scientific Python programmer. 99% to 100% of my programs require parallelism, but it is ALWAYS embarrassingly trivial parallelism, nothing is ever mutated and I never need locks. Right now I am forced to use multiprocessing to get the performance, with all problems of multiprocessing, the major one being that I need to use more memory. For me using multithreading could mean the difference between running out of memory and not running out memory. The GIL removal matters for people like me, the proponents of the GIL removal comes from the scientific community.
I remember when I took my course of "Theoretical Physics" (so called, it was an Introduction to Quantum Field Theory in actuality) and I realized that particles do not exist. It was quite an enlightenment. Particles are a convenient description of Quantum Fields in the perturbative regime, but what Quantum Fields are is not known, not even at the mathematical level. When you live at frontier of knowledge, as a Theoretical Physicists, reality becomes fuzzy. But that's life.
I was in your situation 20 years ago, as a postdoc in Theoretical Physics. My advice is to contribute to some known Open Source project, so that you have some provable programming skills when entering the job market. In my case I contributed to Python, not by coding, but by writing various articles on advanced features of the language and an essay on the Method Resolution Order that at the time was new and undocumented. Guido van Rossum in person put that essay on the official Python site. Having something like that in your CV helps when looking for an IT job. Nowadays I would probably contribute to Julia, you need something that shows promises but it is not mainstream yet to make a good impression.
Seconding this. Don't just learn to code, learn to solve problems related to some project or subject. Those problems may be "we don't have documentation about how X works", so learn X and do some writing.
Ideally you do a little coding too, but it'll give you a portfolio of things to show off later, even if just documentation.
Can be fun stuff, like FOSS games, e.g. Battle for Wesnoth. Fix a few of their bugs or ToDo items, maybe make some 3d assets in blender, build a new campaign, etc.
However, I do not think there is any standard API to follow, I used "info cfg" but many alternatives were possible. So sysadmins have to explore to find out which is the introspection command to give. Not ideal, but I don't think there is a solution.
Another good place for that is the --version output, if your --version is one of those verbose multi-line ones (instead of a basic single-line output).
Pity that I never met antirez in all this time. I first heard of him from David Welton who was a coworker of mine in 2004, well before the existence of Redis. But hope is not lost. For the moment, I think I will buy his book ;-)
