The best that I’ve found is to just ask them to explain some tech that’s listed on their resume. You’ll really quickly be able to tell if its something they understand or not.

My team does basic networking related stuff and my first question for anyone that lists experience with network protocols is to ask them to explain the difference between TCP and UDP. A surprising number of people really flounder on that despite listing 5+ years of implementing network protocols.

A sample of actual work expected of the prospective employee is fair. There are pros and cons to whether it should be given ahead of time or only shown there, but I lean towards giving it out in advance of the interview and having the candidate talk it through.

Note that this can be a hard sell, as it requires humility on the part of the individual and the institution. If your organization supports an e-commerce platform, you probably don’t get to quiz people on quicksort’s worst-case algorithmic complexity.

I recently went through a week of interviewing as the conclusion of the Triplebyte process, and I ended up enjoying 3 of the 4 interviews. There were going to be 5, but there was a scheduling issue on the company’s part. The one I didn’t enjoy involved white board coding. I’ll tell you about the other three.

To put all of this into perspective, I’m a junior engineer with no experience outside of internships, which I imagine puts me into the “relatively easy to interview” bucket, but maybe that’s just my perception.

The first one actually involved no coding whatsoever, which surprised me going in. Of the three technical interviews, two were systems design questions. Structured well, I enjoy these types of questions. Start with the high level description of what’s to be accomplished, come up with the initial design as if there was no load or tricky features to worry about, then add stresses to the problem. Higher volume. New features. New requirements. Dive into the parts that you understand well, talk about how you’d find the right answer for areas you don’t understand as deeply. The other question was a coding design question, centered around data structures and algorithms you’d use to implement a complex, non-distributed application.

The other two companies each had a design question as well, but each also included two coding questions. One company had a laptop prepared for me to use to code up a solution to the problem, and the other had me bring my own computer to solve the questions. In each case, the problem was solvable in an hour, including tests, but getting it to the point of being fully production ready wasn’t feasible, so there was room to stretch.

By the time I got to the fourth company and actually had to write code with a marker on a whiteboard I was shocked at how uncomfortable it felt in comparison. One of my interviews was pretty hostile, which didn’t help at all, but still, there are many, far better alternatives.

There are extensive resources to help with the evangelism side of things.

Back in my day it was just called McDonald’s.

Do you already know about TSAN? https://golang.org/doc/articles/race_detector.html

I know one author who swears by it. I know many who swear at it.

ex is not ed. i have often wished for ve instead of vi though

vi, vi, vi - the editor of the beast

vi, vi, vi - the one for you and me

…editing because @xorhash had been kind enough to remind me of rcs(1) and cvs(1)…

OpenBSD’s base system doesn’t provide dictionary searches or spell check, either, but I’m fine with that. I’m grateful they provide X Window as part of the base system. Stuff like git, troff, aspell, diction, pandoc, and dictd I’m happy to install using the package mangler.

What I would love to know is why OpenBSD ports has the dict server but none of the dictionaries. If I want a dict daemon on my laptop so I can check definitions offline, I have to get the actual dictionary archives out of the FreeBSD port’s distfiles because ftp.dict.org is dead. While I can do that, I’d rather not have to. :)

There is one aspect where Ed maybe has an actual advantage: It keeps you in write mode and discourages editing.

cat > $filename will do that, too, but with ed I can switch back to command mode, save what I’ve done so far, and then continue by returning to append mode.

Though I could probably do the same with cat >> $filename, but I’m afraid I’d forget that I need to type > twice to append and end up overwriting the file. :)

This is why I prefer writing drafts in a chat with myself. Also because of the enforced pacing: the rhythm of hitting Enter when a line is done, and the leaving it as it is.

or use ex, similar enough to ed, has the vi : commands, and vi is one command away

There are a few details to my story that I had left out because I didn’t think they were relevant. You just made them relevant.

1. My wife and her friends know I’m a writer.
2. They know that I sometimes come up with ideas at socially inconvenient times.
3. I had told them that talking with them had sparked an idea, and asked them if they would mind if I wrote it down right away.
4. Only one person objected.
5. The one person who objected wasn’t my wife, so her opinion didn’t really matter.
6. I didn’t have headphones plugged in, so I was able to put aside my work and engage when the conversation turned back toward me.
7. When you’re the only man in a party of twelve, the conversation doesn’t turn to you that often.

Do you usually give out unsolicited etiquette advice online, or should I be flattered?

Hah, I thought the same. It’s funny how most people will not put up with someone opening up their laptop in the restaurant but we don’t bat an eye when we start using smart phones.

I’ve got that book. It’s an excellent supplement to the manual page.

I’ve been using joe 4.5 and 4.6, and it’s jstar mode is good enough that I haven’t been tempted by jupp.

@rocx mentioned M4, and while it’s kinda old and hairy the GNU version might be what you need.

Good luck on that generator. I tried the same thing but primarily with M4. Would not recommend that path. You could simplify your generator into markdown content.md |cat head.htm - foot.htm >content.htm in the end.

How well do you like Newsboat? Would you recommend it over Thunderbird as a feed reader?

This leaves out a pretty important part of work: you work on a team.

I don’t think it matters whether you work 9-5 or 11-7. If other people on the team are working within a certain time period (such as 11-7), then by all means try to accommodate them by adjusting your hours to overlap with theirs to the extent that doing so doesn’t impact your productivity or get in the way of the rest of your life.

The fundamental principle is to do a solid day’s work in eight hours or less because unpaid overtime is for suckers. Not only are you not getting paid for the extra hours when you draw a salary, but working more than 40 hours a week reduces the amount of money you earn per hour.

For teams, I think it’s fundamental to estabilish a common ground from the get go. I feel that team members should (ideally) agree on a (flexible as much as possible) schedule that accomodates everyone needs, instead of just individually decide which work hours suite them. Personally, I think that, when other team members depends on some measure of your availability, showing up “whenever you feel like it” is a sign of lack of respect for your peers (and I won’t allow it on my team).

My team is doing mostly 10-8 (so working more than the 8h/d). Now I usually do 8-4/5 (depending on the work pressure, my commitments, if I took an additional personal time at lunch break …) if a team member throws a PR when I have to leave, I have absolutely no scruples to let it for tomorrow. Once or twice some asked for a review when I was leaving. To that you just have to answer that you’re leaving because you called it a day and that except if it’s critical to have it reviewed it today, it can probably wait for tomorrow.

To me the teams are not an issue as long as you communicate.

Every time someone mentions VMS, AS/400, AIX, HP-UX I wonder if there is any way to goof around these systems to see for myself the differences from the current mainstream servers.

Several essentials have made a disproportionate benefit on my career. In no order:

• find a job with lots of flexibility and challenging work
• find a job where your coworkers continuously improve themselves as much (or more) than you
• start writing a monthly blog of things you learn and have strong opinions on
• learn to be political (it’ll help you stay with good challenging work). Being political isn’t slimy, it is wise. Be confident in this.
• read programming books/blogs and develop a strong philosophy
• start a habit of programming to learn for 15 minutes a day, every day
• come to terms with the fact that you will see a diminishing return on new programing skills, and an increasing return on “doing the correct/fastest thing” skills. (e.g. knowing what to work on, knowing what corners to cut, knowing how to communicate with business people so you only solve their problems and not just chase their imagined solutions, etc). Lean into this, and practice this skill as often as you can.

These have had an immense effect on my abilities. They’ve helped me navigate away from burnout and cultivated a strong intrinsic motivation that has lasted over ten years.

One thing that I’ve applied in my career is that saying, “never be the smartest person in the room.” When things get too easy/routine, I try to switch roles. I’ve been lucky enough to work at a small company that grew very big, so I had the opportunity to work on a variety of things; backend services, desktop clients, mobile clients, embedded libraries. I was very scared every time I asked, because I felt like I was in over my head. I guess change is always a bit scary. But every time, it put some fun back into my job, and I learned a lot from working with people with entirely different skill sets and expertise.

I don’t have much experience either but to me the best choice that I felt in the last year was stop worrying about how good a programmer I was and focus on how to enjoy life.

We have one life don’t let anxieties come into play, even if you intellectually think working more should help you.

This isn’t exactly what you’re asking for, but, something to consider. Someone who knows how to code reasonably well and something else are more valuable than someone who just codes. You become less interchangeable, and therefore less replaceable. There’s tons of work that people who purely code don’t want to do, but find very valuable. For me, that’s documentation. I got my current job because people love having docs, but hate writing docs. I’ve never found myself without multiple options every time I’ve ever looked for work. I know someone else who did this, but it was “be fluent In Japanese.” Japanese companies love people who are bilingual with English. It made his resume stand out.

Four things:

1. People will remember you for your big projects (whether successful or not) as well as tiny projects that scratch an itch. Make room for the tiny fixes that are bothering everyone; the resulting lift in mood will energize the whole team. I once had a very senior engineer tell me my entire business trip to Paris was worth it because I made a one-line git fix to a CI system that was bothering the team out there. A cron job I wrote in an afternoon at an internship ended up dwarfing my ‘real’ project in terms of usefulness to the company and won me extra contract work after the internship ended.

2. Pay attention to the people who are effective at ‘leaving their work at work.’ The people best able to handle the persistent, creeping stress of knowledge work are the ones who transform as soon as the workday is done. It’s helpful to see this in person, especially seeing a deeply frustrated person stand up and cheerfully go “okay! That’ll have to wait for tomorrow.” Trust that your subconscious will take care of any lingering hard problems, and learn to be okay leaving a work in progress to enjoy yourself.

3. Having a variety of backgrounds is extremely useful for an engineering team. I studied electrical engineering in college and the resulting knowledge of probability and signal processing helped me in environments where the rest of the team had a more traditional CS background. This applies to backgrounds in fields outside engineering as well: art, history, literature, etc will give you different perspectives and abilities that you can use to your advantage. I once saw a presentation about using art critique principles to guide your code reviews. Inspiration can come from anywhere; the more viewpoints you have in your toolbelt the better.

4. Learn about the concept of the ‘asshole filter’ (safe for work). In a nutshell, if you give people who violate your boundaries special treatment (e.g. a coworker who texts you on your vacation to fix a noncritical problem gets their problem fixed) then you are training people to violate your boundaries. You need to make sure that people who do things ‘the right way’ (in this case, waiting for when you get back or finding someone else to fix it) get priority, so that over time people you train people to respect you and your boundaries.

The biggest mistake I see junior (and senior) developers make is key mashing. Slow down, understand a problem, untangle the dependent systems, and don’t just guess at what the problem is. Read the code, understand it. Read the code of the underlying systems that you’re interacting with, and understand it. Only then, make an attempt at fixing the bug.

Stabs in the dark are easy. They may even work around problems. But clean, correct, and easy to understand fixes require understanding.

Another thing that helps is the willingness to dig into something you’re obsessed with even if it is deemed not super important by everyone around you. eg. if you find a library / language / project you find fun and seem to get obsessed with, that’s great, keep going at it and don’t let the existential “should i be here” or other “is everyone around me doing this too / recommending this” questions slow you down. You’ll probably get on some interesting adventures.

Never pass up a chance to be social with your team/other coworkers. Those relationships you build can benefit you as much as your work output.

(This doesn’t mean you compromise your values in any way, of course. But the social element is vitally important!)

Linus spells out the Linux approach in these emails.

The short version is: don’t use a type abstraction where you don’t need one, nothing is wrong with typing ‘struct xxx’.

One of the emails in the link, on where typedefs are useful:

 (a) totally opaque objects (where the typedef is actively used to _hide_
     what the object is).

     Example: "pte_t" etc opaque objects that you can only access using
     the proper accessor functions.

     NOTE! Opaqueness and "accessor functions" are not good in themselves.
     The reason we have them for things like pte_t etc is that there
     really is absolutely _zero_ portably accessible information there.