You laugh at that coding assignment for a senior position but you'd be surprised how many "senior" people interview that would struggle with that and be unable to complete it.
An engineer at our competitor got laid off and my PM found out and hired the guy to do FPGA work. My PM knew the guy through some contracts we had with the competitor and assumed he was an expert in the field. Turns out the guy was more of middleman between program management and the engineers so while he could talk about the work, he hadn't really done it in like 10 years. My PM got the hiring expedited and since we don't really do interview tests in our industry, the guy was now on our team before anyone could ask any pertinent questions.
Long story short, the FPGA team starts assigning him work but it's taking way too long and he's asking for more documentation and for help on things that he definitely would have worked on in his supposed previous job. Eventually we all figure out that he kinda overstated how fresh his skills are and we transition him to a sort of documentation role so he wasn't burning hours on things he just couldn't handle. While he was perfectly capable of doing that kind of work, it involved a lot of insight to our design so it took him a while to get onboarded to the system and able to properly describe the design. Eventually he was doing good work and got the project to the point where he wasn't needed but he left a bad taste in everyone's mouth. We could have hired two junior engineers to do the work he was doing for the same price and probably gotten it done much faster. After the guy transfered over to another project, we reamed out our PM about his hiring decision and begged him to give us some input next time. Of course, due to the waste of money from the last guy, the functional managers stopped taking hiring inputs from our project and would just assign whoever the fuck they thought we needed despite the kind of roles we actually needed.
I've had a few startup jobs, a couple megacorp jobs (not Apple), and a handful of mom and pop and defunct business jobs as well.
My least favorite interview questions involve regex or deep internals of BSD or Linux, my favorite interview questions are off the cuff solutions to problems presented, and then backtracking the explanation.
I've also been asked to perform job interviews for positions that i probably ought know enough about to interview a candidate for, but I went off my gut feeling about how the person acted in what i consider a stressful situation (a slew of interviewers asking asinine questions). I don't like interviewing, i am not very good at finding candidates that are "in for the long haul" but every time we were tasked with finding someone who can do X before end of Q3, my hired candidate recommendations always nailed it in that time frame. All this is to say, i find the whole process ridiculous. My CV apparently looks like a train wreck. I refuse to wear a tie or get a haircut. I'm eerily relaxed in interview situations.
My trick? one time i hung out with a CEO of an IT company from the PNW, and they basically told me everything i thought i knew was trash, my resume was trash, my attitude was trash, and the only thing i was good at was solving problems in a hurry. We did, in fact, get coffee for our meetup. I scrapped every idea of what a resume should look like - what i envisioned a perfect professional resume looked like - and started fresh. I learned to say no to most recruiters in a way that made them ask me about different "opportunities" more aligned with my personal ethics and values in the future.
I have 4 FPGAs, and i've never done anything with them, because the bitstream is proprietary on all of them. I wouldn't hesitate to tell an interviewer that i am interested in FPGAs and custom ASICs, because i am. I'm also interested in bacteria, but i won't be applying to a bioscience lab anytime soon. I certainly wouldn't say "yeah i can program an FPGA", or C, or do front end development, or any of that.
From my reading of these sorts of comments, in aggregate, most people try to impress the interviewers. I want them to impress me.
Does this make me privileged? Probably. <sigh>
On the other hand, I have reviewed resumes from people with five years of experience that are 'experts' at twenty five unrelated technologies. As soon as I see that, I think, 'yeah..... no'. I worked with some genius level folk at Bell Labs back in the mid 1990s, ten years into my career, and they were each really good at two or three things. I took note of that. Yes, they could figure other stuff out, they could move on to new technology, updating the three things that they were good at, but that list always seemed to be short.
You have to laugh at 'experienced' or 'expert at' followed by JS, JAVA, Full Stack, Python, Linux, BSD, C#, AWS, C, C++, MySQL, PostGRES, Lisp, Lua, Azure, MathCAD, DSP, AI, Excel, SystemC, Perl, regex, Bash, git, assembly, Verilog, ...
[0] https://www.joelonsoftware.com/2006/10/25/the-guerrilla-guid...
We've had candidates with "20 years of experience" completely unable to do what amounts to "call a web service, deserialize some json, write a couple for loops and if statements, and post back some json to a web service" in over an hour, or in a take home scenario.
It will never cease to amaze me that there are people employed in this field that just. can. not. program.
At my previous company, we had a technical assessment - this was about ten years ago now. It boiled down to: read XML, do some math / business logic, and build a REST API to do so.
Interestingly, ten years ago, at least half the applicants said they found it interesting because they had never worked with REST or JSON before. A lot were Java developers, so the XML part wasn't a problem, and they would often add some SQL database as a bonus.
But 5-10 years later, as development switched to (Node)JS and web, it became the inverse and people said they had never done anything with XML before.
Add "This person doesn't know about my firm's hiring process, aren't willing to do basic tasks, doesn't want to work at my firm," etc.
There are just too many niches where the knowledge we each consider necessary simply isn't. I had one particularly bad interviewer grill me on how the ARM GIC worked in detail (e.g. interconnect details, differences between versions, etc) because they considered it basic knowledge. I've personally never needed to know anything about it that wasn't in a TRM.
One question I have found useful in embedded development is asking someone to discuss the difference between a thread and a process, and the difference between thread based OSs and process based OSs. It is a general question, not bound by anything like CPU architecture, but just gives an idea into whether the person is comfortable about general memory domains.
I have mentored people, bright programmers that never worked in small embedded systems, that initially tripped all over the thread model, but eventually came to understand it.
Yes.
But I think there's a reasonable upper limit to the amount of time a company can expect someone to spend on a job opportunity.
If they're burning an appreciable amount of that time on a trivial coding exercise, that's not great.
You're missing the point.
The premise is that someone capable can blast through trivial assignments in no time. Either this is the final proficiency challenge or there are subsequent, harder questions. In the former case, why not see the salary/offer and then decide?
I have a GitHub profile with a lot of code on it and on my resume I highlight projects I've done a lot of work on. "What if faked tho?"--there's literally too much there to be worth faking. If a hiring manager looks at my resume, has the option of going to my GitHub profile, and between the two goes "I'm going to hand him a college-level Java problem because I'm not sure," then there probably isn't a way we're going to work together. And that's okay, on both sides of it; there are a lot of developers who aren't bothered by that kind of low-trust relationship. I am. Not a fit.
(This is in contrast to, for example, asking a question like that during an interview. Interviews are bidirectional, and are showing an investment in the hiring process on the part of the employer. If a card-deck Java problem is worth addressing with my time, then it's worth addressing with your interviewer's time. The contrapositive is also true.)
However, I do understand where the offline exercise idea comes from - it's not necessarily about lack of respect for candidates' time, but is generally done with the best of intentions in response to feedback, because candidates complain that the interview technical exercise scenario is needlessly artificial: in a live interview candidates do not usually have easy access to their usual tools or Google/Stackoverflow, and many feel pressure and panic from having to code/problemsolve live while someone is watching and feel they would do better if left alone to do the same thing for the same length of time.
Given the incredibly strong feelings either way, perhaps it might not be a terrible idea to let people choose which approach they prefer; but I've never seen any company's hiring do that, though, thinking about it, there really is no good reason why not (provided I still get to talk through the results of the offline exercise with the candidate during the live bit!)
Making it an option for somebody who would rather wouldn't be bad, but yeah, as you say, nobody's learning a lot about the other people that way, and they're probably more important.
(The OP's card deck problem is just faintly ridiculous and a bad allocation of the candidate's time, and I assume there are more hoops to jump through afterwards.)
> If a hiring manager looks at my resume, has the option of going to my GitHub profile, and between the two goes "I'm going to hand him a college-level Java problem because I'm not sure,"
I know we're talking hypotheticals. I get your position 100%, and good for you.
My view is that I'd tell you that
1. I've seen your Github profile
2. However, I didn't have time to go through your entire Github profile looking at your efficiency and productivity. I want to do a quick, ad-hoc programming exercise to see how fast you operate on basic tasks (which #1 doesn't readily address). I expect you to crush it really fast and this is the only coding exercise I'll have you do.
To me, that doesn't seem unreasonable if I'm upfront about expectations. Your response will also say a lot about you (not necessarily negative, but for fit).
These requirements come up because someone always slips through diligence. While you might be getting punished, interviewers are trying to de-risk candidates as much (and as fast) as possible.
Right. And to do so in good faith, this absolutely can and should be a collaborative exercise with an interviewer. It demonstrates that the employer has skin in the game and isn't body-shopping. Once you're out of junior/low-mid hiring, this is really, really important to getting quality candidates to go through your funnel.
> interviewers are trying to de-risk candidates as much (and as fast) as possible.
Of course they are. They should also be aware of the tradeoffs in doing so.
Although I experienced recently what you said exactly! I was asked to build a deck of cards for the screening interview. It was a fun back-and-forth and I felt really good about things. Then in the next steps, I was asked to implement Conway's Game of Life. So like, I've been programming professionally for 13 years, I'm well aware of GoL and maybe should know how to do it, but I've never bothered since there are just a mountain of other projects, programming and not, that interest me over that. It's all good if you want your engineers to be able to solve that type of problem as it's your company and you do what you like with it. But like, they were an e-comm company and I have a ton of e-comm experience and was actually pretty into what they were doing, so why were they using something like GoL to assess me?
On the flip side of things to get a little tangential, I often feel companies reject me because they just don't like me, and I wish they would just say as much since that hurts way less than being told I'm a not a great engineer, lol.
Anyway, maybe a bit too much TMI... interviewing right now is a bit of a shitshow with all the recent layoffs and I'm maybe a little bitter, but also realllllly enjoying unemployment while it lasts.
If the first, that sounds like a terrible question. If the second, that sounds like a quite straightforward fizbuz style coding task.
> I'm well aware of GoL and maybe should know how to do it
What do you mean “should know how to do it”? I don’t think you should have memorised the rules, or an implementation. But I think if you are a software developer you should be able to turn human language into code. That is a key skill of the job.
Recruiters and subsequently hiring teams are often told they can't give much actual feedback to candidates, out of a fear for legal challenges. I cannot assess the validity of these fears, just relaying what I heard. I guess folks have been burned when their presumably-good faith attempts at feedback were twisted into inclusion and equal opportunity cases (which are also important subjects that I don't want to dismiss either).
Sure there are different ways to do this but it's a small enough task that the quality of the solution is easy to judge.
I think the nail analogy works. If a blacksmith can't make a decent nail he shouldn't be hired. Same if a developer can't use one of a few very well-known standard library data structures to implement a deck of cards.
Are there any good ones? I find that people introduce an analogy...it is discussed, another 'contradictory' analogy is introduced....and eventually someone has 'won' the argument referring to something completely unrelated, and thereby have 'won' the original argument, by default.
My boss is particularly good at his :-) To me, its a form of gaslighting.
As soon as i hear "But what if...?", or "it's as if...", I refuse to budge, and simply ask "Are we talking about 'the original subject', or 'Blacksmiths'? If it's the latter, let's talk about Japanese swordsmanship first, then the history of European metallurgy first - just to be on the same page."
Often used at the same time is the No True Scotsman fallacy.
Set ridiculous boundaries on the analogy, ignore the fallacies, and the original subject soon gets re-discussed. It's amazing how many people actualy find that uncomfortable.
This task is just a pre-filter, something to weed out surpirsingly high number of people who claim to be able to code but actually can't.
https://news.ycombinator.com/item?id=33739094
It's still archived, though:
https://web.archive.org/web/20221119032911/https://overemplo...
and
https://web.archive.org/web/20221116023708/https://overemplo...
Key takeaways:
> I started learning to code in 2019 as my new years resolution.
> Job #1 Senior front end dev
> Job #2 Senior front end engineer
> Job #3 Front end engineer (mid-level)