Anyone else feel like job hunting is harder than the actual job?

I've been job hunting for almost 10 months now, and honestly... I'm exhausted.

It feels like my life has turned into the same loop over and over again: applications, interviews, technical assignments, waiting, rejection emails, then starting from scratch.

At the same time I'm dealing with a lot of personal issues, watching my savings disappear, paying rent, taking care of my dog, and trying to build some kind of future while everything around me feels unstable.

The weird part is that I don't hate software engineering at all.

I actually love building things.

My background is mostly in QA automation and product quality in DeFi. I've worked on API testing, smart contract testing, CI/CD pipelines, TypeScript-based automation, and end-to-end testing.

Outside of work I'm building an open-source quantum circuit simulator in Rust simply because I enjoy solving difficult engineering problems. I'm also participating in a quantum AI hackathon, building a hybrid fraud detection project using CatBoost and quantum algorithms.

So it's not like I've lost interest in tech.

I've lost interest in this endless hiring process.

If I had enough financial stability, I'd happily spend my time building open-source software and learning new things instead of preparing for another interview every week.

I'm not posting this because I think the world owes me anything.

I guess I just wanted to say out loud that I'm tired.

Has anyone else been stuck in this cycle for months?

How did you keep going without completely burning out?

reddit.com
u/0xhokugava — 13 hours ago
▲ 1 r/learnrust+1 crossposts

Moving Grover to the Circuit API in my Rust quantum simulator

Small update on the Rust quantum simulator I posted about earlier. The latest change was about cleaning up how Grover search is implemented.

Previously, my Grover demo used direct state-vector shortcuts for the two main steps:

  • phase marking of the target basis state
  • inversion about the mean

That worked, but it bypassed the normal circuit path.

I refactored it so Grover now goes through the same Circuit API path as regular gates:

  • oracle: X gates + MCZ + X gates
  • diffusion: H, X, MCZ, X, H
  • MCX and MCZ are exposed through the Circuit API
  • the same operations are also available through the CLI
  • duplicate controls and invalid targets are validated
  • the old direct phase/diffusion shortcut layer was removed

The original result stayed the same:

Target state: |101>
Target index: 5
Target probability: 0.945313
Grover steps: 2

I also added external validation against an independently constructed Qiskit reference circuit:

Target state: |101> index=5
Target amplitude: 0.972272 + 0.000000i
Target probability: 0.945312

The next Rust-side cleanup is the internal circuit representation.

Right now, storing a gate as a matrix is enough for execution. But for export formats like OpenQASM, the circuit layer needs to preserve semantic gate identity too: H, X, CNOT, CZ, MCX, etc.

So the next step is to make the operation representation more explicit before adding export support.

Repo is here if anyone wants to look at the implementation or follow the project:
https://github.com/0xhokugava/quantum_lab

⭐ Stars are appreciated, but technical feedback is even more useful at this stage.

u/0xhokugava — 14 days ago

What do you think actually counts as a quantum measurement?

I’ve been trying to understand the quantum measurement problem more clearly. Operationally, the procedure is a quantum state evolves, we measure it, obtain a classical result and update the state according to the Born rule. What I still find difficult is the physical meaning of that process.

At what point does an ordinary quantum interaction become a measurement?

Is collapse a real physical event, an effective description produced by decoherence, or does collapse never occur at all?

I understand that quantum computing can work perfectly well without resolving this question - we calculate the outcome probabilities and update the state after observing the result. But that still leaves the conceptual gap between unitary evolution, entanglement with the apparatus, decoherence, and one definite observed outcome.

Which approach to the measurement problem do you find most convincing and why?

reddit.com
u/0xhokugava — 21 days ago
▲ 26 r/learnrust+1 crossposts

CLI for running custom quantum circuits with a state-vector simulator

I’ve been building a small quantum state-vector simulator. It now includes a CLI for running user-defined circuits:

qlab run --qubits 2 --gate h:0 --gate cnot:0,1

Output:

Qubits: 2, Gates: [H(0), Cnot { control: 0, target: 1 }]
State: (0.707 + 0.000i)|00> + (0.707 + 0.000i)|11>

CLI flow is:

→ command-line input
→ typed GateSpec parsing
→ qubit validation
→ Circuit API
→ matrix-free state-vector execution
→ Dirac notation output

One design decision was to keep parsing, semantic validation, and circuit application separate:

FromStr  → parse gate syntax
validate → check against circuit width
apply    → add the operation through the Circuit API

The simulator uses little-endian qubit indexing, with q0 as the least significant bit and the rightmost bit in printed basis states. The next step is a generic matrix-free implementation of controlled and multi-controlled gate primitives.

Repository: https://github.com/0xhokugava/quantum_lab

I’d be especially interested in feedback on the Rust API boundaries and separation between CLI representation and circuit layer.

u/0xhokugava — 23 days ago