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!
> 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.
This is exactly why a lot of us DONT want to go back to the office - people holding their coworkers hostage because they don’t have a social life outside of work.
Exactly, I like to choose who I socialise with and have a vibrant social life outside work. I prefer to work from home and communicate over teams and get my work done than have to sit next to a random office bod who I may have nothing in common with, or worse has some kind of personality issue.
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 ...
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 ...).
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: gered@blarg.ca
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++.
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.
> 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.
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.
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.
Take home tests are bad. Fizzbuzz questions are bad. Multiple onsite interview rounds are bad. Behavioral questions are bad. Leetcode style questions are bad. Collaborative coding tests are bad.
If you ask the majority of job seekers here, the only correct way to hire is to hand out 300K/yr offers after a casual 30 minute chat.
The actual best way is to only have a small set of senior engineers who also are very good at talking about programming, and are good with people and interviewing specifically and have a history of trust and good judgment do all of the interviews where they have a lengthy conversation about past experience, technical topics, and maybe code a little together if they think they need to and just give them total authority to make the call. It might not be that scalable but it would work the best.
This has empirically resulted in bad hiring, at multiple companies I’ve worked at. The best predictor of senior performance on the job has been the take home test or coding challenge. We frequently have seniors who suggest that the technical discussion would be enough for senior roles. We always have to let them down a bit when we tell them that the discussion is less predictive than they’ve built it up to be in their mind.
I'm not sure. I think that's a problem to figure out. What I want to advocate for is mostly that talent scouting should be taken seriously not farmed out by scheduling random employees who aren't good at it and then collating the partial opinions of 10 people who don't really have enough time with the person to have a total view.
But engineers with good tech skills and good people are already likely to be the most valuable and time-constrained resources in the business. So taking 2 of them out to have a 2 hour interview with, say, 100 candidates is 400 hours. Even assuming they’d be willing to do that, that’s about 2 months worth of development from your best engineers.
This is why companies have processes like screening with a non-tech person and tech tests. It filters that 100 down to, say, 5 which is more feasible to put in front of those top engineers.
It hurts not to be selected for that 5, to be told you’re not good enough. Companies should do a better job at that. If they can’t give feedback because of the lawyers, they should warn you of that in advance, to set your expectations. They should be responsive and transparent through the whole process. What they can’t do - seemingly to the chagrin of many engineers here - is offer you a highly-paid job merely because you think you deserve it. I can see people on this post that likely have appalling people skills based on their comment, arguing that, since they didn’t get an offer, the company’s process was wrong. Perhaps those commenters need to look in a mirror to find the problem.
Recruiters might miss some top talent, but that’s the price they pay. All other solutions also have costs.
My wife is a lawyer. They don’t send her a take home test, or ask her about her side project cases, or whiteboard bar exam questions. Somehow it manages to work.
It manages to work because expensive law schools and the state Bar do all of those things on behalf of her law firm. Meanwhile you can call yourself a programmer after taking a 30 minute online tutorial and writing a hello world script – and that is a good thing. We do not need gatekeeping in this profession.
And those certifications mean absolutely nothing. There have been brain dumps for certifications for years.
Even if you don’t use brain dumps, it’s easy to memorize enough from studying something like ACloudGuru.
I got my first (of nine) AWS certifications (AWS Solution Architect) without ever logging into the console. But the only reason I get any of the certifications were to know what I don’t know and as a guided learning path.
For the first one, I was already a dev lead and wanted to know enough to know what I needed to experiment with when the company was trying to “move to the cloud”
My next 5, I was already the de facto “cloud architect” at a startup responsible for “application modernization”
And my last three (that I did within three months of each other), I was (and still am) working at AWS in the Professional Services department.
I can assure you that I don’t know but about 30%-40% of what those nine certifications cover well enough to hold an intelligent conversation with a customer and I only know the 30-40% from hands on experience.
And to be fair, I get it. Industry is too diverse to have one end all be all test. An AWS certificate won't mean much for my domain in games (unless you maybe work on online infrastructure for an ongoing service game).
But at the same time I wouldn't mind some fundamental license to optionally bypass many of these common tests.
Works fine as long as you went to a top-3 law school or graduated near the top of your class in a T14 school... I've explicitly seen lawyers lay that out as the criteria they hire by.
I'd rather deal with obnoxious interviews any day.
But the legal profession, in terms of fairness for new grads, is perhaps the worst of all professions, I'm told. Basically, if you go to a top school you make 3x the average graduate based on that alone. While there is a decent correlation between school and talent, it is by no means strong enough to justify the phenomenon. Certainly it is not like this in other developed countries.
Computer Science has unfortunately been headed in that direction but at least an A+ graduate at a state school has a chance at getting the better offers.
There's no perfect way, but fizzbuzz is perfectly acceptable to me (do you really want to work somewhere with employees who couldn't pass it?), and leetcode is too, as long as it doesn't rely on some trick that selects for memorizers over problem solvers.
I don't know why HN is so against algorithms problems. It is not something I have ever needed to "grind" because I understand ds&a well. While the more exotic ds&a you won't use on the job, and IMO shouldn't be tested for, IME the most complicated datastructures you generally need for both algorithms problems and on the job are hashmaps and hashsets.
>I don't know why HN is so against algorithms problems. It
Probably because they use the ones you mention. They think an ideal engineer should be able to cold solve some level 5 leetcode problem using a Trie with some trick edge case to perfection in 90 minutes as if they are some sort of mathlete. It's not very realistic to what you do day to day and required dedicated studying simply to pass the test, not to advance myself as an engineer.
If they used level 1 questions as a fizz buzz esque filter for string manipulation, iterator tactics, and maps/sets, then I'd have no issue. I'd get why you may test a student for a junior position harder but a senior dev should have actual professional experiences to dig into.
If you can't trust them to code then maybe you should in fact do the FAANG method and describe what exact concepts you want prospective hires to be able to talk about and work with. Haven't seen that outside of FAANG tho.
> "I don't know why HN is so against algorithms problems."
Half of developers are below the median and, to paraphrase Upton Sinclair, "It is difficult to get a man to support something, when his salary depends on his not supporting it."
I agree with the consensus about behavioral questions, the multiple in multiple onsite interviews, and most leetcode. Fizzbuzz is great and take-homes are widely varying in quality.
To give a different opinion, any company that doesn't do a take-home gets lower priority during my job search. My favorite interview was HR screen -> 30 minute chat with another programmer -> take-home -> final interview that included a take-home review.
I didn't end up getting the job but it was easily the best and least anxiety inducing interview I've ever been through.
Your timeline is best case scenario though. Your example timeline could happen and then they bring you onsite and ask you to do an in-person challenge as well. Now you’ve done all of that and still get ghosted.
Well, in that case, I assume you wouldn’t be interested at working for any on the top paying companies in the industry. None of them require “take home tests”.
You're right in that assumption but not because you putting words in my mouth. I said companies that don't do take-homes get lower priority during scheduling.
>As long as they don't take any more than 1-3 hours.
Well, that's the issue. It may be because I'm a bad programmer, but I can't think of a take home that took me less than 3 hours. The take home I did for my first job took some 20 hours over 4 days, and I exaggerated and said it took 12 (which didn't garner a response so I'm guessing that wasn't an unusual answer). I could do that while I'm a student, I can't do that again as a working professional without wasting an entire weekend after a week of full time work.
I still hate leetcode more, but at least there you have an explicit timer.
>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.
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.
Granted, my last 2 jobs did not employ take home tests, so I know I'm not forced to do them. But given my experiences I understand why others would be opposed to them. It sounds like you would be opposed to my experiences as well.
> 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.
I’d rather do neither. That’s the main reason I have never done in person or take home coding tests in the 20+ years I’ve been conducting interviews. So far we haven’t hired a dud.
I bet while you “weren’t doing in person coding tests” as a developer you also weren’t making the type of compensation that the people who were “grinding leetCode and working for a FAANG” (tm) r/cscareerquestions.
I use to brag like you, about “not doing take home test” for 25 years. Then I landed at BigTech and saw that returning interns were making about what I made two years earlier at 45.
I’m not complaining, my goal had been to get into $BigTech in 2020 and relocate when my youngest (step)son graduated I did so without a coding interview and without relocating by pivoting to “cloud consulting/application modernization” (cloud + enterprise application architecture/development). But I tell my younger relatives to practice coding interviews and go for the most compensation possible.
If you base your success on money, sure. Maybe tests are a good filter.
Personally, I'm seeking something more furfilling and the difference between 200k and 300k doesn't matter if I don't find the work furfilling. 300k to 400k would be negligible for any material possessions I'd want.
Sure it is, I had my 3200 square foot home built in 2016 in the northern burbs of Atlanta when I was making $135K.
But why given the choice (theoretically) would I give up making $ALotMore just by practicing for coding interviews?
Like I said, I personally didn’t have to thanks to years of industry experience, knowing “cloud”, and having soft skills. But why would anyone without the path dependencies I had (ie children in school that I didn’t want to relocate) hold their nose up at doing what it takes to make $160K+ straight out of college and a quarter million+ a year by the time they are 25?
>But why given the choice (theoretically) would I give up making $ALotMore just by practicing for coding interviews?
Because I am content in my current state of life? Because the type of work being offered is not engaging to me and I have the luxury to choose? Because I'm not trying to speedrun out of the job market and retire at 40?
I'm making more than $135k, but once I get a decent car and pay off my house... what next?
- Paid off student loans
- Already maxing out my 401k for retirement as well as investing in an IRA account
- I of course have hobbies and disposable goods to buy, but It's not $5000/month worth of stuff.
- I have a decent savings right now, and I imagine by the time I pay off my house I will have a very hefty buffer as well as some more of that going into stocks
The only consideration is potentially for kids, but that's not even in the cards right now. Maybe I'd consider traveling, but I've never had those dreams where I'm an adventurer, nor one where I retire in some vacation resort. I'll cross them bridge when I get there, and it's not like I don't have the savings buffer if I need a short term transition phase for $ALotMore down the line should the need arise.
As is it now, if I got a million dollars in 10 years after I paid off my house/car my first impulse would be... going to art school. Not investing in some more stocks or starting a busines or whatnot which tends to be popular here, I'd just continue to develop myself in skills I never had a chance to. And a million dollars would take that from being a part time side hobby to something I can focus on full time for a few years.
----
so yea, given all that talk, guess my career in tech lol.
Or take my path, find a job that balances work and life priorities, doesn't require you to stress out on grinding rote memorized leet code problems, and work on a side business in your less stressed free time so that you can start your own company.
FAANG companies already have far too much power and influence, I'm ideologically opposed to giving them even more by subordinating myself to them for the almighty dollar.
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.
I mean, it goes both ways. I feel that I am a fairly proficient engineer (built something with 10M+ downloads) but for a long period of my life I would do fine in every part of the interview except the part where you just chit chat a bit. I'd try to tell interviewers about myself and the smiles would just fall off their faces.
It took me a long time to understand that these sorts of conversations had their own "rules" to them, which I had to follow if I wanted to do well. These rules, of course, have virtually nothing to do with programming aptitude or ability, and seem to me, somewhat cynically, to be another way by which interviewers can allow their own biases to enter into the interview process. For instance, one time I got rejected because I seemed "too excited" about my personal side projects; it was deemed that I wouldn't be as excited about the work that I'd do at the company. Of course this is nonsense; I'm now happily employed and pretty excited about my work. I have plenty other examples of me saying reasonable things in interviews and being rejected for that reason.
There's really no silver bullet here. Getting rejected is always going to piss people off.
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.
Normally I'd agree, but I got passed up by a large number of fairly reasonable-seeming companies for arbitrary reasons like this. If it's just one or two, sure, maybe I'm better off. But after that it starts to have a real impact; it becomes harder to negotiate, maybe one of those companies would have been just fine anyways, etc...
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.
As a Clojure admirer who has learned it enough to get things done (and subsequently forgotten it) twice, I recently had the positive REPL experience that people talk about. Or at least I think I did. I was able to write a web scraping tool almost entirely in the REPL.
However, I find myself running Ruby/Rails (console) in debug mode in RubyMine (Jetbrains IDE). The REPL-like experience seems quite close to that of Clojure, with the added benefit of being able to easily enable and disable breakpoints and see my local data (and snapshots of all previous local data up the call stack).
And honestly, the Clojure thing that always stops me from actually getting a full anything built is the lack of frameworks and approaches which have critical mass. It's always the same answer, "We like to choose our own libraries." That's lovely once you know what you're doing, but the ramp-up time is just SO much slower than with other languages.
Considering the time to working proof of concept is critical quite often, few beginners have time to figure out all the libraries and tooling and integrations to build something in Clojure.
I think despite still wishing I had a Clojure backend with Clojurescript/React frontend, I'll step from my Rails PoC to a Phoenix/Elixir product and be successful and happy (and have a lot of people doing something similar, with similar tools and libraries).
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.)
Don't know about Ruby but agree that languages(think Java/C#/Javascript/C++) with really good debuggers don't have anything to envy from the Clojure REPL. But to be fair, companies have invested who knows how many millions to get that level of tooling while in Clojure and the nature of lisps you get it for free and low effort.
i'm starting to feel that REPL driven development can be bad for maintenance, when you have a REPL, you can write ridiculously compact and abstract code that is hard to understand just by reading it.
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.
It's almost by definition in some sense ... if it was obvious how to write the code you wouldn't need the REPL so by definition if it is uesful it must be producing non-obvious code.
That is a slightly shallow take though because its not really symmetrical like that. You can use a REPL as a way to arrive at the most easily understood rendition of something. But that is very prone to subjective bias as lots of things seem obvious in retrospect that are not at the start.
To the extent that the answer you eventually arrived at is a result of learning a mental model of the data and functions surround it, it will leave a significant residual gap for the next person who comes a long to bridge.
When using the REPL you can quickly experiment until it does what you want, but you need the discipline to distill something maintainable from it afterwards.
I agree. More generally, REPL-driven development rewards "guess-and-check" programming, and discourages "think-then-act" programming. This isn't a formula for success over time.
Just tried this out for fun on my 486DX2 PC ( https://i.imgur.com/NOeR1Ad.jpg ). It boots, but obviously the minimal kernel only has included support for a small set of hardware, which does not include serial mouse, S3 805 VGA (works, but graphical artifacts), and 3C509 ISA network card. Will have to try out the provided toolchain and scripts to try and see if I can rebuild with better hardware support for my 486. Why bother, you ask? Why not, I say!
This is a really important point. I work with someone who has quite a bit of an ego. Definitely cares far too much about his personal brand, which has been built up over the years through open source projects. Any time you work on a project with this person you basically need to use all of his open source libraries if any of them are at all relevant for the project, regardless of if they are the best option for the task or not ... sometimes they are, sometimes they aren't.
By far, the best developers I've ever worked with are quite humble.
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!