I'm not sure I know how to write anything from scratch anymore, because I just search/read/alter/test. The breadth of what I work on is 100x wider than it used to be, and so I've become absolutely dependent on quickly reading docs, copying code found online, and then deep diving into testing and rolling it out the door.
I deliver a TON more, but I'm convinced I'd bomb literally every interview I go to today. Today, for example, I updated our firewall rules, updated some Java business logic, tweaked some javascipt and PHP on the site, reversed an odd macro email-phishing virus we got, configured a new RDS server VM for clients, and updated some network GPOs. 20 years ago, I would have never worked on ALL of those things in the same week - let alone the same day.
Maybe we should interview with small take-home tasks to be submitted with some write-ups to test how people research, reason, and write-up problems, rather than writing code on the spot on a whiteboard. ...but maybe that's just me.
Now things are TOTALLY different. Doing a good job requires extensive, encyclopedic, knowledge of what's out there, how well it works, and how to integrate it. npm, nuget, maven, anaconda, we all know the drill. In a day's work it's much less necessary to implement an algorithm from memory.
What should programmers know from memory? Simple stuff like fizzbuzz. The difference between TCP and UDP. What DNS is for. If SQL data's involved the difference between JOIN and LEFT JOIN.
And, if they're experienced, they must be able to describe intelligently how their own stuff fit into the bigger system they worked on. Because there's always a bigger system.
If they're being hired to be a tech rep to an *sshole customer, possibly their performance under pressure matters a lot. Otherwise, not.
This business of high stakes quiz questions serves just one purpose: feeding the ego of the interviewer. "We have high standards!"
Yeah, so high that we wouldn't hire Jesus of Nazareth to be a storyteller.
Our software is utter trash because the business is very clannish, fragmented, and the people in charge either never ever wrote code or did it 15 years ago.
And yet we fail 95% of the technical candidates we interview because they don’t meet our “high” standards. We won’t even consider hiring remotely (but within the country because we’re making government software) even though an overwhelming majority of the company and tech team has been working from home 80–100% since March... No, we’re insisting on rejecting the handful of candidates that apply in our small town. Insane.
I wouldn't say that. What I feel like I've accumulated in knowledge over time is I can look at a new problem and without having the solution/encyclopedic knowledge, I can know in my gut that (a) there is a solution, and (b) the solution I'm looking at is not the solution.
Merely being able to look up things on the internet without these two things means you will either give up too early or settle on the wrong solution.
This is the most succinct way I can describe what I think >a decade of experience is worth compared to being fresh out of college.
Unknown unknowns: The things that you don't know are possible and thus don't even know how to start solving. You will accidentally reinvent the wheel, most likely very badly. Or give up right away.
Known unknowns: An experienced developer most likely unconsciously knows (has read on HN/Reddit/Book/Blog some time in the last 20 years) that a thing they encounter has been solved already, at least partially.
This allows them to start searching for the answer with a few key words, because they know it's possible but don't know how it can be done.
Same comes with having a network of people who know different things, I know the bare minimum about professional pentesting, but I know a few people who I are absolute pros in the field.
I feel like my brain is full of "I read a headline about this once" tidbits, in part because of HN. It's like I don't know the answer, but I know the question has been solved before so I know there is an answer.
It's scary how true this is. I know one manager who routinely rejects perfectly good candidates for making negligible mistakes in the interview. All on the grounds of "We have high standards!"
Knowing how to maximally exploit a CPU is way more important than knowing eight different Javascript frameworks if good software is your objective. And frankly, learning Node is way easier than figuring out how to structure basic, bare-bones Javascript so that it leverages your L1 cache.
And therein lies the problem. How many interviewers dock marks for iterating over columns, instead of rows? Because that matters, a huge amount. How many interviewers would give credit for "how can you speed this up?" if the interviewee said, "write it in C, and simplify the datastructures you want me to use so we maximise sequential lookups over basic arrays, to maximise cache usage." They'll look at you like you have three heads.
"Don't you know Big N complexity is the only thing that really matters if you're looking for speed?" - then you get Electron.
I feel like this is a huge oversimplification. I’d argue that for sufficiently large projects (say, Chromium) every single programmer who works on it could have a strong understanding of performance fundamentals but the product itself could still have performance problems because there are necessary levels of abstraction involved and no one person has the entire codebase in their head. Performance problems could come from emergent behavior that could not have been predicted by the original engineers.
But, as for implementing an app on top of Electron. Say I need to write a cross-platform app with a consistent style and fluid animations. I know how to write a NEON implementation for ChaCha20 for fun, or write a zero-copy binary property list parser that’s faster than anything I’ve found. I have a decent understanding of performance. That doesn’t help me write this cross-platform app. I don’t have to time to write a novel native UI toolkit that allows me to share code while maintaining platform consistency and native performance. I don’t have time to fix the memory consumption of Chromium. I’m going to write my Electron app in JavaScript, carefully, and hope the performance will be acceptable (but not great). I don’t see how that can reflect on any individual programmer poorly.
There is likely a huge organizational focus on performance and more people expressly dedicated to the task because it is a higher priority for Epic. It is directly correlated to Epic's ability to deliver a successful product to game companies, whereas for browsers it is slightly more orthogonal to their success.
LLVM has a bunch of contributors who likely understand the intricacies of machine code better than either of us, and:
> Each LLVM release is a few percent slower than the last.
> The larger problem is that LLVM simply does not track compile-time regressions. While LNT tracks run-time performance over time, the same is not being done for compile-time or memory usage. The end result is that patches introduce unintentional compile-time regressions that go unnoticed, and can no longer be easily identified by the time the next release rolls out.
https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html
I think if those LLVM contributors understood compilers better, they wouldn't be introducing those issues. Look at Jon Blow's achievements on Jai. LLVM is the bottleneck for his entire compiler at the moment, and he's planning to replace it with what... Three people or something? But I also think there are structural issues there. I don't think a top-down project from a large company gets to use that excuse.
As an example, Stellaris had performance issues that were CPU bound for a while and it's gotten better. It's not a visually demanding game after all.
I just think that's a weak excuse, especially given most games have tremendous complexity running through the CPU too.
(As a side note I don't think paradox games are a good example. They're famously poorly optimised.)
Developers love thinking about performance. It's fun and asked us to use so many of our skills. However, for many products other quality aspects are more important, like maintainability, extendability and expediency of development.
That performance often falls by the wayside on terms of business priorities ends up being reflected in the typical developer skill set.
But I think Electron in particular is a symptom of the fact that GUI frameworks are in general horrible. There was a market gap for usability because using everything else was obtuse, and now we're paying for it.
FWIW all of slack competitors are also electron (rocket.chat et all), so it seems like you possibly know something that other engineers don't and might have a competitive advantage!
If someone released a GPU-accelerated version of Electron that had the performance of the GUI in basically every video game, it would destroy Electron. Now, would it be popular? I'm not sure, but let's say the answer is no. Ok, now imagine Google released that.
> Knowing how to maximally exploit a CPU is way more important than knowing eight different Javascript frameworks if good software is your objective. And frankly, learning Node is way easier than figuring out how to structure basic, bare-bones Javascript so that it leverages your L1 cache.
Learning Node isn't easier than learning how to structure basic, bare-bones code that leverages L1 cache. In fact, it's quite the opposite. You can learn cache locality as a concept in much less time than you would learn Node (or any programming ecosystem for that matter).
As someone else said, businesses hire software engineers to solve business problems. Speed often isn't a priority. Fast software will make the experience perceivably better, but it's hard to get on a sales call and tell a potential customer that your application loads much faster when they are looking for feature X. And most companies buying software are looking at a checklist of features first and then maybe the experience.
You also need to put in the time to make software fast and then keep it fast. It's not something you can tack on at the end—if you want something to be fast, that has to be carefully considered from the very beginning. By the time people notice something is too slow, you're burdened by half baked architecture and a monstrosity of a codebase. At that point, it's near impossible to really make anything fast.
I think the hugely successful SalesForce proves this point. Just one standout among many such products.
If the market values fast software, you'll see a lot more fast software. There _is_ a lot of unnecessarily slow software these days, so it _is_ starting to happen. Think Superhuman, Linear.app, etc. — an entire category of software based primarily on the idea of being fast, aimed at the power user. If these apps succeed, you'll see a lot more of them. If the market doesn't value fast software, most commercial software will be slow.
I don't think companies choose to make bad software as a tradeoff. Salesforce had enough budget to build out those features and not be terrible. I think in general, when software is bad it's because the company wasn't able to make it good. And I think the distinction between those categories is important.
My point was that SalesForce has fairly poor user experience and performance, but does offer the features. It has the additional advantage (for SalesForce) or quick lock-in once the customer commits to it. SalesForce has improved the user experience over time because they have the customer base and revenue to allow that.
Optimization of speed is sometimes it, sometimes it isn't.
I have worked accelerating algorithms in VHDL with a PCI-e interface, embedded linux without a MMU because a MMU uses too many logical gates, digital signal processing systems (FFT, goertzel, sigma delta filters) that had to process a lot of data under uS and etc.
Now a days I work more in the devops space, full stack dev and whatnot. I have worked with a lot of technologies, different constraints, different teams, different companies (12 in total) in different industries.
Trying to paint all business and developers as bad or as cheap because business requirements do not align with your view isn't really fair.
Notably, I’m also not logged in, which might be another thing they’re trying to get me to do and another difference between those who hit this more often than not, and those who rarely or never see it. It’s been like this for years.
If I remember right the app would also crash but it could take bigger loads. Not sure, I uninstalled it.
Yes, that would be unfair.
The first chapter is all about that and how software engineer isn't programming. You seem to think as programming and I believe you're missing the bigger picture.
Does it? I've seen some electron apps that run like dogs, and others that seem perfectly performant. So, I'm curious... in what way does the framework run like shit? In what way could it be improved?
> How many interviewers dock marks for iterating over columns, instead of rows? Because that matters, a huge amount.
I think you mean the difference between SoA and AoS. I'm not sure that one is inherently better than the other, except the former scales well for large homogenous datasets.
I doubt optimising for DSPs/SIMD/big-data to maximize throughput and reduce cache-misses, is something the typical FAANG employee needs to know about. Could be wrong.
> "Don't you know Big N complexity is the only thing that really matters if you're looking for speed?"
It does, even if you cache-align and pool your data. And you can optimise your in-memory data-structures (and database IO) later, if profiling finds them to be a bottleneck.
And almost no Qt apps run like that. "As long as I don't notice it most of the time, it's not slow." No, sorry, I don't agree. Frameworks should be fast. Slack is unforgivably slow.
>I think you mean the difference between SoA and AoS.
I mean literally in the interview when they do a nested for loop over primitives. Do they lose marks for going row-first? Why isn't that considered a basic rule? It's not complicated. Most interviewers don't even realise there's a difference (!!).
>I doubt optimising for DSPs/SIMD/big-data to maximize throughput and reduce cache-misses, is something the typical FAANG employee needs to know about.
Twitter is so bad it crashes my browser. It's 90% text! The only ram-hogs are auto-playing videos that dissapear after you scroll past them. These engineers are paid half a million per year. Half the time the website doesn't even load (!!!). That's insane.
>And you can optimise your in-memory data-structures (and database IO) later
Ehh, skeptical. Unless your data & algorithms are structured as contiguous arrays of primitives to begin with you're going to have trouble refactoring the abstraction.
It's not objectively wrong to do this. Suggesting that "SoA is always right", tells me that maybe you don't understand the trade-offs between expediency, readability and performance... or understand the trap of early optimisation. Always measure first before optimising, otherwise write code that's easier to read, and simpler to write.
> Twitter is so bad it crashes my browser. It's 90% text!
Not sure how knowing how to micro-optimise cache-effects fixes these issues. Profiling and spending time on perf does, but they've decided it's just not worth their time.
> Ehh, skeptical. Unless your data & algorithms are structured as contiguous arrays of primitives to begin with you're going to have trouble refactoring the abstraction.
The keyword is refactor. Developers and organizations do it all the time - or at least they ought to.
Disclaimer: Used to work in the video games industry. Literally worked for years doing perf, and cache-level optimisation.
No, I don't mean SoA, I just said that.
I don't think twitter is crappy because of cache misses, I think it's crappy because they don't have a solid understanding of what their code is doing. Ignorance of caching is another symptom.
If you build your game on an entity-component system, you can't "just refractor" that to make it contiguous. Your structure is pretty baked.
It's my hunch that you have little idea of what the code-bases for twitter are like, nor what factors are at play that affect usability issues.
> If you build your game on an entity-component system, you can't "just refractor" that to make it contiguous.
Moving to object pooling of components is very do-able. There might be some extra work, like extracting a generic matrix hierarchy and physics primitives out, but you'd only do such a thing if you found that d-cache misses on v-table lookups, or if i-cache misses due to update code churning were of real concern... and these could realistically be mitigated with homogenised object pools for the particular use case... though usually yes.
Edit: I'd expect anyone on an engine team, or technical programmers at a game dev shop, or maybe even someone working on a browser renderer to have such knowledge from day 0, rather than the average FAANG employee.
I have seen a lot of really bad Qt UIs as far as responsiviness. The Signal/SLot framework can get really hard to follow in huge code bases with lots of state. The whole thread interaction in Qt is not ideal.
It is interesting because most of people are now actually using PyQT or pyside. Even with these being slower than pure Qt. Because it is easier to adjust to business requirements with Python.
Oh, and I have personally rewritten some of these UIs in React and replaced them with a web browser which made them much more responsive.
I’d assumed Twitter showing me “an error occurred” on about 50-75% of inbound link-follows to their site, across multiple browsers on multiple operating systems, was an intentional “feature” to drive me to their app.
If Slack was written in Qt with the same budget it would just be fast. Even with effort we don't have Qt apps that behave like Slack.
Do you feel that you somehow know something that nobody else knows ? It’s all about trade offs . Being able to move quicker seems more important to businesses than writing more performant software .
Note that one person is literally doing that, with ripcord. Looks like shit but it illustrates the point.
Monitoring , metrics , deployment , etc.
I am also looking to play said game on all platforms ! iPad , Android , iPhone , Mac , Linux , Windows and etc.
Would be great if the chat client supported markdown as well
Complexity for me is the software engineering part which the Software Engineering at Google displays really well and I agree wholehearted. I would argue a game is simpler because it doesn't need frequent updates and doesn't live forever.
I work in systems at my company used in a very big scale that were written 30 years ago and are still maintained / changed. That system I would argue is much more complex than any game.
Even tho from your point of view it probably only updates files on disk :)
Granted, they made Electron run fast enough to be usable but I wouldn't call it good software.
Imagine VS Code was exactly how it is now, but had the extensibility of Emacs. It would blow everything else out of the water. Why isn't it like that?
VS Code is doing well here compared to its competition. It is quite extensible, you can add extensions to it written in JavaScript that can add new UI and make changes to the editor view. It's also much more performant than either of the other two IDEs I mentioned, even after you load it up with extensions to replicate some of the most used features from those IDEs.
Because most of us don't care. I need my code editor to just work out of the box. I want to be able to write code and install a few plugins to enhance the tools I'm using. Hacking my editor is a waste of my time and even if I wanted to, I'm certainly not going to learn lisp to do it.
How much money does the Y Combinator Web team receive? Do you think its enough that they should be able to render... Text?
https://github.com/Microsoft/vscode/issues?q=is%3Aopen+is%3A...
I will say that this was way worse a couple of years ago. They seem to have added a lot since then.
Which is why 90% of all software is very profitable crap.
I'm somewhat like you; I do a wide variety of tasks every day and simply can't keep all the different rules and syntaxes in my head. I'm terrible at tests anyway and would probably bomb a FAANG interview badly because of my lousy memory.
As an interviewer, I would rather someone be generally smart, have a good work ethic and lots of experience solving problems. In the long run that seems more useful than being able to write computer programs on a piece of paper in a conference room.
It causes a surprising number of problems. A lot of candidates come in with their environments just very poorly configured, run into weird dependency errors, mismatched installed versions, no linting or syntax highlighting set up in their editor because they don't actually ever code on their personal computer, etc. It's not uncommon to spend half the interview watching someone debug their dev environment, or struggle to remember the basic syntax of their favorite framework since they aren't working on the same codebase that they're used to.
I've mostly come around again at this point and decided that even if I like this type of interview best in theory, focusing on standalone problems that can be done in coderpad with no dependencies is a more reliable approach.
Now THAT reflects the actual daily experience of working programmers.
All the maddening little configuration options to get things working correctly, and seem to take up far more time than actually writing code to solve customers problems.
Isn't that a useful way to filter out candidates that you don't want to hire? Presumably they know in advance what kind of code you're going to ask them to write, so they have time to set things up beforehand.
The reality is that for the past few years at least in SF, hiring engineers has just gotten more and more competitive. Most people who pass our interview will have multiple other offers, often some from companies with a bigger name brand than our own. At least in my opinion, most companies in this environment can't afford to have such strict purity tests. It's supply and demand.
This balance may be changing now given the current recession, it seems even in tech things have cooled off a bit the past few months.
Its actually bad practice in a lot of peoples opinion you should develop and test on an identical system hw/sw to the system you will deploy on.
You need to provide a laptop or like, a mac mini or something you know you can plug in and has baseline requirements for working on the problem you're giving them. And you need to make sure that the problem isn't complex enough that they can't do it in the allotted time if they struggle a bit with an editor they're not used to (including like, vim without their usual barrage of scripts).
Otherwise you're just trading one bias for another: winners will be people who have personal laptops set up for coding, which is not a universal trait of good employees who code.
Let them use a laptop they bring if they want, but be ready to supply them with something they can use if it doesn't work out.
Do you really have to test for the ability to use tools instead of the ability of reasoning? A whiteboard doesn't seem bad for that. I would like to understand how the candidates reason, how they interact with colleagues and yes, also how they handle stress.
Example from yesterday: I had to fix a problem on a software in production before the end of the day (it must be available today) and before a reasonable hour (I wanted to go out at night.) That means working fast, debug, find solutions, possibly develop workarounds that leave the system working even if the problem is still not fully understood and solved and, most important, don't panic.
I worked at a place that got around this by giving the candidate a choice of their own laptop, a Windows laptop, a Mac laptop, and an Ubuntu laptop. Half a dozen different IDEs on each.
Of course, you have to find someone to take on the glamorous job of keeping track of all the laptops, and wiping them between candidates...
> Do you really have to test for the ability to use tools instead of the ability of reasoning? A whiteboard doesn't seem bad for that.
It depends: If you're a big believer in test-driven development, red-green-refactor, clear naming and good code structure, test coverage, use of version control - you don't tend to see those in whiteboard coding.
For example, I'm an Emacs kind of guy, so if they hand me a Windows laptop, do I limp along with Notepad? or some IDE that happens to be installed? Generally, as soon as I've settled in at a new job, I've customized my work environment with something as close to Linux and Emacs as possible -- if Windows, I'll install Cygwin if allowed, and/or Emacs and GNU utilities.
I'm not sure I would even look like a proficient computer users on my personal laptop. It runs Windows, and at this point my macos work environment is so heavily customized that I'd be bound to get tripped up just by the sudden unexpected need to use a mouse.
It can be easily solved by asking what is a parts of code do, or how it works and why.
I'm a huge fan of giving people tasks that somewhat resemble a real world problem they'd likely encounter or at least aligns categorically with their proclaimed resume feats and more importantly on top of that giving them the same environment they're comfortable working in on a daily basis which might be on a laptop in a quiet room from 6am to 10am in the morning.
However, I'm usually instantly met with the "oh well we don't want to expect too much of our interview candidates" mentality as if asking them to do a "take home" (rather than telling them to figure out how to take a day off of work for an onsite panel) is somehow grotesquely disrespecting their time and would make the company look bad if the broader community even got a whiff that it had been considered. I'm so confused. People easily identify that white-boarding interviews suck for more than just the interviewee. And yet any time a solution is proposed that involves doing something other than putting the candidate in a room in front of a whiteboard for an hour, it's shot down.
I've concluded it's a generational thing and the problem won't be fixed until we get a wave of hiring managers that weren't schooled on the Google interview process. But, also note it's a self perpetuating issue too so :shrug:.
An asynchronous test is definitely more flexible for all parties, but it also means the employer can more forward with far more interviews than they would be able to do in person. Leading to more candidates wasting their time doing nonsense work when they have proportionally less of a chance of getting the job.
Possibly I'm just bitter because of the time I spent 4 hours on a take-home only for the company to ghost me (name-and-shame: Instacart). But at least for in-person interviews they have to buy you lunch before the ghosting can occur.
Guess what? It wasn't. They rejected me as soon as I de-anonymized to allow them to see my resume.
Arthena, a Y Combinator funded company, did this to me. It truly was a waste of time.
To top it off the interviewer then sprung a surprise leetcode problem on me that had to work and was required to be written in a language ill-suited to the task. I bombed it and the interview ended. No one ever even ran my submitted program.
mvn clean package worked.
Turns out the guy was running mvn exec:java.
Not to mention it doesn't test the collaboration aspects of real work. Imagine doing your job but you're not allowed to talk to your teammates in case of a blocker. How are we doing our jobs here?
But when it comes down to actually starting them, I will always pass if they come before any interviewing round. You don't yet have a stake in the process.
I would be (and have been) one of those people. Why? In short, likely because your take-home tasks are tedious, boring, and unrepresentative of real-life work. They are not whiteboarding, but they aren't necessarily any better.
I have done take homes as a candidate, and also have reviewed them on the hiring side. Most of the time, as a candidate, any take home I have done has been wasted time. Nothing I feel like I could count as a significant contribution, or something I could add to my resume. Take homes usually have some boring cookie cutter problem, with your most nitpicky code reviewers as the judges. Or it's something that's grotesquely oversize that's expected to be done in two hours (hedging with "but feel free to use up more time if you want"). As a reviewer, I see that it also leads to candidates doing ridiculous things like overusing decorators or metaclasses in an attempt to impress the reviewers.
Honestly, as a candidate, I would be 100% satisfied with a bitesize fix to an open source library that your company maintains, or even a bitesize fix to a closed source library under contract. Or pair the candidate with an employee who is working on a real, minor task at your company, and let the candidate "drive". Give me something real to do, not some contrived situation about an ordering system or building the next Twitter.
My mini-conspiracy theory about this is that most companies are so embarrassed about their codebases and internal process that they don't let prospective employees look at them until after they are hired.
It can take relative ages to become familiar with a code base, especially a large one, such that you can easily hop in and commit fixes that actually work. I'm not going to spend hours trying to gain context for the code, or deploying and testing it.
The employer is going to ghost 80% of their candidates anyway, and if your fix does work, you just did free work that benefits the company for little to no gain for yourself.
If none of their codebases are easy to jump into, then that might be a red flag in of itself. One thing I suppose I have been lucky about is that I have worked for companies that have some (albeit very minor) open source presence. I'm not talking new features. IMO a small fix to an existing codebase can be as minor as adding a new CLI flag, or lightly modifying some existing behavior. In many cases, it's what you'd give a new intern as their first fix.
> if your fix does work, you just did free work that benefits the company for little to no gain for yourself.
Well the gain is that you learned to work with a real-life codebase. The thesis of my comment is that take-home projects do not often approximate a real life codebase well.
I disagree that the goal of an interview experience should be to necessarily give the candidate a new portfolio accomplishment. It's cool if it works out that way, for sure, but that can't be the expectation. I'm mostly interested in incrementally improving the status quo which also isn't focused around an interview day that bolsters your portfolio as an engineer.
I will say my favorite and most memorable interview experience was a phone screen followed by a take home to implement bottles and kegs (a fizz-buzz game) in javascript, a language I was/am not proficient in. Come onsite day, we worked though a ux design problem and a database design problem, we pair debugged some ruby code, and then we wrote a multiplayer back-end for my fizz-buzz client, something I'd also never done before. It definitely ticked the "add something to your portfolio" box but also wasn't stressful in the same way flash 1-hr whiteboard sessions are because I was bringing something to the table that we expanded on during the day-long session.
I have never seen a take-home project yet that I could do this with. Also they come with scary "You may not show this to anyone else, ever!" disclaimers which are more off-putting.
1) It's less time spent talking with potential coworkers. Which for me, coworkers (and how we work together/get along) determine about 90% of how satisfied I am with my job (assuming pay/benefits are standard).
2) You're still going to require me to take a day off and stand up in front of a whiteboard anyway eventually. Every take home I've done is an early stage filter. The final round is still a whiteboard panel.
You can learn a lot about a person by what questions they chose to ask you, but only if it's not a thing tacked onto the end of a long interview. If they haven't gotten much time to ask you questions, they only have your interview questions to go on. Which you know are not representative of the kind of work you do (but then, why are you asking them?)
So because you only ever talked to them about things that could readily be had off the shelf, and this is the only information they have, they can't know if you're bad at interviewing or some psycho who spends all their time reinventing wheels and then demanding that other people be impressed by your insanity.
The chances of the latter are bigger than you think. So if it's down to you or another opening, they'll take the other opening, and then you've wasted everyone's time.
Didn't hit it off with the last interviewer so it was a no-go.
If a take-home is required I'd at least expect a code review over it and focus the rest of the interview process on soft skills rather than trivia questions that are answered essentially by the take-home exercise.
1. 2 pms - collab and project management questions.
2. Trivia Q&A with 2 devs and tech projects
3. Lunch with Dir. Eng, and senior dev.
4. Whiteboard leetcode with A researcher and a junior dev.
5. Systems design with Dir. Eng and a senior devops
6. Chat sessionr for questions with VP of Eng.
Of course from their perspective I could be getting someone else to do it for me or something. Or maybe the take-home leaked (which becomes more probable as the company grows).
At my current employer, that’s exactly how we approach hiring. I send the candidate a take-home that broadly covers the basic tech skills they need to be effective in their role (implement a simple test api, some questions about scaling web apps in production, and a possible architecture sketch for a described system). It’s expected to be around 4 hours of work. If they pass that, the interview is free of technical topics - we just talk about your past experience and assess whether you’d be a good fit for the team.
Is this not how other take-home assignments work?
I'm interested to know who your employer is, if you're comfortable saying.
Most people take issue with the repetition of similar tests and evaluations for multiple companies. If A, B, and C were considered different stages of a technical interview, candidates are repeating A and B too often, whereas applying A and B once would suffice for several companies.
It's a problem that is realized when opportunity cost is compounded when interviewing multiple companies and it's not something that a single company alone can fix. A more "Docker-ish" solution where using one of "A" to lay the foundation for many company interviews (and not just the ones expecting you to practice Leetcode) might curtail the problem of using more time and resources than necessary.
But more than that, there is also a cognitive dissonance with the beliefs of how to reform a broken system. Programmers largely oppose industry-wide regulation while also expecting the vetting process to be more consistent and make more sense. This is a tough nut to crack because we seemingly want to have it both ways.
...of programming (because the regulation would never be able to catch up to the state of the art), sure. Of HR practices? I don't think I've ever heard an engineering lead lament that their company's restrictive HR practices prevent them from testing candidates the way they want.
> and it's not something that a single company alone can fix
Sure they can: micro-credentials. Someone needs to be the CompTIA of tiny programming challenges, where you prove once-and-for-all (in a proctored situation) that you can solve FizzBuzz or whatever, and get that fact recorded in some database.
Hopefully, candidates could then put their MicroCredentialsCorp username on their resumes or into companies' application forms or what-have-you; and then first-stage HR automation (the same kind that matches resumes to keywords) could run through a bunch of RESTful predicate-endpoints checks like https://api.example.com/u/derefr/knows/fizzbuzz (which would return either a signed+timestamped blob of credential JSON, or a 404.)
Hopefully also, allow anyone to create a test (maybe have the end of that HTTP route just represent the username+repo of a GitHub repo where an executable test for the micro-skill lives?), such that these micro-credentials can live or die not by central supply, but rather by market demand.
(I think someone suggested doing this with a blockchain once, but there's really no need for that.)
I don't think any of the major companies would accept such a solution. I mean, they make people who already passed their own interviews once re-interview if they leave and come back or apply again too long after they pass and decline. If a company isn't willing to trust its own interview process as a once-and-for-all test, why would they even consider doing so for a third party test?
We could scale this to 3 months on 80% salary (whatever the company is comfortable spending on throwaway) with the full salary after the test period, with maybe even back pay and a little ceremony to make it a big deal. That would kick my ass for three months, cost me nothing long term, put a big smile in my face and let any company hire me without 15 interviews.
Next stage is a technical interview of 60-90 minutes where we a) try to find what their strengths are and how deep they go, and b) ask them to explain how they solved the take-home.
b) is critical. Of course it tests for the skill that is critical in teamwork: communication ability, but it also lets us catch cheaters.
After this it's HR and reference checking.
It's worked well so far.
Got failed for a number of the most trivial reasons - it didn't meet PEP 8 (it was two white space errors, as I didn't have pep installed on my home laptop, so I missed them).
A load of stuff about not mocking tests (setting up that would have doubled the scope of the project). The spec and said if you don't have time, then describe what you would have added in terms of tests - which I did). I did provide the most difficult to implement integration test to prove the system worked.
There was a complaint providing an HTML webpage rather than a JSON endpoint (the spec described it as a "page" and said not to bother with styling - so implied that it was HTML). Plus a couple of other equally ridiculous complains.
Don't waste your time with takehome tests without speaking to someone in engineering first. Sennder is the company if anyone else wants to avoid, I think we should be naming and shaming such companies.
If you're happy, then awesome, but the reason you would have never worked on all of those things before is because companies are loading up more responsibilities onto technical people to cut down on costs.
You carry the skills of 3 roles from 10 years ago: Sysadmin, developer, and reverse engineer, and yet you're likely only being paid for one.
I know I can, in university I implemented huffman compression(I know there is nothing special about it algorithm-wise) in java and I got the best run-time in 2 series of ~100 students, and by that I mean orders of magnitude better; my runtime was on par with the best C++ programs I could find, and my program could work on arbitrary file size, the fastest C++ program I could find at that time (20 years ago?) loaded everything in-memory. I wrote all the data structures from scratch, using java structures consumed a lot of memory and was way slower.
But the jobs I got in my country as a J2EE developer were much better paying, at that time at least, than any C++/algorithms stuff.
If I was younger, with the same singlemindedness I used to have, I'd absolutely spend 1-2 years tuning my algorithms skills so I could get those sweet FANG job.
Or if I had the ego of my ex submediocre-redneck boss who thought Spring Framework was bullshit, without actually knowing it, and got into programming competitions(only to be butthurt by his results because he did not put in the effort to actually practice algorithms and data structures), again, I'd study hard on algorithms and datastructures.
Or if that was my hobbie -- algorithms and datastructures is 100% a valid hobbie -- but it is simply not my hobbie.
Sure, if I encounter a hard problem, I can look up the best algorithms, copy&paste, modify, optimize and optimize untill I'm satisfied with the result, but there simply is no payoff for me to be an algorithms grand master.
> Never _intentionally_ memorize something that you can look up.
I guess you can't quote Einstein, then.
In theory anyway, I always have to look up how to remove a remote git branch or how to do the euro sign on a Mac.
> We're going to go through a few technical exercises together. It's open book, open documentation, use whatever resources you would normally use — though please do not copy and paste complete solutions from StackOverflow and guess&check to reach our solution. It's open language, so please select whatever you're strongest in. If it is a language I am not familiar with, I will ask questions. Some of those questions may be naive. Use whatever editor and environment you're most comfortable in. Please ask questions of me. There is no specifically correct answer, though your solutions should hit a level of baseline correctness. These problems are designed to mirror some typical day-to-day problems you might face on the job; we're not looking to test rote memorization of _Hacking the Coding Interview_. We want working code, but some aspects or edge cases may remain in pseudocode as we iterate on these problems together. There are no designed 'gotcha' moments in these exercises, and if you feel there may be a 'gotcha' moment, ask clarifying questions. I would rather you ask questions than struggle through a solution.
It works well for modern development.
> I understand you want to test my programming ability, and in order to do that, we should do it under conditions as close to real world as possible. Because I don't know every algorithm in existence, I'm going to use the internet like I do normally to look stuff up. And, I'm going to use my own laptop that I've brought here. Is that cool?
Not really, of course, but I'd like to.
Just do it ahead of time instead of on the spot. You're probably emailing back and forth with a recruiter. Send them the exact comment you posted here, and ask that they make sure that your interviewers know about it.
It's amazing how little things can throw you off your game. I had a couple where they handed me a MacBook set up for "traditional" touchpad scrolling (where it works like a scrollbar instead of like a touchscreen).
Every time I tried to scroll it went the wrong direction!
Of course in an interview we aim to please, so I lived with it for a few minutes, but finally asked "Do you mind if I change your touchpad settings?" Of course that led to a brief discussion on the virtues of traditional scrolling.
This was not only precious time wasted, but a minor blow to my self-confidence. Imagine you tried to drive a car or fly an airplane and they had sneakily reversed the steering wheel or yoke and pedals! You would be lucky to survive.
In fact this is why the preflight checklist for a light plane always includes "controls free and correct".
So many languages, frameworks, and libraries copy the same functionality and every single one does it differently.
The cost of looking it up is a little bit of humility. The cost of not doing so is a small chance of spectacularly breaking something for my entire team. Suck it up, apply the Precautionary Principle, and most importantly, get over yourself.
Do it smartly, know what that component is, if that is good for the purpose, if that is the best for the purpose, its trade-offs, but that should be the primary way. With fallback to reinventing the wheel.
We still will have to provide custom built solutions from scratch from time to time (in fact in a lot of cases, the CS is still not mature enough for proper higher level operations) but better to rely on tested and ready pieces.
Recruiters seems to have no clue how to select people for the particular position therefore they go back to the ancient times of CS like this dumb whiteboard thing. I also felt like they seems to expect that custom made employees exists out there and they only need to wait for the perfect candidate, not really expecting someone to learn while the continuous learning is the industry norm, the inherent requirement. I've seen positions remained unfilled for more than 6 months sending away partially fitting experienced candidates.
I failed at technical interview where you must react instantly and accurately without any help normally available in everyday life (Google). After looong time of programming and learning various approaches I find myself question myself continuously even in fundamental matters. Or is it something by age? Nevertheless while being young, self confident and energetic and the Google style of programming was far from invented my fingers were spitting huge amount of brilliant code that did not work until I fixed all the stupid mistakes I made, which took frustrating amount of time. Coding gives a good amount of humility by showing you that you are to blame in every last cases. Every time! Making mistake, misunderstanding something, not knowing necessary elements, misjudging aspects, not checking the reliability of some component you rely upon, it always comes back to you as the computer will do exactly what you tell it to do, it will always be you. Frustrating. I learned to doubt myself and verify seemingly evident matters which does not play well in whiteboard interviews as you might imagine (in fact once I had mental whiteboard interview, speaking about solutions, how common is oral programming in practice?). This is an unnatural and sinfully inaccurate way of judging how one will work in a position. Due to the constantly changing (improving?) profession and the huge amount of beautiful aspects it entails keeping every bit of detail in head that you can spit out in a second notice is far from being a smart expectation. It happened more than once that the right answer occurred me after walking away from the interview as the knowledge bubbled up of the sea of experiences. Once I told someone that sorry, I never met that technique before just to realize later it was an essential component in a task several years back, I used that quite a lot for that one task.
I did not change position too much (3-8 years spent in one place) but I never been hired based on whiteboard test but by trial tasks or probation period, fulfilling the need of the position (leaving due to dissatisfaction every time). In fact I just met whiteboarding recently and I find it hugely inadequate to judge competency.
Without meaning to attack you personally (especially in the context of the rest of your comment), a comment like this annoys me a bit.
I presume by "average" you mean arithmetic mean, but the median is also an average, and depending on the context the median might be a far more useful statistic than the mean. Confusing the mean and the median is one thing, and perhaps you actually used this terminology in the interview; "confusing" "the average" and the median isn't really worthy of comment, and sounds more like a breakdown in communication between interviewer and candidate rather than a lack of technical knowledge. It just seems vaguely hypocritical to me to be expecting a certain level of ability from the candidate and then using imprecise/informal terminology.
In my native language (French), as you describe it, there is no word for "average" (the technical and the common terms "moyenne" are exactly the same). Until your comment, in English, I assumed you could use "average" and "mean" interchangeably.
Although I do know that "average" covers mean, median and mode, when I was young I was not taught that way. First I was just taught "average" with a formula, and many years later "median" and "mode". I don't think I noticed the term "mean" until I learned about median and mode.
You can see this reflected in scientific calculators used at school, where the button for calculating mean is labelled "Avg".
And in Microsoft Excel or LibreOffice Calc, the function to calculate mean is called "AVERAGE".
So nobody should be hard on themselves for not knowing the difference. You probably weren't taught the difference, and common tools work against it.
It looks to me that the common word for statistical mean is "average" in English, but it's not the correct technical language.
You're quite probably right about common parlance..
> but it's not the correct technical language.
..but as you point out it's not really appropriate in a technical context, indeed I don't think I've come across the term "average" being used in this way in technical literature; I've normally either seen expectation (for probability theoretic cases) or mean (for statistical cases).
> So nobody should be hard on themselves for not knowing the difference.
Absolutely, which is why I think being hard on someone for not knowing the difference between "the average" and the median is similarly an issue.
Incidentally, "mean" doesn't quite cut it, if you want to be a stickler about it. There are several types of means: arithmetic, geometric, harmonic, etc. By that standard, you just failed the interview.
I'm going to assume, then, that you didn't read my original comment which started off this line of discussion? By that standard, you just failed the interview. ;)
Touche.
moyenne is mean or average. The formal name is "arithmetic mean" and "moyenne arithmétique".
median is médiane. people frequently use any word but median in both languages when they want to talk about the median.
The mean, median, and mode are three types of averages. None is 'the average'; though if you asked someone random on the street they'd probably give you the mean average.
Mode: On a typical day <<-- most common meaning for average in day to day conversation
Mean: On a day that is in the calculated middle (for some variance) <<-- most common meaning when we think the question is about math
Median: On a day that is the middle for all the possible days <<-- nobody thinks of this, but they think this is what the mean is.
Given that, showing more charity to the comment you're responding to would have been the correct course of action.
Depends on the interviewer.
It's very possible my schooling was wrong, but presumably I'm not the only one.
The arithmetic mean is colloquially called the average and differentiated from the median and mode, but technically speaking these are all averages. They are all estimators of central tendency. It would be not be out of the ordinary if a statistician asked, "which average do you mean" for clarity. Which definition of average is best depends on what you're trying to measure.
I dislike this interview question because it's an area where it's 1) more trivia than practical knowledge, and 2) easy to not recognize someone who knows more about it than you do. It's like if I tried to test your knowledge of the difference between "affect" and "effect", and then you correctly used "effect" as a verb and I thought you were wrong.
If I repeated everything I just said about estimators in an interview, the interviewer might think I'm too ivory tower to realize that "of course he's just talking about the mean!" But then I could also ask why I'm being asked a question like this in a software engineering interview.
It's a language game where no one wins (somewhat in the sense of Wittgenstein).
It has minimum variance, how can it be a terrible estimator?.. ;)
It is a bit tongue in cheek.
As was my reply ;)
before lunch or 4pm or later interviews we’re worse across all candidates
certain rooms we knew were smelly, loud, or poorly converted from like a storage closet scored worse across all candidates
we took some rooms out of the rotation and made sure everyone was well fed/had drinks. the effect is real
In particular, cases were grouped by prison and within each prison, prisoners without an attorney went last. As the well-known saying goes, "the man who represents himself has a fool for a client": the pro se prisoners fare far worse than those with a lawyer. Judges tried to complete an entire prison before taking a meal break, and therefore ended one session with the statistically weakest cases and began the next with stronger set, thereby guaranteeing the result.
If you look at the original data, some other oddities pop out. A physiological process, like becoming hungry, should depend more on the wallclock time than the number of cases heard. However "However, note that in an analysis that included both the cumulative minutes variable and the ordinal position counter, only the latter was significant."
[1] https://www.pnas.org/content/108/42/E833?ijkey=21207497c684f...
It seems like there's probably some value in a "MoneyBall" company that identifies a way to interview without most of the anxiety. Perhaps hiring a few people with remarkably high EQ who customize the interview setting who review the inteviewees' work and watch them program over a few days in their own computer and IDE.
I know I've interviewed people that have frozen up, but for whatever reason I didn't pause the interview and address the anxiety, but rather I tried to adjust the questions (which generally didn't work).
As for interviewing for a few days... Yeah. No. Not in a country with an abysmally bad vacation policy like the US.
You hear something very different than the person who asked the question. And in one case I discovered that my coworker had been asking a question that he thought he knew the answer to and did not; a deep clone implementation (where he never asked about cyclic graphs).
I hope you suggested that this employee get tested for hypoglycemia. It'd probably greatly improve their quality-of-life to go from "my brain isn't working and I don't know why" to "my brain isn't working and I know exactly why; I need to drink some fruit juice."
Once I had this candidate. Damn, I know my questions are deceptively simple on purpose, but he literally couldn't do anything. Not even a trivial brute force. Not even any related simple knowledge questions. Couldn't tell an average from a median. The only good thing I could write in the feedback was "seems to know some basic syntax".
It was quite a learning moment to read that everyone else was praising how this was the most brilliant candidate they've seen in years. Well, mine was the interview just before lunch, in a schedule that was atypically later than usual. I guess starting an interview after most people start their lunch break was asking for it. He also got hired - apparently the committee agreed that "can't think when hungry" is not really that important a flaw.