At Google, you almost never know which team you will land in before you interview. At Apple, you probably know who your future manager will be before you interview.
(Source: I have worked at both companies.)
Much of the industry was either specialists in their studies, or specialists in that they knew a specific software package. It was interesting to interview people who had very in-depth knowledge of one thing, but completely oblivious to even the basics of other areas.
Here's my defense for the critical thinking questions since I know it's a contentious topic here; I'm evaluating how they asses and troubleshoot something. Often, actual technical problems get caught up in the minutia or domain specific parts. So abstracting it and even removing all of the tech keeps people from getting hung up on that. I hate "trick" questions, but sometimes would ask one to see if they were thinking towards optimization or non-traditional. It's actually deflating if they already know the answer. I never cared if they got a result, I'd often move on if it took too long.
I felt the most criticism towards the technical questions. Many of them were more technical than really ever came up on the job. I think it's good to find the limits of a candidate's knowledge, but not ding them for it. An example would be doing stuff with pointers when the job is 100% in a scripting language. Sure, ask them if they know the basics of pointers, sure maybe once in 5 years they'll troubleshoot a bug that might need obscure knowledge, but I would hope that would get triaged and passed around instead of expecting everyone to deal with the 1% case.
So how about giving reasonable arguments why OP probably had rounds that went poorly and is salty about it and why Apple has a wonderful software developer culture that focuses on quality instead of assumptions? Apple has problems with documentation since years, one example I had to deal with recently: their maps API. The MapKit programming guide is still in Objective-C, old design and outdated.
FWIW, I don't see how "I tried to add documentation in my interview and my interviewer didn't like it" translates to "everyone at Apple hates documentation".
> The MapKit programming guide is still in Objective-C, old design and outdated.
Objective-C guides are not inherently old and outdated.
You're absolutely right and this could have been an argument made by trangon, instead of an assumption about bad intentions by the OP. The interview story is just an anecdote in the end.
> Objective-C guides are not inherently old and outdated.
I agree in parts, they're not outdated in terms of facts present (although I wonder if MapKit didn't have any changes since October 2016). What I meant is outdated in a sense that Apple is pushing Swift but doesn't provide a programming guide in that language for this particular topic. Still supports my point of Apple having problems with documenting their APIs. SwiftUI is another example.
there is a common answer of “study leetcode”. No other advice, just the belief and assertion that all you need to get one of those jobs is to score higher than the other people.
This idea unfortunately perpetuates itself as one person advises another and a person.
The number of leetcode questions solved is used in the inevitable male appendage sizing contests.
If you spend time doing extraneous things like documentation during a coding challenge you likely won't do well, not because documentation isn't valued but rather because you won't have time to move from the "simplest" answer to the "best" answer, let alone the "teach me something" answer. This may frustrate your interviewers because they're seeing you spend your time in a way that's not advantageous to you. They may even be more frustrated if they actually liked you as a candidate.
Tests are different because they often help you move more quickly and confidently between layers of the question as you can sanity check you revised implementation against your tests.
1) You can't always be 100% sure the code was actually written by the candidate.
2) One quality I'm looking for in particular is somebody who can work well with OTHER PEOPLE'S CODE, and that's even harder to evaluate. If I see a balance of original repos and forks, that might be some evidence, but again, how do I dig out what they contributed? Chasing down PRs would be more helpful, but that definitely is too much work for a job interview.
3) Having a busy github account could be a marker of particular life circumstances (to avoid waving the red flag of "privilege" around too much) — the candidate is not overly busy working a second job, raising young children, or giving 120% in his day job.
4) There are plenty of respectable reasons not to code in your spare time — you may have different hobbies etc. When hiring pathologists, we don't give preference to candidates who cut up bodies in their spare time. We should get out of the habit of doing so for programmers.
5) A busy github account can also be a warning sign of somebody who might be more invested in side projects (or possibly even bootstrapping a startup) than in their day job.
I come from a CS background and struggle with these too.
The big problem I have is this performance stuff is often barely relevant to the position. You need to know the principle of a BST. Unless you're building a database working in a unique scenario, actually traversing it going to be done by some library.
Writing documentation headers in an interview setting should only happen if they explicitly state that you should write them, or after you ask the interviewer if you should be writing them.
From what I've seen, interviewing is evolving and focusing gradually more on realistic, practically-oriented coding, and less on Leetcode-style questions, especially as people are learning to game those.
That it also rejects some good candidates is fine, there's always more candidates for FAANG jobs. (Few competitors pay FAANG salaries.)
I feel like there should be a course for passing these exams run by ex-FAANG employees. Perhaps a bootcamp.
2. Some of these firms occasionally host coaching sessions for referrals. Ask your friends if one is currently running.
3. "You don't need H1Bs, just lower your hiring bar" is a criticism that is a bit less applicable to firms with a high hiring bar, than to firms with a low hiring bar. If you are, in fact, talent-limited, an H1B will actually cost you more than a local worker. (Lawyers, immigration sponsorship, uncertainty in whether the visa will actually arrive, aren't cheap - and FAANG does not have a reputation for exploiting their H1B hires.)
I'd like to practice this, any recommendations?
If you don't want to pay, just get the list of former questions from the internet. [1]
Many of those questions may no longer be asked, but if you can ace them, you should have few problems with similar questions/variants thereof.
This is not a skillset that develops from doing your day job. You have to deliberately practice to get good at this.
[1] https://www.interviewcake.com/google-interview-questions
Here's what I like about interviews:
(1) I get to talk about myself and how great I am without people rolling their eyes at me.
(2) I get to solve a fun puzzle with:
(2)(a) A defined answer.
(2)(b) That I never have to maintain.
(2)(c) With a potential financial windfall at the end.
If you happen to do coding exercises at all, they are just basic tasks like implement a linked list data structure, count the number of words on a file and such.
Answer some trivia about the language you are supposed to use, e.g. when should you use a struct in C#.
Luckly only startups over here are somehow into SV hiring culture, which still leaves plenty of others with job offers available.
Looks like you got stung by the confusion between binary tree and B-Tree (and B+Trees).
1. The b in btree isn't binary.
2. Databases use B+Trees.
3. binary trees are almost worthless.
Interval trees reduce to Binary Search Trees when the nodes can't overlap. Most markup DOMs (in browsers, WYSIWYG editors, etc.) are held as an Interval-tree ADT which is actually implemented by a BST.
Also, Red-Black trees specifically are used in many database clients to implement an in-memory write-back cache of a database table, as the combination of performance requirements for flushing batches of writes to the DB, and reading back arbitrary keys that were written to the cache, make these BSTs nearly optimal for this use-case.
But yes, DBMSes themselves don't tend to use BSTs for much. Maybe as a query-plan-AST term-rewriting-phase ADT.
Interval trees are degenerate R-Trees which can be implemented using GiST which is itself a btree.
>Also, Red-Black trees specifically are used in many database clients to implement an in-memory write-back cache of a database table, as the combination of performance requirements for flushing batches of writes to the DB, and reading back arbitrary keys that were written to the cache, make these BSTs nearly optimal for this use-case.
Got a source? I'd like to read up on this use case.
>But yes, DBMSes themselves don't tend to use BSTs for much. Maybe as a query-plan-AST term-rewriting-phase ADT.
Postgres' source does indeed have a red black tree in it:
I was a manager for a long time. I loved long résumés and relevant material.
I was hiring expensive people to work on really important stuff, and there was no way that I wanted to rush the vetting.
Also, I never gave a single test, and I think I got it right, every time.
I rarely have time to look at code repos unless asked by the manager/recruiter.
You are also likely interviewing with the wrong people. Most large companies are looking for as many of the best devs they can find for generic opportunities. They have many many slots to fill.
If you are looking for something very specific then you need to find a recruiter who does placement as well. Amazon (where I work) has two major hiring processes, direct to team where they are usually looking for a specialty or generalist and take the first qualified candidate, and generalized hiring where you have to pass a standard interview but then you begin interviewing managers and finding a fit. The second may be better for you, but you still have to pass a bog standard interview.
There is of course the third way which is have a friend on the inside do the pre fit and selling.
(Maybe spend a few minutes on the phone just to verify they are really the person who wrote all that code.)
The on site interviews are checking for things like communications, soft skill, design, etc. Things that don't fully come across in a code repo and are hard to verify who did what.
We have tons of people who try and misrepresent themselves. It would be a waste of time for the 6 people on a loop to all read the repo. It would also be bad if we didn't cover the things we cover in the on-sites.
We are also required to keep loops the same for all candidates. So giving an offer to one candidates because they have a GitHub repo and a phone call and the rest don't and therefore have to come in is a no-no. Therefore they all come in.
I've also generally had very good experiences interviewing with them - tough but entirely reasonable questions focused directly on my expertise and the tech the team is using. One that stands out in contrast to OP's complaint was an interviewer that brought in a stack of printouts of screenshots of apps I'd worked on and used them to spark a discussion of the work I'd done on them.
OP's experience, while annoying, and not surprising, is also not universal at Apple.
Another point in case against overreliance on metrics. Optimizing your process for making it easier to measure can easily turn into looking for your keys under a lamp post on a street even though you've lost them in a park.
There's bound to be some confirmation bias there
I confirm that everyone that worked on my team worked out well. Some had more challenges than others, but we got the job done. The team worked well together, and we worked with our overseas compatriots in exemplary fashion.
I was very fortunate. It was a small, high-functioning, C++ team of experienced engineers. All family people, with decades of programming experience.
I'm quite aware that this was a luxury. I'm grateful for that.
I might be reading into this wrong, but it almost sounds like you're saying that you only hired people who had families. Doesn't that sound a little bit discriminatory?
I would have been fired if I had shown any bias at all. I had my differences with some folks there, and I wasn't always thrilled with the way that things were run, but it was the most diverse environment I've ever seen; and I include a lot of Silicon Valley companies in that statement.
The simple fact of the matter was, that the jobs in my team required a fairly advanced knowledge of C++, and the lions' share of applicants were men in their 30s; usually married.
Marital status, gender, race, religious or sexual orientation/gender identification mean absolutely nothing to me; unless the applicant insists that it should. In that case, I generally find that they might not work so well in the team.
Lack of drama was important to me. We had a full plate.
An almost guaranteed way to lose people with families, is to insist that they must ignore their family to work the job.
This means that things like offsites and travel need to take into account things like school schedules, childcare and time off. I would often let people travel on Sunday to Japan, taking the heat for them not being there for a Monday meeting (which usually was just a "set the agenda" meeting anyway). That was my job.
It doesn't mean that someone going through a divorce, or caring for a sick family member, can take a ton of time off when a project is melting down, but it does mean that I would work with them, to ensure that their families get cared for, and that they can leave the job where it belongs, so that they are 100% for their families.
If you do things like this, you end up with a team that will take a bullet for you, and will do things like travel to Japan for two weeks to work on an emergency integration.
It's absolutely shocking how many managers don't get that.
I would argue that "how fast can someone implement this algorithm?" is a considerably less useful question to answer than "does this person document their code?" in an interview. If time is the constraint then schedule a longer interview.
There is likely no causal effect between whiteboard/algorithm interviews and poor documentation.
As a method of finding good candidates it feels like it must suck but so few companies are willing to actually measure their hiring effectiveness (and be open about it).
As someone who has given hundreds (maybe thousands) and received dozens of these types of interviews, it's really not.
Generally speaking I'm looking for at least 2-3 of these abilities, depending on which question I'm asking:
1) Can you reason about data structures and algorithms when looking at a problem you haven't seen before? 2) Can you communicate your ideas effectively? 3) Can you integrate new information from a colleague while problem solving? 4) Can you write code that makes sense? Do you understand basic programming concepts? 5) Can you read your own code and reason about it?
There is at least two hidden attributes that I'm not testing for but do affect performance, so I try to account for them:
1) Are you comfortable with me, a relative stranger? 2) Can you do these things while dealing with a high pressure situation?
You will encounter high pressure situations at work but often interviews feel more high pressure (to some people) than most daily conversations about engineering.
That's it. If I can tell a candidate already knows "the right answer" to the problem, I'm usually disappointed because I'm more interested in watching them think.
It tells me they meet the baseline - they can learn well enough to at least be able to do this particular problem super quickly.
But it doesn't tell me any more than that, unlike the candidate who thinks for a pick, considers a few different approaches, writes something up, stops a few times to think about edge cases, satisfies themselves that they're covered, etc.
"Can you figure stuff out on the fly" is the test, not "do you have this memorized?" Fortunately, most people don't have everything memorized, so for now it's still a useful-enough filter.
The problem with alternative, past-experience-based types of questions is that most candidates are terrible at driving them. I would love someone to tell me an hour-long story of debugging something in a library, say - but usually, even with a lot of prompting, it's very hard to get much interesting stuff out of them.
So by putting some algorithmic questions on the panel too, at least they have a chance to show that they can code, even if they can't communicate much meaningful from their past experience.
I would also have serious reservations about taking a job where documentation is considered a negative during a coding interview.
Part of this is understanding what they're asking for and adapting. If someone wants to know how to document code properly then you can have a conversation about that and give an example. But if they're asking about algorithms then you write the code and explain how it works verbally. You don't need to write comments because the reader is right there and you can explain it to them. It's not production code.
Assuming everything the GP said is true, what you're saying is completely contradicted by the fact that they were dinged for not using a null coalescing operator.
You could thank them for pointing it out, say you're not sure you want to use it (if you don't think it's better) and then get the conversation back on track. And, hopefully they'll think you handled it smoothly and won't take off points, but you'll never know how important it is to them that you're fluent in Swift. Maybe not at all, it's just an aside?
Which is to say, usually you can't tell in an interview what they're really grading you on. It's nerve-racking, but you just have to try to seem reasonable and hope that works.
>It sounds like you might not be quite getting the concept behind this sort of interview. Although some code is written, this is (usually) a test of how you talk about code. You want to show that, if a co-worker asks for your advice on how to solve a tricky problem, you will be able to help them figure it out.
The details of the exercise aren't the point...and I'm sure the reason the interviewer likely gave off mixed signals about the extensive documentation is because time is limited and a good interviewer makes sure to keep the candidate on track so that there's enough time.
Common data structures have no place in any type of interview.
“I just can’t hire someone who fails this sort of problem”.
Given that this person was applying for a general backend position building foundational, framework derived features (mostly CRUD and some light analytics) it was confusing to me. There is literally zero application for graph traversal in their work. They will absolutely never encounter this sort of problem in the course of developing our software...which is b2b, targeted at industry experts: we build software that generates reports. Not even complex aggregates...just moving window averages and the like.
At this point in my career, after building more than one team/business I’ve learned that the shape of your technical interview loop informs not just the codebase you generate...but also your engineering culture.
Otherwise, it's unlikely that most people will be able to solve it in 45 minutes, even with hints, and then you don't learn anything other than that they failed at an unreasonably hard problem.
So, one of the problem's solutions being a binary tree isn't itself necessarily a problem. The interview could be done well or badly depending on execution, and we can't judge that from afar. All we really know is that a binary tree was somehow involved.
---
At least, that's the idea. Interviewing is still terrible. It's pretty random to base a hiring decision on a few (extended) questions, and I think interviewers are left on their own too much to come up with good questions. How do we even know what's a good question or not?
Sometimes I wonder if it wouldn't be better to choose twice as many candidates as you need and pick half of them at random, just so everybody is clear that there's a lot of luck involved and they don't take either success or failure some kind of precise indicator of someone's worth.
If that's the metric being measured, then sure, it's a bad idea.
Why?
Because any single interviewer has a set of well rehearsed questions they know like the back of their hands. They know the different possible solutions and understand their pros and cons. This makes the interviewing a routine that lessens the brain drag. I in an interview setting you wan't to know your shit.
Using the candidates online source code repo portfolio would mean that the interviewee would have to try to understand the candidate's code and whether it'd be applicable to the intended role and how well the code would lend itself as a measuring stick for the candidate's skills. This is a lot more work and so obv it won't be done.
Also, it's never obvious how much someone contributed to their portfolio. Just being able to explain it doesn't mean you were the sole contributor, or the contributor at all, and it doesn't give a great indication of how you work or how well you can analyse problems.
I've seen this claim getting bandied about a lot lately, but I'm increasingly less convinced. You receive 10 n-dimensional vectors of programming and engineering skill, aka "applicants". You take their dot product with a ten-dimensional vector. Even assuming you can do that correctly and reliably, on what basis are you so sure that the ten-dimensional vector you've chosen has any relationship to what you really need? Repeatably and accurately asking a detailed question about recursion and pointers in a job that rarely calls for it just means you are repeatably and accurately collecting irrelevant information.
I've been chewing on this claim for a few months as people have been making it, and it's not like I'm entirely unsympathetic to it, as hiring does obviously suck. But lately the more I think about it, the less convinced I am this is the path forward. It just seems like a great way to institutionalize bad practices.
I think you need to embrace the diversity of the incoming n-dimensional vectors and pursue a strategy of exploration. Fortunately, they're not all uncorrelated and you do have an idea of what you're looking for. I see interviewing as a process where I'm seeking the answer to the question "What are you capable of?", and I want to seek out answers focused on how that relates to what I'm looking for, and that may mean I thought I was interviewing a dev candidate but I'm actually interviewing someone suitable for QA, or vice versa, or I thought I was getting an academic and I've got an old UNIX sysadmin, and these are just the examples I can quickly give. (What really happens is even more detailed, like, they clearly know their APIs but they're pretty sloppy in their naming, or I started looking at their personal projects for skill and was surprised at the documentation, etc.) It's not an easy approach, but why would we even expect there to be an easy way to analyze applicants?
(Or, to put it in more statistical terms, rather than applying a fixed vector dot product, I approach applicants in terms of a multi-armed bandit, where I'm trying to find their strong points. It helps in this case that the "multi-armed bandit" is actually incentivized to help me out in this task.)
So the only thing you really can do is ask objective questions or check technical skills. Thus the choice is not between hard skills or soft skills, but between hard skills and no skills because the soft part deteriorates extremely quickly and becomes essentially useless at scale.
That basically begs the question of what I'm saying though; why should we expect that there is an "easy to teach" process that "works", for some useful definition of "works"?
Our desire for something to exist does not mean it does exist. I think a lot of the rhetoric around "fixing" interviews is making this fundamental mistake, where what is desirable is laid out, and then some process that will putatively lead to this is hypothesized, but there isn't a check done at this phase to be sure the desired characteristics can even exist.
It may be that evaluating human beings and whether they can fit into technical roles is just fundamentally hard. (I mean, when I put it that way, doesn't it sound almost impossible that it's untrue?) While acknowledging fundamental difficulty is not itself a solution, it does tend to lead one to different solutions than when the assumption is made that there must be some easy, repeatable solution.
I can sit here and wish there was some easy way to communicate how to be a full-stack engineer in 2019, but that doesn't mean that such a thing exists, and anyone trying to operate on the presumption there is is headed for the shoals at full speed. People who know such easy things don't exist may still wreck themselves but at least they aren't guaranteed headed towards the shoals.
(Or, to put in another really technical way, the machine-learning-type bias that somewhere in the representable set of interview processes there must in fact be a good solution is not necessarily true, and think there's good reason to believe it's false.)
You guys are absolutely correct about the reference questions. I can find no fault with that.
However, there's absolutely no question that I'm the sole contributor to all my code. Most of my repos have only one contributor (Yours Troolie). A couple have been forked off.
I do link to a number that have been turned into larger projects; with multiple contributors, but there's no question that's happened.
Also, those are my old PHP repos; not the ObjC or Swift ones.
There's ten years of commit history in the repos. You could run crunchers on them to do things like develop velocity and productivity metrics.
I'm also quite aware that my case is unusual. Most folks don't have such extensive portfolios, and are much more of a "black box."
A bad actor could easily just have someone else write the code or copy it though.
1. Look at the project list, if it's all tutorial projects, you're already done. There's no use looking closer because you won't be able to tell if it's their source code or if it's copied from a tutorial.
2. If it looks like they have some real source code, apps or frameworks they've written from scratch, pick one and look for an important file. There's no trick to identifying an important file, in most cases the projects are small enough that it's obvious. (And if the candidate has large and complex projects, you've probably already identified an exceptional candidate.)
3. Once you've opened the file, I'm always stunned at how easy it is to evaluate. I'd say in about ten seconds of scanning I've usually identified three or so mistakes that roughly gauge that developers ability. In which case I'm done, unless I want to dig for some material to discuss on a phone interview.
4. If I haven't seen three mistakes, then we have an exceptional candidate, this is really rare (maybe 1 in 100), so we've already identified an exceptional candidate in about a minute.
One of the keys takeaways is that process only takes a long time for a truly exceptional candidate, in which case I'm happy to spend the extra time. I'm baffled by the preference for coding tests, because those I find way harder to evaluate. I know in my bones what production ready source code looks like, because I've written and read it all day, everyday for ten some odd years. Evaluating someones coding test is way more mental gymnastics and guesswork for me.
For the people who have experience evaluating GitHub profiles, but instead prefer giving tests, I'd love to hear how your experience deviates from mine. I know there's nothing special about my ability to evaluate source code, e.g., I watch my colleagues do it all day as part of code review.
In Swift, this is expressed by "??".
It means "If the previous test returns nil, then execute what is after the ??".
For example, if you have a concrete Int, but the source might be an optional, then you could do something like this:
let a = b ?? 0
You can chain these, like so:
let b: Int? = <something from somewhere>
let c: Int? = <something from somewhere>
let a: Int = b ?? c ?? 0
You can have a lot more going on in the handlers than simple assignments, but this gives you an idea.
nameLabel.text = user?.name ?? "Guest"
if let name = user?.name {
nameLabel.text = name
} else {
nameLabel.text = "Guest"
}In some languages, you simply write:
if (user)
nameLabel.text = user.name;
else
nameLabel.text = "Guest";
nameLabel.text = user.name if user else "Guest"
When constructing objects "in-line" in c# I actually used to see the ternary operator quite a lot, as in
new SomeClass() {
Val = valSource == null? SomeClass.DefaultVal : valSource
}
How the hell is it worse? It lets me write things like
toolbar.visibility = userSettings.showToolbar ?? defaultSettings.showToolbar
someOption = localPreference ?? onlinePreference ?? defaultPreference
Giving the developer succinct ways to prevent program failure from unexpectedly undefined values is a feature.
> It's called the "if" clause.
If we got rid of everything we don't absolutely need in programming, we would have to get rid of 98% of Swift syntax, and probably every modern programming language including Swift.
I started off with machine language, in embedded systems. You can't get much more "raw" than that.
I have been writing Swift exclusively for a long time. I speak it without an accent. It's my beauty.
But I also know that you can have so much sugar you fall into a diabetic coma.
Exactly my feelings. Same thing here started from machine code and now doing everything else including kitchen sink
Type in a bunch of numbers, then set the PC to 0.
Assembler was great after that.
I do not remember that stuff fondly. It sucked.
"If" is often a statement, not an expression, so they aren't equivalent in a lot of cases. I'm not sure if this is the case in Swift, but I'm fairly certain that Swift's '?' operator also does unwrapping and propagation, similar to '?' in Rust.
int a = b ?: c ?: 0I hate it when things like this get names that everyone's supposed to know and it's considered a mark against you if you've never heard it before, but I do think the name Elvis Operator is hilarious. :D
> The name "Elvis operator" refers to the fact that when its common notation, ?:, is viewed sideways, it resembles an emoticon of Elvis Presley.
b = list.next.to_s || "Reached end of list."
a = b || c || 0
edit: One BIG downside to this I forgot to mention at first: If nil and a false value are both possible for a variable, then this construction can betray you and break your heart.
Personally, I like the ternary operator, and I also like the nil-coalescing operator, but I'm quite aware that they can produce difficult-to-maintain code, so I'm careful with them. I have gone and done some silly stuff with both, but then, I realized that I was leaving unmaintainable code.
If you use godbolt.org, you can actually see what code is produced by the source.
int a = b ?: c; let studentScoreFormatted: string = student.formattedScore ?? 'Student has not taken this test yet.';
It is awfully helpful for ensuring you handle error states in displaying API values. Additionally if you want this behavior but when the value is falsey, then you can use `||` instead.
a && a.b && a.b.c
a?.b
a && a.b
It's identical to something similar though
(a !== undefined && a !== null) ? a : bBut also, as another commenter pointed out, there is a distinction between "optional chaining" and "nil coalescing" and I explained (roughly) what optional chaining is.
Is that the one you had in mind?
a ?? b
a != nil ? a! : b
https://stackoverflow.com/questions/2100758/javascript-or-va...
optional1 ?? optional2 ?? optional3 ?? ifeverythingelsefailsvalueif b is not nil, then a = b else a = c
return a or bI don't know about that; if Apple had lowered their hiring bar, they'd likely have enough engineers to not be constantly starving one project or another of talent because it's being "borrowed" by the Big New (next-to-announce-at-a-keynote) Thing. That still seems to be a problem; I haven't noticed any decrease in the number of Apple projects that "lay fallow" while their engineers are off doing something else.
The interviewer probably wanted you to write idiomatic Swift. That seems reasonable.
Most of the open-source code that I've written has been for other people to take over. Most of my repos are still 1-contributor ones, but every single one has been written to be extended. The ones that have been extended are being extended very well, indeed. I have had almost zero questions about the codebase.
Given that a large portion of the discussion in this thread is around what this operator is, it seems somewhat valid for a company to want to see you use this. It might represent a deeper experience in the language being used, or at least some previous study of syntactic options.
The other parts of the interview weren't as bad but they also weren't great. Expecting you to know what happens when you export an int as 'main' instead of a function, for example - you can certainly figure that out from first principles or happen to know, but why should you?
It's sort of a "when a company shows you who they are, believe them" situation - even when I did get offers, seeing this reduced my confidence in the company.
In any case, as is usual with all employers, these days, they completely ignored the focused, relevant links that I sent them to elements of my extensive portfolio of repos, and, instead, based the entire interview on a 50-line binary tree test in Swift.
I'll make it clear that I'm NOT a fan of these. I am mediocre, at best, at them, as I don't come from a traditional CS background (I started as an EE).
In any case, during the test, I did what I always do when I write code. I stopped to write a header document for the function.
This was clearly not something the tester liked. Also, to add insult to injury, they dinged me for not writing a cascaded nil-coalescing operator. The code they wanted me to write was difficult to understand, and absolutely not one bit faster.
What makes this even funnier, was that this was for an Objective-C job, and the links that I sent them (that they ignored), were to ObjC repos.
After that, I just gave up on them. It kind of shows where a lot of this is coming from.
Dynamically-generated documentation can be great (It's clear that the lions' share of Apple's developer documentation is dynamically-generated), but it requires a VERY disciplined coding approach. I suspect that they may be hiring less-disciplined engineers, these days.