gered · HackerTrans

That's great! There's nothing wrong with that!

But what you're saying is NOT what the person I was responding to was saying, 'nor was it what I was responding to. I don't know if you read their post or not before replying to mine. Frankly, I'm not even sure if you even fully read my post if this is what you're zeroing in on ...

gered

3 年前discuss

This is a very narrow view of the situation. There are any number of reasons why some people may prefer working from an office.

Take myself as an example. I live alone, in a small apartment. My home "office" is a corner of my living room. I'm not "rich" and unfortunately cannot currently get a place big enough to have a dedicated room for an office. As a result, over a long period of time of working from home I end up getting the feeling that I'm living at work. In general, I prefer a strict home-vs-work separation, so going to a physical office elsewhere to work over the longer term helps me.

Other reasons include that some other people who prefer working from an office outside their home may just in general like the in-person social aspect that comes along with it.

It's shocking to me to now see a narrative like what you're trying to push that labels people who want to go to the office as terrible people. Jeez, wow!

gered

3 年前discuss

It's really sad, but yes, this is what I ultimately ended up doing too. There was no way to configure the filters to very closely approximate what the feed was showing previously that I could find. The new algorithm always seemed to want to throw stuff at you that was slightly outside the bounds of what you were specifically following (clearly done to help you "discover" something else that you may be interested in, treating it as if this was a social media platform instead of a coding platform ...).

gered

3 年前discuss

Hello! First time posting in one of these threads. I suspect it'll just get lost in here, but who knows!

I'm a developer who has been writing code professionally for ~18 years, but in total including my self-taught years as a teenager, etc, I guess it's almost 30 years of slinging code at this point.

  Location: Toronto, Canada
  Remote: Yes (EST timezone), also perfectly willing to do hybrid and on-site.
  Willing to relocate: No
  Technologies: Java (Spring / Spring Boot), Clojure/ClojureScript, Docker / Kubernetes, SQL (Postgres, MSSQL, Oracle, ...), Full-stack Web Dev, Backend Web Services, DevOps (Jenkins, Bash, Ansible)
  LinkedIn: https://www.linkedin.com/in/gered-king/
  Github: https://github.com/gered
  Website: https://blarg.ca/
  Email: [email protected]

These days I'd consider myself much more of a backend / web services developer. I've done plenty of full-stack web development over my ~18 year career, but over the past ~8-10 years almost all of the frontend code I've written has been ClojureScript, so I feel I'm totally out of the loop on what the JavaScript / TypeScript world is doing. And I just prefer backend stuff in general these days.

On the side, I work on hobby projects mostly relating to game development (see my Github profile). These projects are usually in Rust or C/C++.

Thanks for reading!

gered

3 年前discuss

Yup. It's absolutely crazy to me to see the amount of people who are apparently doing hiring telling others here in the comments (and elsewhere on HN, etc) that they should "grind leetcode" while also NOT admitting that this is absolutely stupid. Like I'll give you a pass as an interviewer / hiring manager if your hands are unfortunately tied and you can't change your companies hiring processes.

But if you're an interviewer or hiring manager who is telling people to "grind leetcode" because you legitimately believe this is a good way to find good talent ... you need your head examined. All you're doing is filtering for people who've grinded leetcode long enough to memorize solutions. This has ZERO correlation to software development ability.

gered

3 年前discuss

While that is obviously a detractor that I would agree with, how much it affects you will vary from person to person.

Again, just myself as an example, I've been somewhat surprised over the years how little I've actually needed a super key.

On Mac OS, my preferred keybindings was to have Command bound to both left and right Alt keys, Ctrl kept as the left Ctrl key, while the right Ctrl key was rebound to Option/Alt. Some people also like rebinding the usually-useless Caps Lock key but I am one of those weirdos who doesn't like doing that.

I've moved back to Linux over the past couple years and haven't found the need to do any rebinding to get a Super key on my keyboard at all.

Your mileage may vary!

gered

3 年前discuss

> I don't see any rational argument for a Model M in 2023. There are so many options in keyboards that are more modern, quiet, well built, compact and yet feel nicer to type on.

This is a highly subjective take. Just taking myself as an example, an original Model M feels far nicer to type on to me personally than any of the other modern mechanical keyboards that people often recommend.

There are absolutely rational arguments for a Model M. Just as there are rational arguments for other keyboards too. You just have to try to look at it more objectively and try to match to people's own unique personal preferences.

gered

3 年前discuss

> I've never had a test come later. 15 minute interview call to make sure the high level details are correct (pay, location, physical office vs. Remote, etc), and then I am sent an interview test.

Depends on the company. My personal experience has luckily been (so far) that more companies I've interviewed with who do take-homes at all have given them later on in the process.

I suspect with the current job market situation given all the recent layoffs that things will probably start to shift for those companies that do take-homes, where they'll probably start giving them to candidates at the beginning of the interview process, as they'll probably see it as an easy filter for themselves. Ugh.

gered

3 年前discuss

I don't think that's a "different opinion" at all! :-) I look at it the same way basically.

gered

3 年前discuss

See, I take a bit of a different view in the example you've given. Like, if I got rejected because I seemed "too excited about my personal side projects" I'd come away from that thinking "if that's really their take away, I'm kinda glad I don't work with them!"

You're right that the conversational interviews (just like any social gathering, really) have their own rules. But I think the most important thing you can do during those interviews is to just be yourself. After all, you want them to get to know you, just as you want to get to know them, right? How else can you each be sure that you're a good fit for each other? If they reject you for something you said that is true but that they just didn't like (e.g. a difference of opinion on something), or they nitpicked some little thing you said even though the rest of the conversation went smoothly ... well, in my opinion, you're better off.

gered

3 年前discuss

I mean I agree with you on this, but the idea that you can gauge a person's skillset through conversation (gasp!) and talking about your craft and details about past projects, etc seems to be totally lost on people today.

gered

3 年前discuss

It's been surprising to me to read through the comments posted here and seeing how most people seem to really despise take-home assignments during the interview process.

Speaking as someone who absolutely hates live-coding something during an interview (unless, maybe, by chance it's a practical exercise ... something like "build up this simple CRUD web service" ... not "solve this leetcode problem" ... but this is pretty uncommon in my experience, unfortunately), I rather like take-home assignments. As long as they don't take any more than 1-3 hours. I've been in situations where I've declined a take-home assignment that was given to me where I estimated it was going to take 10-20+ hours. No idea why any company would think that is reasonable.

For myself, what I hate is when the take-home assignment comes first. Like, before you talk with anyone at all, or maybe immediately after you did the 15 minute HR/recruiter screen. If I get a take-home assignment at that point, I decline.

There's no denying the fact that a take-home assignment is a large investment by the candidate on this random chance to get the job. I'm not willing to make that investment unless I've gotten a chance to talk to at least _some_ of the people I'd be working with at a company to better gauge what the situation is and whether I think it's a good fit for me. Even a 15-minute HR/recruiter screen is not going to do that. So yeah, if they just throw the take-home assignment at me right off the bat ... yeah, no thanks.

This all being said, yes, it is frustrating though to have to go through a bunch of these and get rejected with no feedback, or just ghosted, yeah.

gered

3 年前discuss

Isn't that what "Twitch Turbo" is?

gered

4 年前discuss

Yeah the (what I personally call it) "choose your own adventure" style approach to Clojure projects, where you don't use a framework like Rails, but just string together your own project from separate libraries, is really both a "pro" AND a "con".

It's great when you know what you're doing, and indeed, I have my own personal Leiningen templates to set up a Clojure project the way I like it and to save myself some time. Bigger project templates, like Luminus, I often find personally aggravating because I often feel like it just barfs a whole bunch of unnecessary and semi-complicated (in my opinion anyway) code in a new project even with the most minimal options chosen. But that's the power of the ecosystem ... you can create your own project templates to meet your own needs.

But a new developer getting their feet wet in this ecosystem? Yeah, it is hard. And even if they use an existing project template like Luminus to bootstrap their project ... well, the project template only helps generate the initial project. Ongoing maintenance for updating dependency versions and keeping a working integration of the libraries it initially set up for you (with respect to newer versions and any API/config changes, etc) ... well, those responsibilities are all on you! Kit (another newer successor to Luminus) _may_ provide some better alternatives here, but it'll still be limited with exactly how much it can help here. But I think it's still much too early to say one way or the other with Kit, so who knows.

(Also thanks for sharing your Ruby/Rails perspective on REPLs. A colleague of mine made some similar comments to me when we were discussing REPLs a while back, and I've not spent any time with Ruby so couldn't comment. It's interesting to hear! Most other REPLs I've used outside Clojure were not too useful as anything other than quick toys for trying short snippets outside of the context of a full project.)

gered

4 年前discuss

That's an interesting point I'd not thought of. I guess I'm more looking at it through the lens of "interacting with and modifying a running system" which kinda gives you a debugger (ish), compiler and execution environment all rolled into one. It's kind of nice to work in this kind of "scratch pad"-like environment while you figure something out versus the more traditional edit-compile-run cycle. But I have definitely seen what you describe as well, so I think that aspect is worth considering too, for sure.

gered

4 年前discuss

This is my experience exactly. I love the language and ecosystem in a lot of ways. I also believe that REPL-driven-development is a ridiculously productive way to work.

But I absolutely hate maintaining an old Clojure codebase (unless it's tiny).

The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get into a dynamic-versus-static-typing debate, but I've long since come to the conclusion that -- all other things being equal (hah!) -- if I have to dig into a large and old project, I'd much rather have types by my side than not. Code will not ever be adequately documented or commented (and even if it _seems_ to be at first glance, you will always have nagging doubts about how up to date that info really is). This is where type definitions help to figure out the shape of the data that any piece of code is working with. People talk about adding spec/schema definitions but that doesn't solve all the problems with not having type definitions unless you add these spec/schema definitions _everywhere_ ... and let's face it, you just aren't going to do that in any Clojure project. So, best case scenario is you still have a large collection of functions in your project that are calling each other, etc that you are left having to deduce yourself what this random map or list actually contains.