gcmeplz

Even in situations like that one, I think it's possible to avoid the comment:

- setting up a type (with a comment linking to that API's documentation)

- setting up a shape validator & a test that asserts that that that field is a string with the correct shape

- Using a variable name that makes it clear that something intentional is happening: `const weirdlyStringifiedJSONObject = JSON.stringify(...)`

A comment might still be the simplest thing to add, but it doesn't mean it's the only way to document that weirdness. Comments can be fragile compared to the same documentation expressed in code

[edit: list formatting]

I think even that "poor social skills nerd" engineer trope might be partially an example of Berkson's Paradox [1]. You have to have serious technical chops to compensate for a lack of social skills, and it's hard to see all of the people with weak social skills who aren't engineers.

[1] https://en.wikipedia.org/wiki/Berkson%27s_paradox

edit: removing markdown syntax

I loathed typescript at first because of the heavy compilation step, but setting it up to compile only when it was necessary (building for production), and to transpile the rest of the time (running tests, starting a server locally) made a huge difference for our team. A slow compilation step really is a huge cost!

> It would be much easier for many users to be able to say "starts with x", "ends with y", "has abc in the middle" as 3 separate statements than to have to derive the regex that does it.

This seems like a less error-prone and more testable way of writing regular expressions in code too! Writing out the individual portions of a regular expression might be a ton more verbose, but it's because regular expressions hide a ton of complexity with "write-only" shorthand.

You can set up a per-directory bash history: https://unix.stackexchange.com/questions/305524/create-histo...

And a Makefile sounds like it'd be pretty helpful too!

For someone who's awful at pool like me, I suspect that optimal play is to avoid ever hitting any ball in to increase the likelihood that your opponent will scratch on the 8-ball.

You can also use `set -xv` to get nice debugging logs

https://www.gnu.org/software/bash/manual/html_node/The-Set-B...

It works on linux too -- I just downloaded it to test it out.

Use sponge! https://linux.die.net/man/1/sponge

  awk '!n[$0]++' fileName | sponge fileName

Walmart, alibaba, jet.com, Target, and ebay all spring to mind

Coding tests -- I don't think so. Within three months of practice, folks were generally proficient at the "Cracking the Coding Interview" style of problems. When you have a curriculum that's partially designed for that purpose, any question you have that would stump bootcamp graduates is also going to flummox some amazing engineers with years of experience.

I'd instead try to pair with people on solving a problem that translates well to the problem domain that you're trying to hire for. Anybody who's new to the industry is going to need a decent amount of support & mentorship starting out before they're able to contribute meaningfully to a team and working with someone for a day is a good way to figure out how much support they're going to need and what it's going to be like to mentor them. Bootcamp graduates would likely be open to a day of paid pairing to figure out if a job would be a good fit.

If you did want to go with the more traditional coding test route, I'd try and do something relatively concrete:

- download a set of log files & group them based on a search

- hit an API route & use that to render and update a list of items

- connect to a database, figure out what schema migrations are necessary to support a new feature, and then talk through how to do the migration

- figure out why a test is occasionally failing on a CI server

- add metrics, logs, tests, and alerts to a service with two routes (/healthcheck and /doSomethingImportant)

Like all interviews, the closer the interview maps to the day-to-day of what your needs actually are, the better it will be. There's something beguiling about questions about dynamic programming or red-black trees, but being good at answering those questions has almost no relationship to day-to-day work. (Unless you're at a place where deeper knowledge of data-structures and computer science really matters... and in that case, you're not going to have much with recent bootcamp graduates anyways)

> Needless to say, I will be leaving my company very soon to go to a place where there is a coding test and filtering to prevent most of these bootcampers from getting in.

I went to a bootcamp, and the first hour of every day was spent learning to solve the types of coding tests that companies use in interviews. So, when companies look at the graduates of these bootcamps, it's really hard to differentiate between people who perform really well on the interview but will require significant investment before they're useful (this was me) and people who have been programming and working with computers for years and simply lacked a little bit of polish & training (like some other people in my program).

All that's to say -- traditional coding tests & filtering doesn't necessarily work that well when you have people training for the test (rather than training for the ability to do the work that the test is supposed to be a proxy for).

  awk '{ if (!($2 in seen)) print $0; seen[$2] = 1; }'

You can even shorten this a bit! "awk '!seen[$2]++'" does the same thing -- awk will print the whole line when it's provided a truthy value. It's definitely more code-golfy than being explicit about what's actually going on though

I'd be curious to actually read that Glaciers, gender, and science paper to see if it's as worthless as it sounds.

I think there's some amount of feminist theory that boils down to -- all of the people thinking/doing stuff in A field were men operating under B culture; what if we thought about things from a different perspective & revisited some of our assumptions?

Like most fields, I bet glaciology has some underlying assumptions (is the goal of glaciology to manage glaciers? navigation?) & history (which glaciers have people historically studied? are they representative?)

And I know as an outsider, it's really hard to tell what's valuable about another field. If an outsider was critiquing computer science, I bet they'd easily be able to track down studies about tabs vs. spaces and laugh at the silly stuff that gets published in that field.