Had to nitpick on the monospaced font line. Proportional type preserves the shape of words which is a huge part of readability. I don't think I'd take a resume that looks like it was written in a code editor as a positive signal.

https://www.quora.com/Typography-Monospaced-fonts-what-are-t...

It's his fantasy world, so who are we to judge. As a gimmick I could appreciate and would definitely notice a resume printed with a dot matrix printer on pinfeed paper using Courier. But I would recommend everyone to just stick with a nice serif typeface.

I'm glad Apple brought fonts to the computer world as well.

> they would gripe about that technology all day long; if they can't complain about its shortcomings and pitfalls, they didn't use it.

Lol that is gold. I have to add that section to my interviewing questions.

I disagree. I used to be this gripe-y person, but the more experience I gained, the more I realized that everything is just the result of its trade-offs and started finding the griping both boring - who wants to complain constantly for years and years? - and less productive than maintaining more of an anthropologist's mindset.

So to me, constant griping is more of a not-that-much-experience signal.

This is the most important question I ask in every interview. The goal isn't to get someone to piss and moan about every little thing, it's to see if they can identify any downsides to the tech they use. IME >80% of candidates have never even thought about it, treat every tool/dependency as free, and whatever tech they happen to use was written by the second coming of tech Jesus and contains no faults.

Fair enough. Perhaps I have a blind spot due to always having been the opposite kind of person. But I dunno, I'm not sure I've ever run into one of these "second coming of tech Jesus" types of candidates. Maybe that sort of perspective is more common in the bay area? I definitely sense a bit less ... cautious skepticism when I talk with silicon valley type folks.

It's a great direct question. However, what I read was that this person asks candidates broadly about X technology and expects them to divine the knowledge that they need to start complaining about X if they want a job.

When a job interviewer asks about X technology, often they actually _want_ to see you hedge your bets. They think of this in terms of you understanding both the upsides and the downsides of technology (and business) decisions.

I aim to answer by listing: a high-level business benefit of X, a time I saw X delivering such a benefit, a time I saw X being a hindrance or failing to completely deliver the purported benefit, something an alternative of X does differently and why, then wrap up with a conclusion that the benefits are situation-dependent.

Agreed, I wouldn't want continual moaning, I'd like to hear about the problems they experienced, and have the knowledge that on a different platform/framework that would be better, but you'd give up something.

I agree, I think it's better to ask what some of those trade offs are. What's this tech good or bad at? I'm not gonna complain about a language feature that I can't do anything about. I'm gonna implement the work around and move on. What's the point in sitting around and complaining? I can't alter the language itself and it would be unreasonable to change the project language past a certain point.

Reading into how Javascript was created clarified that the "issues" with the language were. I understand the creators(who are probably far smarter than I) chose to make things that way for a reason. I can often just google these reasons "Why does X language do this?" and understand. Any time I think "This seems silly..." there's a reason for it.

Most of us aren't on the cutting edge of technology. I've personally never worked on a team whose biggest problem was a lack of technical prowess, the problems are always social/cultural.

If I'm being frank, then you need to be up front about that in the job posting. "Cultural fit" and other PC BS won't cut it - be honest about what you need.

"We need someone who can design and implement frontends alongside our product marketing group." Not, "Looking for a JavaScript, Typescript, Angular, React, Node.js, Mongo, and BerkleyDB rockstar."

Because I've personally watched several people who were cultural fits and great talkers be PIPed and fired purely for the lack of an ability to execute technical tasks.

I've written and deleted this message a dozen times trying to get it right without it coming off as an attack. I hope you won't take it that way because I'm genuinely trying to be helpful. The way you parse "Looking for a JavaScript, Typescript, Angular, React, Node.js, Mongo, and BerkleyDB rockstar." sounds like the way I would expect an autistic person to parse it, too literally. Every job everywhere has an implied requirement that you will be able to communicate and work effectively alongside other humans. Since it's a requirement everywhere, hardly anyone will list it explicitly.

When I read:

>"Looking for a JavaScript, Typescript, Angular, React, Node.js, Mongo, and BerkleyDB rockstar."

I parse it as:

"We need someone who can design and implement frontends alongside our product marketing group. Our technology stack is JavaScript, Typescript, Angular, React, Node.js, Mongo, and BerkleyDB."

Your point would be made just as well if not better with the first paragraph elided entirely. In general when you rewrite something so many times, it means you should say less

I was trying to solve two problems.

The first problem is for people not on the spectrum to recognize that I wasn't trying to speak to the OP as if they were a simpleton. Because for a person not on the spectrum the implied requirement is obvious.

The second problem is a message to people like myself on the spectrum, "This is a new social rule to add to your matrix for interpreting behavior."

Eliminating the first paragraph entirely would have decreased the likelihood of creating the new rule in spectrum people while simultaneously seeming like I was being snarky to non-spectrum people. It's entirely probable that I failed in both my goals in spite of this.

> Every job everywhere has an implied requirement that you will be able to communicate and work effectively alongside other humans. Since it's a requirement everywhere, hardly anyone will list it explicitly.

That is true. But there is a huge variability in degree, both on the side of the candidates and on the side of the jobs. I think most people would agree that saying "we need an efficient programmer" is insufficient detail. The same is true for a requirement like "needs to be able to communicate and work effectively alongside other humans."

Considering how many of their target audience will parse it too literally, perhaps it is the message that is wrong. It's not purely on us to learn to communicate, the business and recruiters must learn to communicate with us as well.

On the other hand, I think recruiters take it way to literally too. The will quiz candidates and their experience on everything in the list and drop people that don't know 1 or 2 of them (and the liars will get through).

Who do you think you're trying to hire? Of course there's going to be a large number of people who take it literally.

I'm confused by which side you're comparing to the bit in your last sentence to. All they did was fit in and talk? That's not enough.

You have to be able to navigate the work environment and find a way to get stuff delivered. Which your "design and implement" part captures, but "cultural fit and great talker" doesn't.

It’s always a combination. Most of us work in “old” tech. I use 10-20 year old tools, languges.

But good practices and clean code habits are older than that.

There's this one recruiter company that calls me up every six months or so.

We always do the same dance: First they ask me for my most recent updated resume. I send it to them. It's a text file. No fancy formatting, no fonts, not even any Unicode, just ASCII. They always ask me to reformat it, and they always send me the same example resume, and they always explain to me very nicely that they want my resume to make a good impression.

I never do it.

Mostly because I'm lazy, but also because I don't care. That resume gets me jobs. I've never posted it to Craigslist and not gotten responses and a job.

Sometimes they nag me once or twice and sometimes I just don't hear back from them.

Now the thing that puzzles me about this the most is, why, for goodness' sake, don't they have somebody on staff to do the reformatting for me? My hourly rate is not low, y'know? I know they have an office full of people 'cause I've been there. If it's such a crucial step, why not provide it as a value-add service?

Oh well. Not really my problem. Just a weird recruiter thought I wanted to share. :-)

Probably because recruiting is a crapshoot numbers game. Emailing massive numbers of people is easy. They have pre-written templates, so the marginal time spent is minimal. Forwarding resumes along is easy as heck too. But customizing someone's entire resume? That doesn't scale. They would have to... you know... actually value you.

Because you're not compliant, and a compliant candidate is easier for them to place. If you won't reformat your resume to look like pretty much everyone else's, how can they count on you to take a bunch of pointless phone calls for positions that may only vaguely match your skillset in the hopes that one is a match and they get their blood money?

A good balance between highly technical and creatively designed is to write your resume with TeX.

I used to think this was a good idea, but I see so many resumes done in TeX that they cease to stand out.

Of course, just throwing TeX at your resume isn't enough. However, TeX gives you tools at an engineer's level which can be used to make your resume stand out.

Is that more of a recommendation or a hard requirement? I've been using a bland resume that I thought would check all the boxes inside an ATS.

Just a recommendation. TeX is a very engineer-oriented design tool. An interesting way to spruce up your resume.

It's a very good recommendation. Simply being aware that TeX/LaTeX is a thing (it's very recognizable) is something that I tend to appreciate in an engineer.

> they would gripe about that technology all day long; if they can't complain about its shortcomings and pitfalls, they didn't use it.

I have literally baited people I interview with this type of thing. Asked about things I know everyone who has come in contact with has cut themselves on and been upset about.

Some candidates, depending on their backgrounds, may be wary of being thought of as complainers or being "difficult." Something to look out for.

A question that I've been using lately is to ask a candidate to pick some technology (anything) that they have strong feelings about - positive or negative. I'll then throw out a couple of examples: "I really like A about B thing" and "In language X I really dislike Y because Z" -- I'm looking to see that they've really thought critically about some technology. Anything.

This seems better, it's more about tradeoffs.

I don't really feel the need to complain about languages. I just find the workaround and implement it and move on. All languages have trade offs. I can tell you that this one lends more to scaling projects or this one is easier to maintain, this one is easier to iterate, etc. But getting upset doesn't do anything. You just pick the best you can and work with it. I'm not going to get mad that my hammer isn't also a drill.

Every technology is designed through tradeoffs. Choosing a technology and the using it properly reqires understanding those tradeoffs. What they are, why they were made. I whine about the appetite for secret allocation that my C# program has. I whine about the mess that is writing the equivalent C++ or Go code, and the learning curve of doing it in Rust.

It’s whining on the surface but it’s really 90% tradeoffs and 10% badness.

Being able to critique design mistakes in eg. an API means you have a pretty deep knowledge on the domain (and/or API design in general). Being able to argue the downsides of a certain technological tradeoff (such as GC vs not, dynamic vs static) is also important. No one will be able to win an argument on tabs/spaces or dynamic vs static but everyone should be able to point out some drawbacks and benefits.

Describing the merits of a technology is just as good as describing the drawbacks. I chose drawbacks/whine because (unfortunately) I am myself much more enthusiastic when describing flaws than positive sides - itself a flaw, but a very common one.

I see where you're coming from. I think I just don't like the "complain about it" angle.

I can't change the language itself. I feel like a lot of people stress about those issues and can talk about them at length. I'm usually like "This isn't optimal, here's the workaround, this other language does it better but it's got other issues that are even worse for what we're building. Problem solved, moving on." Like, it's just another problem to solve at my problem solving job. The answer is not elegant, but that's the case with so many things in the real world...but this is probably the stoic in me.

I took a resume like this to the career center at my university and got out of that appointment with a lot of disappointment.

I had a similar experience, and at an engineering university no less. The career center was very good if you were a mech/civil/elec engineer wanting to work for a big co, which was maybe 70-80% of undergrads, but that wasn't me. Very glad I turned down almost all their advice and stuck to my LaTeX resume.

I think EQ is incredibly important to engineers or to anyone who is working in a team and "EQ" or put more casually, is this person a self aware, nice person that can work well with other people, is absolutely something I care about in hiring.

I've received a fair number of job offers over the years with a resume that I forward to people as emidln_at_gmail_dot_com_Brandon_Adams_resume.txt. I do work in various development/programming/sysadmin roles. If someone requests html, word, or pdf I just convert it for them.

"and we have to pretend we're designers to work around people like this who have no idea how to hire actual technical people."

I honestly don't know what you mean by this.

My current resume has approximately 6 different fonts, left and right justified fields, bullet points, and tables just so it looks just good enough to get past the HR drones (many of whom are wonderful people despite being a resume gatekeeper).

It was an agonizing process, but the end result is something that recruiters recognize as being well designed. I hate having to maintain it.

That's what I mean by pretending.

Mines is just literally a list of techs categorised by bulletpoints under a job without any context. It doesn't look terrible, but it was hardly really well designed.

The basis that the HR drone/recruiter (wonderful people or not) is only actually interested or capable of matching buzzwords (when hiring engineers, specifically, but possibly in any field) and thus will pass the resume based on meeting a Ctrl F hit percentage critera.

Once the actual hiring manager get the CV, they ask for the context and we discuss it. This largely gives me a reason to talk and thus make people like me, I feel less awkward because I'm not regurgitating my CV, and the hiring person is less bored because they haven't read this. This seems to give them enough context to move to the hiring stage, few ask me any technical questions at this point.

I'm a contractor in London with a very high success rate in landing gigs. Your mileage may vary, but try to think about the people who read your CV.

> They're busy and have a lot of CVs, thus they want to skim for relevance.

> They want 1-2 pages, they're not going to look past this.

> If they ask you about a tech on your CV and you don't stand up to scrutiny, they'll feel you're dishonest and you've wasted their time.

A little bit of empathy goes a long way.

Yep, good advices.

Additionally, have a master CV template and customize it based on the requirements.

Cutting it down to 1-2 pages, removing everything not worthwhile listing for the advert.

Rephrase the technical terms for the buzzwords bingo as per job advert, e.g. .NET vs C#, ADO.NET vs C# database access,...

> 6 different fonts

Dear God, is that really what they're looking for? Tech hiring gets more ridiculous every day.

It's what was needed. And my use of the word fonts is a bit incorrect, it was a total of 6 different font faces (bold, italics, different sizes, different fonts). Sorry about that.

- Name - largest on the page, picked a font that looked good at that size

- Email address - monospaced font, colored to appear as a link (which seems silly, but helps pull attention to it since it's the primary contact method for me)

- Physical address - Small font, so it, my phone number, and email address occupy roughly the same visual space as my name. Also, a different font to fit the reduced size without impacting readability

Per job:

- Company name and title - Larger than the description

- Dates - Small so they can exist on the same line as the company name, but a different font to be legible.

- Descriptions and duties (also used for summary) - The baseline for font and size.

A quick glance at my resume won't show the design choices made; it's supposed to be subtle while retaining legibility through a fax machine (you wouldn't believe the lack of quality of some of the resumes which I've been handed over the years). That subtlty/readability is what took the longest.

You were right the first time. In typesetting, A typeface is a family of fonts, and a font is a weight and set of variations (and size, too, before digital).

Don't believe 6 different fonts in a piece is considered good design.