I think that is the thing. The vast majority of software engineers have only worked on closed-source codebases so reviewing their previous work is impossible. That said, what I have generally done is to just use interviews to talk about previous work. It is usually pretty clear in the course of a 30 minute interview who has actually done the amazing things they claim on their resume and understands how to build software systems and who doesn't.

That's also something I keep hearing in anecdotes.

The main reason I publish them publicly is ... I don't know why actually. However, one benefit to public github repositories is I can try out various services that are free for open source projects. This way I have exposure to these services which is nice. Also it is easier to get help from others or ask questions when I get stuck.

In my experience, I've found programmers very helpful as long as I am willing to put in some effort.

Unique talent was what I was specifically looking for. Since my company paid "competitive" (i.e. "low") wages, I had to look for "diamonds in the rough." We did interview some highly qualified people, but they tended to defer, when offered.

I feel that I was quite successful, and kept highly talented engineers for many years, but it made the search challenging.

"Cookie cutter testing" wasn't even an option. I'd have been crazy to ignore every advantage each unique applicant had to offer.

I suspect some scammer was running a game on you. They tend to go "over the top," as "dumbass filters." If someone responds credulously to an outrageous claim, then they are a "good mark." The fact they ghosted you, tells me it was a scam. I have encountered many, many scammers, since leaving my last job. It's a pretty tough field, these days.

One of the reasons that I stopped looking for work, was because a lot of hiring managers and recruiters believe that it's important to insult applicants, right out of the starting gate. I think that HR policy, in general, these days, is to always keep the applicant in a supplicant position, so you are in control of the relationship. I think that LeetCode tests are part of that game. Sort of like "hazing."

What would be the purpose of this “scam”?

It may be as basic as getting you to open an infected document, of some kind. We tend to exchange a lot of stuff, when we do employment negotiations. I'd think an engineering manager, at a sensitive level, would be a juicy target. I've had any number of LinkedIn attempts to get at me, through offers of employment, basic networking, and attempts to get me to employ (I have a title as a CEO of a couple of 1-person companies, so I get a lot of these types of attempts).

My favorite ones, are the "attractive young women" that want to "link up" with me. I'll bet a lot of folks fall for that.

So you can know if it's really their portfolio.

Just asking some basic questions about the code in the portfolio will make it clear pretty quickly if it's their work or not.

Instead of wasting time with somebody floundering tests and offering excuses, or even have a cringe situation. That is why i also like the portfolio candidate.

Also, there's nothing stopping someone from copy/pasting entire projects into their portfolio.

I would totally ignore someone's portfolio when interviewing them.

Too bad. you look like an interesting chap to know.

Accountants don't have "portfolios", interviewers don't ask to see their spreadsheets. Managers don't have saved video recordings of 1:1 employee meetings for interviewers to look over. Engineers don't have a sample set of bridges they've built [0].

Artists (and by extension, designers) are the only other profession where you're expected to have a portfolio of your work for a prospective interviewer to look at.

I guess what I'm trying to say with "I'd ignore the portfolio" is that if we're going to emulate another profession, let's copy the engineers, not the artists. Artists are typically underpaid and undervalued. Engineers are highly respected professionals.

[0] well, they might have photographs of the actual bridges, but not a sample selection of actual bridges. For some reason I can't point an interviewer at a previous employer's app and say "I built that" like an engineer can.

Engineers are mostly standardized, and the salary range reflects that. There are some very well compensated engineers, but the bulk do okay, doing normal work.

And critically, a board certified engineer stamp is an engineering stamp. Regardless of who it comes from.

On the other hand, artist compensation is directly correlated to ability to market yourself, current trends, and overall skill.

You have artists who are struggling to make it a job (in our world: entry level web design, analysts), artists who are doing okay with careers (enterprise software dev), entrepreneurual artists (startups), and superstars.

And critically... their degrees tell you almost nothing about which category they're going to be in.

But most aren't. Most devs clock in, write some code, clock out, go home, do something completely different. It's a job. They operate inside the salary bands of their organisation, and they do okay, doing normal work.

And specifically, when there are no signals that can be normalized across candidates for comparison.

I feel like that's pretty descriptive of most general software development.

So artists and designers aren't? There might be a few folks around these parts that might take issue with that. I was once an artist, and that training has been of significant value, in my engineering.

I list Adobe Illustrator as one of the 4 applications that I use every day (along with Xcode, BBEdit, and SourceTree). It's what I use to generate graphic assets for my development work.

Anyway, we could dance this jig all day, and I don't think it would solve any pressing world issues. Not a big deal. We don't need to prove anything to each other.

Yes, agreed. It's not worth getting too bothered by it ;)

Fortunately I've yet to run into this once I spent enough time as a mid-level developer and became senior. If it's any ray of hope for younger developers out there, you will get to a point where you basically bypass all that crap and interviews can be more like a friendly chat between peers.

In a couple of instances, it was a sensible, applicable “take-home” test, but usually, it was a schoolboy binary tree test.

I interview very well (on account of over 30 years of relevant ship experience, and I’m actually a fairly decent chap), but it has never gotten to that point.

BTW: if it isn’t already obvious, I’m quite senior, and have been architecting, as well as writing, software, since my very first project, in 1987.

I was quite willing to work for a lot less than many folks much less qualified, on account of having my retirement set, and was looking for interesting and engaging work, more than money; but it never got that far.

I won’t waste time practicing LeetCode. I don’t think it would make any difference, simply putting off the inevitable rejection. It’s not something that helps me to write better shipping code.

If I could just build them a feedback system for their employees. Including backend, frontend (as a SPA please), and tests.

Of, of course they didn’t expect me to actually finish, 5 API’s and 3 implemented front-end pages would be ok (and tests, of course). Also, could I maybe make it look nice?

I dunno, for some reason I saw it as a challenge and actually tried. But after 3 hours I was forced to concede that even using a full framework and CRUD generation for most of the app the idea that you could finish was ludicrous.

I spent an extra 30m writing up a review of the process and attached that as a ‘cover letter’.

Unsurprisingly I didn’t get the job, but I guess I consider it a bullet dodged now.

Just setting up technologies that I have never used on my local machine and trying to understand them has taken me several hours.

It seems unlikely I will submit anything.

Unfortunately they are developers. They underestimate how long it will take. They didn't actually try it themselves. They might even have modeled it after a piece of software they did build in-house and thus underestimate even more.

I had to advocate very strongly on cutting scope from our take home test and multiple times argue against 'extensions' of the ask.

I like take home. It's a great way to talk about their code. Have them explain choices. Pros and cons. And yes tests please. What I look for is not complete test coverage or having 27 classes that all have pseudo tests. Have one class with _good_ tests. Show that you understand what is important to test and how to do that. If you know how to do that, I can hire you to repeat it for a salary.

My own last take home I sent in didn't even run because the implementation assumed various external services that I didn't bother implementing or mocking out enough to make it all run. I put lots of comments explaining various choices and what I'd expect those external services to do though. Was a great topic started about code comments and which ones I would leave in actual code and such.

So you’ll be competing with people that implement the whole thing regardless.

Now I’d like to think that interviewers are entirely impervious to that, but realistically, it’ll hurt the chances of those that do it only halfway.

If you don't try you've already lost.

My experience doesn't matter. The fact that I've now worked at (and currently work at) 3 of the big tech firms, doesn't matter (to be fair, I only got jobs at these places back when I was willing to grind out leetcode and memorize as many problems as I could - a task which I refuse to do today). The fact that I have a history of leading teams, areas, and spend at least 50% of my time also "writing code" for high performance, high reliability, global services, --and-- can speak in depth regarding my accomplishments, design decisions, technical decisions, collaboration, etc. doesn't matter.

The only thing that matters is: Can I pretend like I've never seen this toy leetcode problem before during an interview, and magically come up with a perfect solution in 30 minutes or less. (and if I haven't happened to memorize it, and dare legitimately appear to struggle, well... game over).

Everyone knows that something very serious must be done at an interview. Nobody cares about it enough to actually put in the time or trust for a bespoke solution.

Consequently, you end up with everyone sub'ing algorithms in for due diligence, then because they made that choice, defending the choice and pretending like it's meaningful.

Hiring is hard. Hiring technical, non-standardized talent is even harder.

Did you think to work with blockchain? It has a lot of engaging problems, and you can start even without getting hired. It ranges from helping out DAOs in open-source and getting paid in tokens; to starting off your own small project and building a community.

As for the jobs, the compensations has been through the roof lately – the field doesn't get new developers nearly at the rate needed

I enjoy working on stuff that people use. Things that the user interacts with directly; like UIs and devices.

I did a bunch of work with Bluetooth, OBD, and ONVIF (surveillance), but I'm working on what is sort of a "social media" app, now. I wrote the backend for one of the servers we use, and was the original author of another of the servers. These were big projects.

The interesting part, however, is the iOS app that I'm developing. Trying out different ways of presenting to the user, and interacting with the user, is a lot of fun.

Do you know of any good articles or guides about getting started with this for complete beginners to blockchain?

Today, we have “jargonauts.” These are folks that key on certain terms and acronyms.

I remember, back in the 1990s, hearing everyone gushing about “AJAX,” and wondering what the big deal was (after being laughed at, for not knowing the term). No one would explain what it was.

I looked it up, and go “Oh, they mean HTTPRequestObject!”

Turned out, that I actually already knew a lot more about “AJAX,” than most of the folks gushing about it, and the reason no one would explain it, was that they didn’t actually understand it.

Lot of that, going around…

Except then it turns out what they mean isn't DI, but some other concept related to it and largely taken care of by their framework of choice.

Personally I find DI to make it harder to reason about in a sizeable portion of cases (20ish%) without actually providing a benefit.

So that makes me prefer going for rejection (Passing the result of the dependency instead of the dependency itself) or just keeping it there.

Altough, those approaches depend heavily on the rest of the codebase. (FP makes rejection relatively easy for example)

Without classes what would you be injecting? Other functions? That’s still something that happens all the time in FP.

That’s secretly the most powerful design strategy.

Altough, for usability it is IMO definitely the best.

Nowadays it's called a dict.

Not worth fighting over. Time is flying, and even the early 2000s was a couple of decades ago.

I'm pretty sure that HTTPRequest debuted in IE 5 or 6.

It's more akin to saying "We want to do this thing that's never been done on the web before, and no one ever thought to do. How do we assemble it out of this box of scraps that HTML and browsers currently give us?"

Consequently, there was probably proto-AJAX with ActiveX, the early js landscape, and iframes. But it would have certainly depended on where you worked.

Critically, internet connections were much slower (in latency and bandwidth), so partial page loads were more of an advantage.

I asked someone that was on that trip with me, and it was late 2007.

You know how it is, with us doddering old geezers; we forget stuff...

While I'd prefer to work, not needing the money implies the ability to avoid the interview process. It's a funny thing being in an industry where people retire not because they can't do the work at a professional level, but because getting a job is such a PITA.

I feel that this is a desired result. I am pretty convinced that folks like to have an "ideal culture" at their workplaces. I hear the term "cultural fit" so often, that I guess it means something that I'm missing.

https://www.youtube.com/watch?v=G2y8Sx4B2Sk

The whole situation is quite pathetic.

Sorry it's a boring answer :-)

I ran a UI team for 3 years, we built a UI framework, then the UI and apps on top of it.

We lived trees and tree traversals. Understanding trees was essential to everything we did.

Do I ask people to balance trees? No, but I do care if people can understand traversals, and also how to manipulate and design tree structures to solve business problems. Being able to design the right data structure to solve a problem is an important skill, and trees are one of our fields fundamental data structures.

I have written quite a few frameworks, SDKs and APIs; both server-based and host-based, and never had to deal with this stuff. If I had, I would have done what I always do, when I get to that point: Learn what I need to learn.

I have been learning new stuff, my entire career. I don't know how to do almost every project I take on. I even wrote about it, here: https://littlegreenviper.com/miscellany/thats-not-what-ships...

A lot of people try to start at root, enumerate the level of nodes for the entire tree, and then return non-sibling nodes at the same level as the node we want to find the first cousin of.

Which works, but it is O(n) and a lot of work. People who know about parent pointers in trees just walk up a couple levels and then down a couple of levels.

I consider it a fair question because, it has no gotchas, it is just understanding how to efficiently walk around one of the most commonly encountered data structures.

My other go to question is provided a library function that can schedule a callback to run anytime in the next 2147483ms, write a wrapper that can schedule a callback at any arbitrary time in the future. For advanced candidates I provide a library of date/time functions and they have to take in a date/time and using the provided limited functionality scheduling callback, call the passed in function at the proper date/time.

This is a very simple problem, and one that I've encountered in real life[0].

It is a trivial, but again real life problem of building functionality on top of a limited platform API. I have seen this question trip up countless candidates, who try to seriously over model the solution. I have no idea why a class with 1 function and a couple int64 variables counting down time seems so hard!

(Old school C programmers tend to get it right away)

[0] Windows timer APIs like their 100 nanosecond parameters, though now days they all have modern 64 bit FILETIME variants that side step this entire issue.

The thing is, companies don't want to employ any random person who can code and meets the minimum bar, they want The Best™ - and that's when things get competitive, and arbitrary.

This is the other side of the coin to a recent HN thread (on pay transparency/whether tech workers are interchangeable[1]). My thesis is if you agree that some are many times more productive, the so-called 10x - and you want to hire those: then you need to test for that in the interview process, hence the exploration of the less-visited areas of Data Structures & Algorithms. If any engineer who meets the minimum requirements will do (i.e. fully interchangeable), then anyone who can pass FizzBuzz and is familiar with the tech will do. Most companies are in the latter group, but tell themselves they are in the former, resulting in the current explosion of "Change this unsorted linked list into a balanced tree with the least time complexity" questions.

> If a candidate has a portfolio, you'd be absolute idiots to ignore that portfolio.

I'm guessing only a minority of candidates have a portfolio before applying for a job. Most of SDE output belongs to their past employers, so expecting portfolios will also filter out a whole lot of people who can do the work, and I'd rather grind HackerRank than hastily build a portfolio just to apply for a job.

1. https://news.ycombinator.com/item?id=28536084

I can usually do … OK … on these tests, but I’m probably mediocre, at best, as it’s often the first time I’ve encountered the test.

I tend to write naive code at first, and make sure the result is solid, then optimize. I will sometimes also experiment; trying out all kinds of harebrained stuff, before settling on even that “first try” code.

That workflow has worked extremely well for me, in my vocation, but does not present especially well, in quick whiteboard tests.

My workflow results in very high-quality, performant code, but iteratively. Also, not all code needs to be optimized. Sometimes, leaving the naive code, means it is more maintainable. I also habitually document my code as I go, which has proven unpopular, with testers.

People just out of school, or who spend hours each day, practicing LeetCode, will usually come up with an optimal solution, done the way the tester expects, first go.

I don't know if I've ever done that. The Apple OS framework has a lot of those tools, built-in, and it wouldn't make sense to circumvent them, unless I was writing a cross-platform "engine," of some kind.

If you were interviewing as a device control engineer, then a minimum, would be understanding of things like ring buffers, thread contention, asynchronous callbacks, timing diagrams, etc.

If you were interviewing for work with Apple device development, then knowledge of Core Bluetooth, as well as basic Bluetooth, would be important. WiFi and networking might be useful. Maybe BSD sockets, USB, etc.

If it were as a UIKit app engineer (classic native), then understanding of the various widget types, delegates, data sources, etc., as well as the six gadjillion different "extra spice" features that each widget has, as well as the proper way to do things.

SwiftUI is gonna add a lot more facets, as it's built around Protocol-Oriented Programming, and a rather "reactive"/KVO model that differs substantially from the "classic" model. I have yet to do a "deep dive" into SwiftUI. I plan to tackle that, once I have the app I'm working with at a ship level.

And, of course, an intermediate-to-advanced familiarity with Swift would be expected, as well as the Foundation framework.

Not right out of college and don't balance binary trees every day? Submit a portfolio to review.

Don't have time or permission to write open source code outside of your paid employment? Well, let's see if you can balance a binary tree.

Both of those are bad? Well how about a take home exam you will need to set aside time from your schedule to complete.

Seems like the perfect interviewing process would have multiple avenues for a developer to demonstrate they can actually program. Of course, that requires the company taking the time to set up a process that can evaluate candidates across all these evaluation methods and somehow compare them fairly.

Benefits:

- Employer: by scanning for resumes with this license, the employer saves time and money that would instead be spent on technical LeetCode-esque interviews.

- Employee: a singular license would make you more attractive and compel a higher salary. You wouldn't have to grind LeetCode for 3 months before a job hunt.

In my "utopia", FAANG/S&P 500 companies + universities (MIT/Harvard/Stanford/etc.) would band together to form a third-party committee and standards board that would design and proffer this exam. Having those big names in charge would give it instant credibility and make it the de facto S.W.E. P.E.

FAANG companies are willing to put their money where their mouths are. They pay quite well. I think it would be quite reasonable for them to require a standardized certification, and people would bust their butts to pass the cert., for a chance at the money to be made.

A lot of startups, on the other hand, have much "earthier" needs. They may want people that are more "generalist," for a lot of their roles, and might be able to use support for eventual training to the tests as a carrot. If they treat their employees well, they could get some certified engineers for a bargain price, out of the deal.

Also, there is such a huge variety of coding specialties. Algorithm coders work with data processing, but you also have people that may specialize in ML, and that could require entirely different skillsets (I am not an ML person, so I don't know whether or not standard DP algorithms are ideal for AI work). I have done a lot of communication and device control stuff, and that has some facets that few of your "standard" developers see.

Then, you have toolsets and frameworks. These are really what makes a developer rock. Someone who really knows their way around specific toolsets, or deep language knowledge, may be what you need. I can learn a new language, in a couple of weeks, but knowing it well can take years. And there's a better than even chance that knowing it well won't be particularly valuable to a company.

Lot of variables. Software is a very, very dynamic place, and it's really difficult to distill meaningful standards from it, that aren't rendered obsolete, almost as soon as the ink dries on the documents.

Also, ABET already accredits Software Engineering and IT programs; and NCEES has had a Software Engineering PE in the works for the last couple years (I haven't checked recently, but iirc it was slated for release in 2022(?)).

Toy problems seem to exist in pretty much any technical discipline, but it seems most acute in the software world; and I've come to suspect that it's accessibility to making those. Code is quick and human-centric technical item, where as something like a bridge rectifier, amps, fets, and PID controllers aren't necessarily items you can just 'pull out' in an interview; you can see if someone's comfortable with CAD programs, you can see if someone has the chops to understand when a BJT is more appropriate than a MOSFET; but you can't really do that quickly as a 'whiteboarding session' so other technical fields are required to be more selective since you can't just slap out a FET configuration for a D Class amp without spec sheets, requirement gathering, probably CAD design, and other design steps; but you can sure-as-shit slap out a MVP of a SPA customer portal without any of that.

Divorcing "coding" as the act of writing code, and "coding" as the mental process of building a well designed app/system would bring the software world into better alignment with a lot of the rest of the engineering world; and would make something like a SWE PE more viable in the first place. I also don't know if you've ever sat a PE, but they're also __OPEN_BOOK__, since we know that it's a lot of knowledge to have in your head, and it's a better test if you know where to look something up and how to use the right tools (kinda like a 'take-home' exam in software interviews, but not nearly as exploitable and scummy); bring your reference material, but so much ground is covered that if you don't know your stuff, you're failing the PE no matter how many reference books you bring along.

I literally had to ask a guy why a group of 5 of them all had the same fucking letter for letter resume...

Ask.idiotic.questions.to.weed.out.the.base.morons.

However, I still think you're pretty badly missing the point:

(1) Algorithm coding challenges test whether a candidate has the ability to go to the internet, research and get good at a technical skill. That is absolutely an appropriate thing to be testing.

(2) Algorithms are a beautiful cornerstone of our profession. Perfectly reasonable, and kind of nice, to use them in our hiring processes as described in (1).

In my experience, there was never any "go to the internet, research and get good at a technical skill." during the interview. That would have been nice. It was "Sink or swim, right now, while we laugh at you," So I guess that you mean I should dedicate an hour or two per day to LeetCode, like a lot of folks do.

Why the living heck should I "go to the internet, research and get good at a technical skill" that has no applicability to the work I do, every single day? I learn what I need, when I need it. You don't want what I have? Fine. You won't get it. I worked long and hard to be in the position I'm in now. I don't need to "play the game," as I have real work to do. I don't really care whether or not I make money at it, or impress anyone. I don't need anyone's approval or validation for the work I do. The people that matter, are quite aware of my capabilities. They see what I do, and use my work, every day. I have done two TestFlight releases already, this morning.

I don't know how to do just about every project I take on[0]. That's S.O.P. for engineering. I've been working that way for more than thirty years. I've learned a lot. Sorry if it isn't what some people think is important, but I have been delivering and shipping software, since 1987. I've worked for some pretty intense organizations, and they seemed to be happy with my work. I've written stuff that is in use -every day- by thousands of people, in multiple languages. There's a small chance that I might actually have a clue.

I write code -lots of code- Every. Single. Day. Don't believe me? Look at my GH ID[1]. That's not "gamed." If anything, my tagline should be "Don't believe me? Look for yourself." I can back up every word I say. If I'm wrong, I freely and promptly admit it.

For example, today's task is learning the proper way to set up an edit session for a particular type of user interface. I haven't done it before, and I'll be "go[ing] to the internet, research and get good at a technical skill," in order to get the job done. It will probably take me a day or two to get good at it, and apply it. I do this multiple times per week.

[0] https://littlegreenviper.com/miscellany/thats-not-what-ships...

[1] https://github.com/ChrisMarshallNY#github-stuff

Since I already have a very substantial "nest egg," it was time to just start living off that, and doing work that I want to do.

I immediately sought out some folks that wanted to do a free app (it actually has monetization potential, but we aren't really paying attention to that, right now) that would help recovering drug addicts network and support each other. They were not having much luck, getting people to take their effort seriously.

I already had a full-fledged generic application server that I had written, just for practice[0], so I said that I'd build them a frontend, based on that server, and I'd do it for free, because I like to code, I figured that I'd learn something (I haven't done a social media app, yet), and it would give me a chance to develop some theories about hyper-flexible software methodologies that I'd had kicking around. I knew they didn't actually have a clear vision for their product, and I knew that I could develop it in a way that would help them to refine it. I just got off a video call with the CEO and a backend guy, where we mapped out a "bare spot" that needs paving. I guarantee that many startups would absolutely drool over the process we are using to develop this app.

It's been great. I haven't been this happy in my entire career.

[0] https://riftvalleysoftware.com/work/open-source-projects/#ba...