611–620 of 1001 posts
Surprisingly enough I got interviews from a big tech company. Definitely the biggest place I have ever interviewed, I don't even believe I'm getting interviewed. Didn't make it but lasted two rounds so at least I should have a bit more confidence.
The author's tone is condescending, angry and entitled. If everyday interactions with him followed the same tone, I would argue that he is the exact type of person behavioral interviews are meant to screen out (technically competent but a nightmare to work with).
>According to all the interviews I’ve failed over the years (I don’t think I’ve ever passed an actual “coding interview” anywhere?), the entire goal of tech hiring is just finding people in the 100 to 115 midwit block then outright rejecting everybody else as too much of an unknown risk. As a (now) senior/staff-level engineer back out on the job market for the first time in a while, I'm begrudgingly coming to accept…
From personal experience the coding round gets easier for senior/staff roles, even for the exact same question, because of the experience the interviewers have and the signal they are looking for (eg problem solving, communication, testing, etc.) At junior and "SDE II" level coding rounds are just toxic newly minted SDEs trying to make it a competition between the candidate and themselves ( I've got interviewers offe…
If the market uses a tool, and you don’t understand the tool, perhaps reserve judgement or even feign interest. The example of wrapping a CLI tool in docker does not make the argument the author thinks it does. It shows they resent standardization and are stubborn. I’ve turned down dozens of applicants for similar suggestions.
It’s fine to suggest or prefer simplicity, but it’s beyond silly to suggest only idiots are using tools like Docker and K8s. It’s weirdly common refrain from jobless developers: “I don’t know how to use your tools or what benefits they bring but I don’t like them”.
Okay, next?
In a way it reminds me of the arguments against modern cars: “too complex!”. The complexity serves a purpose; dismissal out of hand shows gross disrespect for the engineering skills of others.
To the OP: I'm certain you're an experienced and seasoned programmer, but your CV (on your website: https://matt.sh/files/a-resume/resume.html ) is an example of how not to write one. It's a wall of text and fluff, with too much focus on fanciness and design. I hire and interview people all the time, and your CV leaves me with zero sense of the impact of your work - only with the fact that you've done a bunch of stuf…
He misspells choices, fair, I make typos too. But might want to catch that on a résumé. Then comes across like he’s not getting the proper traction or respect for it. Fine, but probably don’t complain about that there, idk. I’d still hire him though.
To the OP: I'm certain you're an experienced and seasoned programmer, but your CV (on your website: https://matt.sh/files/a-resume/resume.html ) is an example of how not to write one. It's a wall of text and fluff, with too much focus on fanciness and design. I hire and interview people all the time, and your CV leaves me with zero sense of the impact of your work - only with the fact that you've done a bunch of stuf…
"Employment vibes"?! "The entire industry was sleeping on SSL and DHE ciphers..."?! And that self-quote at the top, wow. No names of the companies he worked for. It's hard to take this seriously. Over 15 years of experience each in Erlang, Smalltalk, Scheme, Objective C, regular C, Python, JS, and then 9 years of Swift. Seems... impossible. I'd be willing to believe C + Python + JS + one or two others, since that mix…
Erlang and C are complimentary.
Erlang calls code written in NIFs, coordinates C Nodes, and/or programs talking to the emulator over ports.
The original design goal of Erlang was to make it easy to write correct, concurrent, fault-tolerant supervisors and coordinators for complex, high-performance systems. (Like suchas telecom switches.) Erlang wasn't intended to be particularly fast, but to make writing concurrent systems easy, and provide fairly low and fairly predictable latency. One bounces out to C for performance-critical stuff, rather than writing it in Erlang... even today.
Earlier quoted context omitted.
> As in, a person who has used and learned a dozen plus languages but only tacitly used C++ suddenly will be a complete invalid when trying to write in C++? I've switched at least 5 languages professionally and used probably 5 more for extended periods of time and wrote a decent chunk of C++ "back in the day". I'd say C++ is the least suitable for "learn on the job" approach out of any language I can think of (I'm lu…
I generally agree with you, but I think it depends on the team. If the team is just "using" C++ but aren't good software developers, then yea, I totally agree that having a non-C++ expert join the team is going to be a rough ride for everyone. But if the team's software architecture and coding practices are solid, which probably means they use a subset of C++'s vast feature set in a very clear way, then one probably…
I will add my two cents for people who believe that this might be related only to the SWE and tangent industries: It's really not. I have many friends (in Europe) who are trying to get through to different jobs in unrelated industries ranging from finance to fashion, or just trying to get promoted vertically (or horizontally), failing rather miserably. Most jobs are now hoops after hoops, not taking into consideratio…