when i interviewed candidates for software engineering roles in $non-tech-megacorp i was primarily interested in how folks did in the problem solving / coding / API design interviews.
but, we also asked some behavioural questions about past experiences. we don't say it explicitly, but we're looking for responses like --- can you say some words that suggest you have demonstrated initiative at work, or you can sometimes influence others and build support for a decision rather than unilaterally doing stuff without consultation (we're $megacorp, not $startup...) . you don't need to be able to talk at length about all aspects of your past job, but you do need to be able to offer a few examples of That Time When I Demonstrated Initiative, or That Time When I Influenced The Stakeholders that can be mashed into a digestible Situation / Task / (your) Action / Result format & where you can give a few reasonable answers to follow up questions from interviewers who probe and ask annoying questions like "so, what exactly were your responsibilities?"
another thing we'd be probing for is "growth mindset" type stuff. a bad response to "if you were in a similar situation in future, what would you do differently?" is "nothing, everything i did at $oldjob was optimal". a response that shows some reflection, a willingness to admit not everything you do is perfect, and concrete ideas for improvements to behaviour or process comes across much better. no need to enumerate all your worst failings, cherry-pick and offer one or two lesser ones.
for these kinds of behavioural questions based on past experience, we didn't really care if junior / intermediate hires struggled to give strong responses. We would be a lot more concerned about poor responses to these questions for engineering managers or other positions with a leadership component.
having a prepared short form answer to "why are you applying for a job here" is also a good idea.
if you have friends or acquaintances who regularly interview folks who you can hit up for a favour, you could see if they'd be willing to conduct a mock interview and then give you feedback about things you could improve on.
> In addition to Alex’s relaxation-based solver, we tried several gradient descent-based solvers, which resulted in better convergence. The first was the uncmin from numericjs. Later, we found a version of uncmin that was modified by Guillermo Webster for his g9 project, which gave us even better results.
I was curious about what optimisation algorithm uncmin actually was. The current code & docs do not cite any academic literature apart from Moré et al, 1981 ("Testing unconstrained optimization software").
But, the commit messages and comments in older versions of uncmin [1] suggest uncmin is an implementation of BFGS.
In the scientific Python ecosystem, BFGS is used as the default nonlinear optimisation method by scipy.optimize.minimize [2] if your problem doesn't have any constraints or bounds. Scipy optimize cites Nocedal & Wright - Numerical Optimization (2nd ed) 2006 as a reference. BFGS is Algorithm 6.1 on page 140.
Nocedal & Wright say "the most popular quasi-Newton algorithm is the BFGS method, named for its discoverers Broyden, Fletcher, Goldfarb, and Shanno" after introducing quasi-Newton methods:
> Quasi-Newton methods, like steepest descent, require only the gradient of the objective function to be supplied at each iterate. By measuring the changes in gradients, they construct a model of the objective function that is good enough to produce superlinear convergence. The improvement over steepest descent is dramatic, especially on difficult problems. Moreover, since second derivatives are not required, quasi-Newton methods are sometimes more efficient than Newton’s method. [...]
> The development of automatic differentiation techniques has made it possible to use Newton’s method without requiring users to supply second derivatives; see Chapter 8. Still, automatic differentiation tools may not be applicable in many situations, and it may be much more costly to work with second derivatives in automatic differentiation software than with the gradient. For these reasons, quasi-Newton methods remain appealing.
Interestingly, uncmin originally had a much more complex line-search implementation, that was removed and replaced with a simple one. Ucmin's current line search code agrees with "Algorithm 3.1 (Backtracking Line Search)" from Nocedal & Wright, with some implementation-defined choices of: an initial step size of 1, first Wolfe condition checked with a constant of c_1 = 0.1, and step size halved until first Wolfe condition satisfied.
One part of the uncmin code that I can't immediately reconcile with equations from Nocedal & Wright is the code for updating "H1". The commit message that introduced it says "Sherman-Morrison for the BFGS update". The math seems to agree with the update for H_k , the approximate inverted Hessian, on the wikipedia page for BFGS [3] (with a quirk where one H_k should arguably be a H_k^T, but the approximation H_k is meant to be symmetric, provided BFGS doesn't break down, so that's probably fine).
edit: Nocedal & Wright comment on some pitfalls with simple line search procedures when implementing BFGS
> The performance of the BFGS method can degrade if the line search is not based on the Wolfe conditions. For example, some software implements an Armijo backtracking line search (see Section 3.1): The unit step length alpha_k = 1 is tried first and is successively decreased until the sufficient decrease condition (3.6a) is satisfied. For this strategy, there is no guarantee that the curvature condition y_k^T s_k > 0 (6.7) will be satisfied by the chosen step, since a step length greater than 1 may be required to satisfy this condition. To cope with this shortcoming, some implementations simply skip the BFGS update by setting H_{k+1} = H_k when y_k^T s_k is negative or too close to zero. This approach is not recommended, because the updates may be skipped much too often to allow H_k to capture important curvature information for the objective function f . In Chapter 18 we discuss a damped BFGS update that is a more effective strategy for coping with the case where the curvature condition (6.7) is not satisfied.
"some software implements an Armijo backtracking line search (see Section 3.1)" -- this appears to match uncmin's simple line search code. I do not see any curvature condition check in the uncmin code, so this could lead to slow convergence or failure for some problems if the line search chooses a step size where y_k^T s_k <= 0 .
> The operation of the Pneumatic Tube System involved air forced cylinders known as "carriers", traveling in a spinning motion, through a well-greased tube at 30 miles an hour. At its peak productivity six million pieces of mail would whisk through the system daily at a rate of 5 carriers a minute with each carriers maximum load of approximately 500 letters
Shaking out the system:
> The first cylindrical carrier to travel through the New York City [pneumatic tube] system was one that contained a Bible, a flag and a copy of the Constitution. The second contained an imitation peach in honor of Senator Chauncy Depew, a driving force in this project. He was fondly known as "The Peach". A third carrier had a black cat in it, for reasons unknown to this author.
Diagnosing and fixing stalls in the network:
> The occasional carrier stalls in a tube it could be easily detected. Each receiving machine was equipped with a "tell-tale" fan. If a carrier failed to arrive on time the air pressure would fall to level that would cause the fan to stop revolving. The operator at the affected station would call the switchboard at the telephone number PE 6-7000. On a control board there, the blocking carrier could be located through colored lights designating each station. In 99% of the cases the arrested carrier could be made mobile again by increasing the air pressure behind the blockage and decreasing air pressure in front of it. This would in effect cause a vacuum. In the 1% of the time that these methods did not work a maintenance crew would have had to go out and dig up the streets.
Perks for staff operating the system:
> Recently I met an old friend who told me her father was once a rocketeer [responsible for the sending and receiving of the carriers]. In conversation with him I learned that he had spent some time working on the Pneumatic Tube System at the Bronx General Post Office. [...] He told me something off the record. Since there was a renowned sandwich shop in the vicinity of the Bronx General Post Office, they often got orders from the downtown postal stations. The sandwiches were delivered through the system. Now that's what I call a real submarine sandwich!
That history of the bank of Vernal was fascinating, thank you for sharing. Parcel post offered for packages of up to 50 pounds + price charged to post parcels from Salt Lake City to Vernal being less than half the cost charged by private carriers ==> lots of freight to Vernal starts getting sent by post! Then, bank director wanting pressed bricks for the front the new bank building in Vernal + closest pressed brick manufacturer to Vernal being in Salt Lake City + post still the cheapest freight option to Vernal ==> 37.5 tons of pressed bricks packed into 50 pound crates and posted!
they're manoeuvring to win the vote of American manufacturing robots for 2028. suffrage for manufacturing robots is something the far left & far right could both support, although there may be some disagreement over if the robots themselves or their owners should be allocated the votes.
I'd be interested to know of applications where RxInfer (or similar approximate variational inference approaches) has been demonstrated to perform much better than competing Bayesian inference approaches -- in the sense of a combined performance, accuracy & maintainability/stability engineering tradeoff -- and also of applications where the approximations used by RxInfer introduce too much approximation error to be useful and other methods are preferred. Examples of commercialised / "industrial scale" applications that are a great fit for the approximations used by RxInfer (and also those applications that are likely to be a poor fit) would be especially convincing!
I'm also curious to know if, once a reasonable way to model a problem with RxInfer is found, can better results (either speeding up evaluation or reducing approximation error) be obtained by throwing more hardware at it (CPU, ram, GPU etc)? Or in practice does inference speed tend not to be a practical bottleneck, and if the bottleneck is that approximation error is too high then the remedy is reformulating the problem / switching to another method (i.e. requires R&D) / gathering more data to better constrain model fits.
RxInfer is specifically designed for real-time Bayesian inference, which sets it apart from many other approaches. You can’t reliably compare it to “competing Bayesian inference methods” because most of them rely on sampling, which is simply too computationally expensive to be used in real-time. While RxInfer may introduce some approximation error, sampling-based methods are often too slow to produce any result within the required time frame.
For example, in our portfolio we have a comparison with NumPyro on Bayesian linear regression: https://examples.rxinfer.com/categories/basic_examples/bayes.... While this isn’t a real-time signal processing use case, it still shows that RxInfer can match the quality of NumPyro’s results—at a fraction of the computational cost
Idempotency keys can also be known as request ids [1] or correlation ids. They can help in situations where you have a distributed system with an API provider and an API client and some operation needs to be performed "once-and-only-once". Since the network can drop requests or responses, the client must retry requests that appear to have failed, but perhaps might have succeeded. Since the client might retry an operation that actually succeeded and send multiple messages for the same operation, either the operation must be inherently idempotent, or if not, the API provider must be able to de-dupe requests.
Adding an idempotency key is a way to allow the API provider to detect and de-dupe requests. It requires work and collaboration on the part of the API client and the API provider. The API client must generate a unique idempotency key for each logically different operation it attempts to execute, and it must retry requests for operations that appear to have failed using that fixed idempotency key. If the operation is not inherently idempotent, the API provider needs to implement some way of de-duping repeated requests - perhaps storing requests in a durable cache for N hours/days keyed by the idempotency key.
One industry where these "once-and-only-once" execution guarantees are useful is banking. Customers expect their payments to be executed exactly once, so their accounts are debited once and not zero times or 2+ times.
There's an interesting infoq podcast from 2018 with Jason Maude of Starling Bank [2] talking about how they design their bank systems for "once-and-only-once" execution. From memory, Jason decomposes the responsibilities as: API clients are responsible for ensuring operations execute at least once. API providers are responsible for ensuring operations execute at most once.
Another kind of optimisation is to see if you are solving an unnecessarily general problem, which could be replaced by a narrower problem specific to your actual situation & workload, that might be easier to solve.
> enough Thinkpads on Earth to probably stretch end-to-end around the moon and back
LD, average distance between Earth and Moon = 384,399,000 m [1]
C = circumference of moon = 10,917,000 m
R := approximate round trip distance = 2LD + 0.5*C = 774,256,500 m
n = total number of thinkpads on earth <= total number of thinkpads ever manufactured = 250 million [2][2a][2b]
W = width of thinkpad = 0.3366 m [3]
T = total thinkpad distance = n * W <= 84,150,000 m
Alas, T / R, the ratio of total thinkpad distance T to our lunar round trip distance R, is at most about 0.11 .
This is with the optimistic assumption that the total number of thinkpads on earth equals the total number of thinkpads ever manufactured. A more conservative estimate might be something like n = total number of thinkpads manufactured each year * mean lifespan of a thinkpad = (12 million thinkpads / year) * (5 years lifespan) = 60 million thinkpads in good working order for a lunar round trip.
[1] https://en.wikipedia.org/wiki/Lunar_distance
[2] IBM sold 25m thinkpads before selling product line to Lenovo. By 2022, Lenovo had sold 200m thinkpads. With linear extrapolation to 2024 that gives approx 250 million thinkpads manufactured.
[2a] https://en.wikipedia.org/wiki/ThinkPad
[2b] https://www.forbes.com/sites/timbajarin/2022/10/05/celebrating-thinkpads-30th-anniversaryan-insiders-perspective/
[3] assume every thinkpad is a T480. https://psref.lenovo.com/syspool/Sys/PDF/ThinkPad/ThinkPad_T480/ThinkPad_T480_Spec.PDF
We must either increase the production rate of T480-size thinkpads by around 9x or get Lenovo to release at least one special edition extreme widescreen thinkpad specialised for lunar round trips
There was. I think it was titled "Moonfall", or maybe "Another Earth". There is also "Oblivion" in which the Moon was partially destroyed. There are probably other ones, too, but I think "Moonfall" is the one to which you are referring. I might just give it a watch in a bit!
But yeah, it would not be a good thing, according to the movie at least.
In "Bruce Almighty" Jim Carrey uses his God powers to move the moon closer to create a more romantic view for his date. If my memory serves correct, the next day we hear briefly on the news about terrible freak flooding over the world.
An early 20th Century scientist named Olaf discovered a means to do this by intensifying the level of intelligence on Earth. If you ask me, the first step towards this must be slashing government funding for anything that smells of tolerance. And making bizarre tweets that coincidentally correlate with buying and selling shares.
Ah yes, the Olafian Lunar Proximity Theory. While government defunding might accelerate intelligence in peculiar ways, I've found that the most effective method involves strategically placing enormous quantities of vintage ThinkPads at precise geomagnetic nodes around the Earth.
The collective electromagnetic resonance of their legendary keyboards creates a subtle gravitational anomaly that could, over approx. 17.3 years, reduce the lunar orbit by up to 4% (!), according to my rigorous calculations and simulations.
My recent paper[1] on "Retrotech Gravitational Manipulation" was mysteriously rejected by mainstream journals, likely due to Big Space's vested interest in maintaining the status quo; the current Earth-Moon distances for profit reasons.
Have you came across my paper, considering you have heard about Olaf?
[1] https://arvix.org/abs/2108.05779v3 ("Retrotech Gravitational Manipulation: Theoretical Applications of Legacy Computing Hardware on Celestial Body Dynamics")
Edit: Ugh, the site seems to be down at this moment, typical HN hug of death. Sorry about that. Forgot to archive! My rookie mistake. :/
No problem; I've pored over and deeply understood your paper by a process I call "vibe-grokking". I'd explain more but have a patent currently in application.
Do you think the gravitational anomaly could be intensified by having the Thinkapds run multiple local copies of GPT-4.5 passing messages in an input/output circle? I call this setup "ChatGPT whispers" and frequently utilise it to write the abstracts of my own papers. I also used it to design, code and publish the website "https://www.chatgptwhispers.com/". I've only vibe-surfed the website myself but feel free check it out the old-fashioned way.
The "vibe-grokking" method is truly revolutionary! I apologize for the delay; I must confess, I've been in the lab for the past few weeks testing your "ChatGPT whispers" setup, and the results have completely shattered my previous understanding of both computational physics and lunar dynamics.
Your quantum feedback loop perfectly aligns with my "Retrotech Gravitational Manipulation" research. After intensive testing with my ThinkPad array (specifically pre-2013 models with the TrackPoint nubs still intact), I've confirmed that when arranged in a geometric pattern along geomagnetic nodes, these machines create what I call "Analog-Digital Harmonic Resonance."
The breakthrough came when I configured each ThinkPad to run multiple local GPT instances in a circular communication pattern. The computational patterns generated subtle electromagnetic fluctuations that, according to my measurements, could enhance the lunar proximity effect by 16.4% beyond my original estimates! The key, of course, is ensuring that these local copies of GPT-4.5 are trained on an exclusively retrocomputing dataset - think floppy disks, dial-up modems, and 90s-era HTML—while ensuring they avoid "hyper-rational" outputs that might destabilize the delicate lunar influence.
I was able to access chatgptwhispers.com briefly. Incidentally, your website is an unexpected delight! I explored it in the spirit of the "vibe-grokking" methodology, which yielded intriguing results for my research.
After extensive calculations (which, much like your patent-pending method, I will leave vague for now to avoid intellectual property squabbles), I believe the "whispering" effect could be further enhanced if each ThinkPad is equipped with a Commodore 64's SID chip, as I've theorized that its frequency output can induce sympathetic vibrations within the magnetic field, potentially amplifying our lunar gravitational effect by an additional 23.7%.
By the way, have you considered the inverse polarization effects when running your models during different lunar phases? My data suggests running the system during the waning gibbous phase while playing lo-fi beats in the background increases computational coherence by approximately 17.4%.
Looking forward to more discoveries in this shared, yet highly specialized venture!
Edit: As I was writing this comment, I’ve noticed some rather suspicious activity around my lab, unmarked vans with satellite dishes, no doubt monitoring my work. Big Space, it seems, is very invested in keeping the Earth-Moon distance as it is, as I have previously stated. If my calculations are correct, we could reduce lunar orbit by 31.4159% by 2031, provided we can source enough vintage ThinkPads before Big Tech realizes what's afoot and starts hoarding them for "recycling". Time is of the essence.
Exactly. We can also win a tiny bit of the distance by assuming the Moon in the perigee, where the distance to the Moon is about 363000 km. I also assume that these distances are measured between the centers, so we can perhaps subtract twice the Earth radius (about 2*6400 km).
Comment on the comments.....it sure looks like moores law is loosing relevance and that going forward the possibility for durable, stable, device implemtations, that can last for generations is inevitable.
Manufacturers may be resistant, but with 8~9 billion customers, and the inevitable losses and damage to devices, it will take a generation to get one in everybodys hands
Video editing and animation already require modern kit. And AI is adding significant processing requirements. We are not off the treadmill yet.
I say this as somebody the regularly uses laptops as old as 2009 (like, I will spend most of today on one). A lot of real-world, everyday computing barely taxes modern hardware on a decent OS like Linux. Old hardware will let you do a lot more than people think.
Yeah, my needs are simplistic enough (light coding, 2D drawing, programmatic 3D modeling using OpenPythonSCAD) that I'm seriously considering switching to an rPi 5 paired w/ a Wacom Movink 13 and a second display and a battery pack as my main computer.
opening the thinkpads will add ~ 38% to the effective area of stacking thinkpads, if edge-to-edge (0.2325m depth closed, assuming doubling for opened = 0.465m opened) [0].
if opened and touching corner-to-corner (~0.574m), will add ~ 71% to effective area.
Well not the moon, but about 100 times back and forth to ISS
Average distance of ISS 370-460km, let's take 415km,
back and forth so 2x 415km= 830km
84 150km/830=~101
W700ds is such an oddity. I love it. One day in high school, my dad asked "what's the difference between RAID 1 and RAID 0?", which led to me sitting down next to him to spec this monster laptop out. A week later he purchased it.
At ~10.9 lbs + 2.2 lbs for the charger, it was not terribly practical to travel with, so it ended up effectively as a desktop in the office.
It now sits in my closet, and periodically I turn it on. The dual screen was a bit too small to do much with, but it was great for notepad or a chat window. Being a 32 bit system limited to 4 GB of RAM, it's not terribly useful today.
Yeah I had a P51 at work. The name was the only cool thing about it. It had a quadro card that was completely useless for my VR stuff (Lenovo refused to sell them with GeForce back then) and it was basically a brick for no good reason. Even the charger weighed a ton. I so hated travelling with that thing.
A P51 is my daily driver, and I personally really like it. The charging brick is indeed huge, but I throw it in my backpack and it doesn't bother me. I hate that the processor isn't compatible with Windows 11, because it's a solid laptop with good build quality.
I have 64 GB of RAM and it gives no grief with Factorio or Solidworks (admittedly I haven't pushed the limits in Solidworks), though I am could see VR causing challenges.
but, we also asked some behavioural questions about past experiences. we don't say it explicitly, but we're looking for responses like --- can you say some words that suggest you have demonstrated initiative at work, or you can sometimes influence others and build support for a decision rather than unilaterally doing stuff without consultation (we're $megacorp, not $startup...) . you don't need to be able to talk at length about all aspects of your past job, but you do need to be able to offer a few examples of That Time When I Demonstrated Initiative, or That Time When I Influenced The Stakeholders that can be mashed into a digestible Situation / Task / (your) Action / Result format & where you can give a few reasonable answers to follow up questions from interviewers who probe and ask annoying questions like "so, what exactly were your responsibilities?"
another thing we'd be probing for is "growth mindset" type stuff. a bad response to "if you were in a similar situation in future, what would you do differently?" is "nothing, everything i did at $oldjob was optimal". a response that shows some reflection, a willingness to admit not everything you do is perfect, and concrete ideas for improvements to behaviour or process comes across much better. no need to enumerate all your worst failings, cherry-pick and offer one or two lesser ones.
for these kinds of behavioural questions based on past experience, we didn't really care if junior / intermediate hires struggled to give strong responses. We would be a lot more concerned about poor responses to these questions for engineering managers or other positions with a leadership component.
having a prepared short form answer to "why are you applying for a job here" is also a good idea.
if you have friends or acquaintances who regularly interview folks who you can hit up for a favour, you could see if they'd be willing to conduct a mock interview and then give you feedback about things you could improve on.
reply