Comment by dxy3 | Hacker News Reader

Comment by dxy3 | Hacker News Reader

Parent Full thread

Some ideas (from a guy in his 40s who interviews every 6 to 12 months for high paying short-term project work):

- 25 years at a single company is working against you. Remove all that from your cv and just list the recent stuff you built.

- Most of your cv should be description of the repos with links. Cut out and summarise past experience ruthlessly, like you’re refactoring someone else’s old code.

- Remove the link to your personal git page, use the other one. On first sight it looks weak - it has some html files and a lot of docs. My first reaction was “meh”. It took me many minutes of browsing to figure out the real meat was in the other repo And then my reaction was “wow”. Most hiring manager don’t have time for this. People are not clicking on the green squares they are clicking on the source repos, you have about 30 seconds of their time.

- At this stage you might get bored or unhappy real fast in a job, if you are honest to yourself. Consider selling short term access to deep technical expertise - in your case Mobile Bluetooth on iOS.

Thanks!

Well, the long-term work is staying in the CV. I worked for 27 years at one of the most storied and respected Japanese corporations on Earth, at a very deep level. This says a lot about my aptitude, ethics, Honor, Integrity, team dynamics and loyalty. I sure as heck don't want to work for any company that thinks of that as a bad thing. Most of my tech work has been done in the open. I've been doing open-source work for over twenty years; which gives me the advantage of a vast portfolio.

I was a hiring manager for 25 years. Hiring people was a very important part of my work. I managed a small, high-functioning team that did image pipeline "engine" code in C++. Getting headcount was a huge battle, and I kept employees for decades. I loved multi-page CVs. "Draw Spunky" tests were absolutely worthless in evaluating people that would become part of my team. Interviews were often very casual affairs, where I'd encourage people to tell me stories about their work.

I have a Stack Overflow story that lays out my work in a linear fashion[0], or CV fashion[1]. I kind of like the idea of an SO story. It's fairly direct in pointing to my work.

My experience is that the vast portfolio is ignored by hiring managers (recruiters are much, much worse). I used to send links to relevant projects, when applying, only to have them completely ignored, in favor of a 50-line binary tree test. I have come to realize that binary tree tests are "young pass filters," as the only place binary trees actually exist, are in colleges. If a company gives a binary tree test, then I know they aren't interested in me, and are just ticking an "Interviewed old fart" checkbox.

[0] https://stackoverflow.com/story/chrismarshall

[1] https://stackoverflow.com/cv/chrismarshall

To be explicit here, it sounds like you're saying that you don't think you perform well on data structures questions in interviews, for example binary tree questions. Is that right?

Not really. I just don't practice them. I'm way too busy writing shipping software that has very little use for the kinds of academic exercises in LeetCode/HackerRank stuff.

Sometimes, I do great at them. Most are common sense.

Usually, I'm mediocre.

There's thousands and thousands of energetic folks out there; young and old, that practice these every day, and can usually ace them in an interview.

There's no way that I'm even gonna try to compete with them. They'll smoke me. They worked hard for that, and I respect them. I would hope this is indicative of them being good employees, but I can't really see how these tests would indicate that better than a simple conversation.

That said, since I've been writing deployed/shipping/sold software for decades, I suspect that I might be doing something right.

In fact, today, I am polishing up a simple Observer infrastructure[0] for a mesh networking driver that I'm working on. One of the basics of my workflow, is if I'm working on a project, and see that the part I'm working on might be more generically useful, I stop work on the main project for a day or two, while I break that section out into a general-purpose module. It helps me to write much better software.

I'm rather obsessed with Quality, and this practice is one way to get that.

I'm not sure that there's LeetCode for that kind of practice, and I can't really see it happening in a timed whiteboard test.

It is, however, very easy to see; simply by looking at the GH repo.

[0] https://github.com/RiftValleySoftware/RVS_GeneralObserver

This is so well articulated. Thank you.

I’m a 25 year old developer that’s only been working full time professionally for ~3 years and I came to a very similar conclusion about you regarding the LeetCode style interviews. I’ve always been allergic to bullshit and smelled it clearly and instantaneously when I began wading into that process.

Undoubtedly I’ve closed doors and passed up opportunities through my refusal to contort myself to the LeetCode regime. At the same time, the time that I would’ve spent drilling myself on superficial coding puzzles I’ve instead invested in building practical applications for my friend’s business, learning and applying machine learning theory to automate a boring task during an internship, implementing a processor in Verilog and writing an assembler for its ISA that I managed to get running on an FPGA, working on an open source digital contact tracing app, and several other projects.

The projects I’ve spent time on are those that I deem to genuinely valuable to society and to my personal skill development in the broadest, most fully integrated conception of ‘valuable’ that I can achieve. To clarify, I could see an counter point being made that LeetCode skills are “valuable” in the sense that I could use them to get a higher paying job at $TECH_CO. But from a higher level perspective, those skills are tailored towards a system (the LeetCode hiring gauntlet) that I think is fundamentally corrupt, and so to spend my energy practicing them for the sake of that system would be corrupting of my integrity.

And despite the admonitions I’ve received from supposedly more pragmatic-minded people, I’ve been able to pull together a living and have a budding career to speak of. My job hunts have perhaps been more drawn out and frustrated than the LeetCode crew, but I believe my focus on genuine knowledge and skill development has contributed to my high performance at the jobs I have managed to land. And by being straightforward about my disinterest in hoop jumping and interest in “real skills”, I’ve managed to befriend and work with companies and people that share similar values to me, who in my view are more rewarding to work with and tend to be more likely to succeed in the long run.

That sounds excellent! I support you completely, but my support may not be that relevant.

Coding tests; at least Codility/LeetCode style, are now pretty much worthless, as there’s an entire industry devoted to helping folks pass them.

I just love doing what I do. It sounds like you do, as well.

Every hour I spend, practicing for interviews, is an hour I’m not spending, learning new, practical stuff.

While I don't think that whiteboarding aho-corasick from scratch is a good quality interview. I don't think algorithms and data structures are useless or impractical. IMO a basic understanding of the main data structures is important and useful in the day to day.

Granted, some applications will involve more or less use of data structures/algorithms than others, but if you discount them completely you mark yourself out of a whole subset of work.

I would want most of my fellow employees to know what a trie/binary tree/linked list/vector/array/etc is, and I would want them to know how to evaluate space and time complexity of the code they write. What is a good style interview for that is an open question, but I don't think the content is impractical.

By all means, spend your time however you like. I just think it's unfair to call knowledge of these sorts of things "impractical". Impractical for whom?

Point taken, and I agree.

> vector/array

Those two, yes (and vectors really only apply -as such- in C++), but the rest? It depends (the best answer to every conundrum).

I write consumer/developer software; not ML or Big Data Mining stuff. My work is generally in device control, user interface, SDKs, APIs, etc.

That means, that, in over thirty years of writing software, I have encountered exactly 0.000000 binary trees. BTW: Binary trees and linked lists can be an issue in parallel-type programming. We had some image processing algorithms we did that used similar structures, and we had to be very careful. We often had to back out optimizations.

Writing consumer software has issues that don't seem to occur to folks writing engine software. These are things like localization, security, adaptive user interfaces, aesthetic design, information architecture (hoo-boy), responsive controls, branding, testing (all kinds of testing), etc.

That "information architecture" one is a big deal, and almost everyone falls down on it. This is most obvious in settings. Engineers design settings to match the underlying architecture, and don't worry too much about how they will be perceived by users. The result is the infamous "Find the hidden setting" game. I just went through that, yesterday, helping a friend set up a Zoom meeting. Fun! I also just went through it yesterday with my wife, and her Mac. Apple has started to segregate settings the same way, and there be dragonnes.

Testing is another big one. Everyone is fixated on automatic testing and unit tests. If a project comes with a bunch of unit tests, then everyone thinks it's "high quality."

There's issues with relying on unit tests alone. I write about that here: https://medium.com/chrismarshallny/testing-harness-vs-unit-4...

Also, if we write device control, or a lot of communication software, unit tests can be worse than useless. Usability and accessibility testing are also something that can't really be automated.

Shipping software is really boring. There's a lot of "'snot mah chob, man!" stuff involved, that, nonetheless, needs to be done by someone, or we end up with steaming piles of crap.

Some of that involves the programmers directly. For example, do we habitually autodoc document our method headers and class/struct definitions? Do we use tokens and localizedVariant calls for all displayed text? Do we follow good secure programming practices from the start? How would a blackhat use this function I just wrote? Do we throw dependencies in as a first resort? Is that good, or bad? Do we know what that dependency we just committed the company to does? What's our testing strategy? How will we integrate this, and when? etc.

Also, power usage. That's a big one, if we do mobile or embedded software. Sometimes, highly optimized code is the worst code to run, as it can drain the battery, or end up with really strange race conditions between chipsets.

That's practical stuff. When you're a one-man shop, like me, you get to deal with all of it. I was also quite involved in all of it in my last job, where we were a huge, global team, supporting some pretty intense hardware products.

> Those two, yes (and vectors really only apply -as such- in C++), but the rest? It depends (the best answer to every conundrum).

I think other systems langs make the distinction, Rust does also, this is what I've been doing at my day job lately.

> That means, that, in over thirty years of writing software, I have encountered exactly 0.000000 binary trees.

I've been doing it for a third of that time and I've encountered binary trees and all kinds of other data structures a bunch of times. I don't do any big data or ML stuff, I was writing React frontends for about half of that, the last few years it's been systems programming with Rust; I still encountered these types of structures writing JS though.

> BTW: Binary trees and linked lists can be an issue in parallel-type programming. We had some image processing algorithms we did that used similar structures, and we had to be very careful. We often had to back out optimizations.

When sharing any memory between threads or tasks you have to be careful, I'm not sure there's anything special about binary trees or linked lists. Consequently Rust makes this sort of thing very nice.

I'm not sure how to respond to the rest of the comment. Personally, I'll take an expressive type system over a comprehensive unit test suite.

I'm not discounting your personal experience but I find it hard to believe you aren't encountering these types of problems, unless you are but just not noticing it. Curious about what kind of 'optimized' (optimized for what?) code is 'the worst'?

edit: I just re-read this and realized the tone was a little aggressive, I don't mean to come across that way, my bad.

I also apologize if I came across aggressively.

I ran a C++ shop for 25 years. We wrote “pipeline” software for image processing. REAL heavyweight data processing/DSP stuff. Optimizations were crucial, and we often took advantage of things like GPUs, and threading.

There be dragonnes...

I learned that explicit threading is a scary place, full of surprises.

Nowadays, I write in Swift (which I love -I think that Rust is similar). Explicit threading is barely supported, which is just fine, by me.

I can get defensive, because I have been treated rather badly, simply because of my age. No one ever bothers to look at my portfolio. They just start with the condescending drivel, sometimes, even accusing me of “faking” ten years of commit history, hundreds of thousands of lines of code, dozens and dozens of repos, hundreds of pages of articles, documentation, prose, and training modules.

It was exactly this kind of behavior that convinced me to not even bother trying to get work.

I’m not arrogant. I’m actually a really decent person; warm, compassionate, and a great team member. My LinkedIn profile is jammed with testimonials. I worked on a team with some of the finest engineers and scientists in the world, and had their complete confidence and trust.

But that doesn’t mean a thing, if I can’t give a proper answer to a “Draw Spunky” test.

Applying the most generous interpretation principle[1] I suspect the binary tree test is not an old fart screen. Just a poor test of job aptitude.

Unfortunately, hiring is fairly broken in our industry, if you want a job, the best use of your time is probably to practice those coding tests.

[1] https://www.omahaic.com/blog/mindful-moments/mindful-moment-...

Nah. I like writing code that ships. If it means that no one wants to hire me, I can live with that.

It does say a lot about the industry, though, that people don't care about shipping software.

Might explain some of these Jurassic-scale disasters we're constantly reading about...

Reply on news.ycombinator.com