Fork me on GitHub

How you deal with being ghosted by a company? I mean passing all interviews, code tests and so on. They just stop replying to the email before the offer. Happened to me this week for the second time with the same company (if they won’t reply on Monday but I doubt it). The first one I said to myself that was COVID time. But now there’s no excuses.


I'd say it says a lot about the company (culture). I'd stay away from it

🙌 1
Martynas Maciulevičius14:01:29

Stay away from those at all costs. Don't even think that they owe you anything. I've been part of some HR processes only to find out that they want to lock me into a contract such that I wouldn't be able to work for their competitors after they hire me. And they would own all code I produce on my private time too. Stay away.

Martynas Maciulevičius14:01:36

Also run away if they magically decide to change the "details" of the contract at the last second. Even if you did produce any kind of code. It's a liability on your side. At that point your emotions are your liability.


I once interviewed with a company, then got an offer a month later. Companies sometimes move at "company" time, which is very different than the timeline an applicant would like.


@U028ART884X that’s crazy. Thanks for sharing next time I will remember to double check the contract

Martynas Maciulevičius09:01:50

If you are employed not through direct employment then you may end up with a contract that can have some bad problems. For instance some companies like to force the worker to notify 3 months before leaving. Which means that after the moment you sign you can't change your workplace easily.


@eliascotto94 I think most companies have a tendency to do that, to be honest. A lot of companies don't bother telling candidates they didn't get the job.


@seancorfield I know and I think is wrong. They post marketing shit on LinkedIn everyday but they don’t reply to candidates. Also is worst when they ask you to waste your time to do a coding test for them. I pretend to be treated professionally no matter what. Is another downside of working remotely.


@eliascotto94 Yup, I agree that it's wrong. But it's common, unfortunately.


@eliascotto94 a common scenario that's happened to me (from a hiring perspective) is that you might be considering a shortlist of people and you can't really announce anything until all the interviews are concluded. Sometimes delays accumulate.


That said, I try to pre-announce timetables and if things start to slip I will try to inform candidates that things are taking longer than expected.


But wishful thinking does come into it: “ah, we're going to be done in a couple of days, no need to send an embarrassing email to 4 people”.


@orestis yes, informing the candidates is a good practice. Just a quick email that things are taking longer or you choose someone else. This time I’ve been ghosted at the final chat with fixed date and time…


Oh that's nasty


An email from the company after the candidate rejects an offer/position should also be a thing, very often isn't. At least to acknowledge the reception...

Nom Nom Mousse13:01:42

Do you know any resources that deal with Java and Clojure futures? Ideally, something to read like book chapters. This is the first time I touch them and my lack of understanding causes me headaches.

Ben Sless14:01:48

It's a bit of a broad question. Where's the problem? Where do you want to start?

Nom Nom Mousse14:01:44

So there isn't like a great chapter or resource you can read to understand it all?

Ben Sless14:01:03

You can try reading the brave clojure chapters, and the purely functional tv page

Ben Sless14:01:10

Concurrency is hard, if someone throws futures all over the code base it's even harder

Ben Sless14:01:50

Without being more specific I can't do much more than throw links at you, sorry

Nom Nom Mousse14:01:23

I really only use futures to start bash jobs, but I use callback functions to tell me when the bash jobs are complete. These callback functions seem to continue running in the new thread started for the bash jobs so in the end my whole program runs in new threads started in futures. And hence weirdness ensues.

Nom Nom Mousse14:01:38

Just links is what I wanted. I should try to read it all.

Ben Sless14:01:23

Are you using babashka/process?

Nom Nom Mousse14:01:45

Yes, but does that matter much? I think bb/process is just a wrapper

Ben Sless14:01:57

It is, but those don't need to run in threads, they're forked anyway

Ben Sless14:01:53

So I don't see why you need threads, exception handlers, etc

Nom Nom Mousse14:01:40

To run bash jobs asynchronously.

Nom Nom Mousse14:01:52

Often multiple at the same time

Nom Nom Mousse14:01:52

Okay, so these aren't threads, they are new processes? But does not the problem of my exceptions being swallowed happen whether they are threads or processes?

Ben Sless15:01:55

Because I'm not even sure how those processes bubble up an exceptional exit


@U0232JK38BZ by exception do you mean error in the forked process, or an exception thrown inside the jvm? I'd expect that if you successfully start a bash job, after that an exception in the jvm would be unlikely, and what you really want is to look at the stderr and return code from the bash job (or for poorly written programs you would need to check stdout too...)


unless you call .waitFor on the process object (or whatever options babashka abstracts that onto...), you don't need new threads here, starting a process returns a process descriptor that lets you access the return value and stdio of that process, and that's all you actually need


ProcessBuilder / Process are small enough, and simple enough, and well enough documented, that I consider it silly to use a library to abstract them


more elaboration: if you are using "bash" as your native shell, I assume linux or at least some *nix, and in that case an "exception" is an abstraction of the jvm (and may or may not exist in the language your forked program is written in), all that the underlying system really offers for failure detection are the conventions of non-zero exit codes and stderr output.


[It would be better for this to be in #beginners or even #clojure) because you already posted a related message there but let's see...] Many clojure books and articles talk about futures and some of their properties. • With regards to exceptions I linked in the other thread. Also (no longer available but you can find it in this archive link) • Joy of Clojure is an excellent, though a bit advanced book, for everything about Clojure including concurrency. • The article by Eric that Ben linked above is great Some other "random" links: •

🙏 1
Nom Nom Mousse13:01:37

> by exception do you mean error in the forked process, or an exception thrown inside the jvm? I do handle return codes in the bash process correctly. But the execution of my software continues in the new thread after the bash job is finished. And there I might have JVM errors.

Nom Nom Mousse13:01:29

So the forked process isn't just for bash jobs, the regular execution continues there afterwards (I think). This is the callback on the new process:

(defn add-completion-dispatch [java-proc jobid job]
    (.onExit java-proc)
    (reify java.util.function.Function
      (apply [this p]
        (reset! app-state/jobresult [jobid (.exitValue p) job])))))
I've heard that the watcher triggered by the change in app-state/jobresult continues in the new process. So after that my whole program is run in futures (I think)

Nom Nom Mousse13:01:55

Thanks for all the links btw. I'll make sure to read them. I'm so new to this it is hard to ask good questions even.

Nom Nom Mousse13:01:49

What I'd like to do is to start bash jobs in a subprocess and notify the main process when these are done and continue the execution there. But I can't figure out how to do it 😕 That is what I tried to do by updating an atom when the job was done. Perhaps queues can solve this? I have a lot of reading to do...

Nom Nom Mousse13:01:36

I guess if all exceptions in futures were handled I would be happy. But this snippet does not seem to work for Babashka processes:

;; Assuming require [ :as log]
 (reify Thread$UncaughtExceptionHandler
   (uncaughtException [_ thread ex]
     (log/error ex "Uncaught exception on" (.getName thread)))))


> execution of my software continues in the new thread after the bash job is finished I don't understand why a new thread is being constructed


I would keep a collection of Process objects, and check which are done (probably inside an atom)


I don't understand what exception you are talking about here

Nom Nom Mousse05:01:06

> what exception I was talking about exceptions in general. My concurrent program acted weird and I assumed it was due to threads dying silently.

Nom Nom Mousse05:01:06

> I would keep a collection of Process objects, and check which are done (probably inside an atom) This is a good idea. I could use a loop/recur that checked every 100 milliseconds as you showed me in the other thread.

Nom Nom Mousse05:01:10

> I don't understand why a new thread is being constructed I think this is what happened. My design was: 1. start a job in a new process (wrapped in a future) 2. when done, the process used a callback to tell it was done and start a new job using 1. I think this created futures in futures in futures etc.


Any recommendations for books that introduce programming using Python? For techies that don't have any prior programming experience whatsoever.


I would be remiss to not recommend I haven't read it, but I've met Al and he's an incredibly kind and smart person, and I've heard great reviews from my friends who've read it


That looks like a great match!


I have stumbled upon some bizarre Linux issue and would like to get some help figuring out what might've caused it. I went away from my PC for almost two months, but I took an M.2 drive with both the OS and $HOME from it, put it in a laptop, and continued doing my things from there. Had to make some minor configuration changes and whatnot, but everything went smoothly. Now I'm back home, I put the M.2 drive back into the PC, had some minor troubles with bringing the configuration back but after a couple of tries succeeded and now everything is working properly again. Except when I start Steam. On the PC before M.2 drive switch and on the laptop after the first switch, Steam was working just fine. After the switch back to the PC, it just hangs at log in. But it also hangs seemingly every single TCP/UDP operation in the system! I can't use ping, I can't restart network, I can't run ifconfig, I can't run ss for TCP/UDP sockets - all of the operations just hang indefinitely. All such processes turn into zombies and can't be killed. Surprisingly, existing connections seem to work just fine - at least, one video I was watching kept being buffered till the end, it kept receiving new data. Tried starting one such process with strace, got this:

ioctl(4, SIOCGIFCONF, {ifc_len=1200 /* 30 * sizeof(struct ifreq) */
and the process hangs there, and nothing can affect it. How can one possibly debug such a low level thing? Feels like the only thing I can try is to run an older version of the kernel and see if that works.


Yep, downgrading the kernel did the trick. The funny thing is, I had to upgrade it to an "edge" version specifically because of the laptop, to make something specific work - the hardware was too new for the current kernel.


I don't have any advice for this specific scenario, but I do recall that either Steam, and/or some popular games installed via Steam, have some kinds of software included that tries to prevent people from using software that gives them an unfair advantage in certain on-line multi-player games? That sounds like the kind of thing that could cause low level hacks in the OS.


I suppose you have already tried uninstalling and reinstalling all Steam games, and Steam itself?


Sounds like anti-cheat software, and in this case it would be VAC - Valve Anti Cheat. And yeah, wiping Steam completely didn't help at all. But my bet is on some issues within the newer kernel - after all, it hasn't been made the current one yet, so people are still testing it, at least for Ubuntu 21.04.


I remember a similar problem I had with a very old Linux, and indeed I had to change the Linux distro (at the time, I didn't know how to change kernels, or it was too hard, etc)