an engineer's perspective on hiring
44 points by jyn514
44 points by jyn514
hiring in tech is broken and everyone knows it. what can we do better?
I would like the “not capitalizing sentences in blog posts” trend to go away. It makes it harder and takes longer for me to read.
Content is fine. Last time I did technical interviews I asked the applicants to pick between showing me some code and walking through it or doing a coding challenge. All of them picked showing me code. It turned out really well and gave me a strong sense of technical communication and their coding priorities as we talked tradeoffs. This was for an internship, the intern worked out really well.
A interesting anecdote: Due to a technical glitch I was unable to open one applicants resume so had them open it and walk me through it together. (Remote interview, screen share). It also let me ask them directed questions about experiences as they talked about them. The flow was actually quite nice and casual. Not sure how to recommend this as an intentional practice though. I wouldn’t want the applicant to feel I cared so little about their time that i didn’t bother to open the resume. On the flip side it would be nice to know an interviewer heard my main achievements.
I would like the “not capitalizing sentences in blog posts” trend to go away. It makes it harder and takes longer for me to read.
Likewise. I kept re-reading same couple sentences multiple times so I just gave up on reading the post. When I don’t know where sentences start, it’s difficult for me to keep track of the text I’m reading.
In short posts it’s okay, because I’m usually done reading before the problems start. But in lengthy blog posts it’s just difficult for me to focus on.
I’m not condoning it (switched away in my own posts recently for the same reasons), but I’m afraid it’s not going away any time soon—it’s a generational thing.
As a person from that same generation who used to do it, I can give some background: writing without capital letters is a form of personality expression. It sets a different tone than capitalising your sentences does. It’s varies from person to person, but mine was about setting a more laid-back, humble writing style.
I appreciate the explanation, even if I don’t entirely understand the intent, yet.
I read “house of leaves” in high school which does some wild things with typesetting and punctuation and capitalization. I understand using it for dramatic and tonal effects. But the effect on the reader is how they perceive it, not how it was intended.
I don’t understand what tone missing capitalization is supposed to be setting. It makes the writing more confusing and slower to read (for me). Is it supposed to be a confusing and slow tone? Is it used selectively on only a few works for specific effect? Or is it being different for difference sake? I know these are pointed questions, but I’m also genuinely curious.
it’s how i write. all my writing is formatted this way, including casual conversation and long form writing.
that said, i have seen enough people say that it makes long form writing harder to read that i will make an intentional effort to switch back to capitalization for future posts. but it is that, an intentional effort.
It kind of reminds me in spiderverse how miles refuses to tie his shoes because he is chooses not to. The difference is, in text it’s tripping me up, not the “wearer.”
I think for short form it’s nice to not have to go back and correct casing as you’re editing, especially on mobile. I can see how it would be weird to have to “switch” back, thanks for that effort.
Sounds like I will have to make firefox addon or userscript to make things easier to read, then.
Agreed 100%. Spending effort to make your post hard to read sure is an odd choice for a post talking about efficiency and respect.
Are they trying to distance their writing from LLM output?
Points 3 and 4 are in sharp opposition, in my opinion.
In particular, the fact that Oxide is willing to spend a lot of time screening engineers is a costly positive signal that it is a workplace that takes culture fit serio usly, rather than pay lip service to it.
How does the author’s proposed interview process intend to preserve this signal, so you can hire high-quality candidates that have enough self respect to not work in toxic environments?
I’m confused by the apparently large discrepancy between take home assignments and work samples, which are basically the same thing, but get rated very differently. What’s the assumption here – that interviewers don’t review the assignments and discuss them with candidates afterwards? And why would a take-home not be representative of real work?
Principle 2 seems wrong to me. What you care about is how predictive of job duties it is. How similar/dissimilar the test is to the job duties is kind of irrelevant.
While this is true, some of the best research in this field suggests that realistic work sample tests are highly predictive: https://www.researchgate.net/publication/232564809_The_Validity_and_Utility_of_Selection_Methods_in_Personnel_Psychology
Few thoughts overall:
The code review point biases towards, well, towards people who have experience with code review and have spent more time in specific kinds of engineering culture. E.g. I can see that being tricky for hiring junior devs, where some juniors may have landed internships (and gotten code reviews from experience engineers) and some juniors may not have.
For point 4 about efficiency, I’m not so sure about that. Engineer time is expensive, sure, but the cost of hiring someone who turns out to not be successful is arguably much more expensive. The design of interview questions itself is not cheap depending on how you do the internal testing process (you’re testing these internally first, right?). Using code review means that the following groups have an advantage:
etc. It’s not obvious if that is acceptable or desirable. If you want to reduce the influence of these factors, then you need to do more work.
(To be transparent, I’ve actually advocated for swapping out a coding interview for a code review interview for candidates at work. But I feel like this post doesn’t actually talk through the downsides of it seriously. A code review interview is arguably, to some extent, an assessment of the engineering cultures you’ve been in in the past.)
The last point about Code review reminds me of https://lobste.rs/s/y59kd4/how_freaking_find_great_developers_by (the link is dead, correct link: https://freakingrectangle.wordpress.com/2022/04/15/how-to-freaking-hire-great-developers/)
Code review is absolutely the highest signal-to-noise experience I’ve had, both on the receiving and the giving end.
The way my previous employer did it was an even superior variation: you get the mediocre code and a user complaint explaining how the application didn’t work. This also tests for ability to interpret user language, and prioritize what actually matters for the user. (The bug was simple enough so as not to turn it into a full-fledged live coding interview.)
I like this a lot. I do find that sometimes we got lost in the tech – it’s a valuable and surprisingly rare skill to be able to view things from the end user’s POV, and then translate that into minimal and easily executed technical requirements.
Rather than rewriting code endlessly to follow whatever “engineering best practices” have arisen in the last 2 years, which often don’t benefit end users