-
I’m trying to convince my workplace to get rid of whiteboarding interviews, does anyone know if there are resources for ideas of alternatives? Anyone have a creative non-whiteboarding interview they’d like to share?
-
The best that I’ve found is to just ask them to explain some tech that’s listed on their resume. You’ll really quickly be able to tell if its something they understand or not.
My team does basic networking related stuff and my first question for anyone that lists experience with network protocols is to ask them to explain the difference between TCP and UDP. A surprising number of people really flounder on that despite listing 5+ years of implementing network protocols.
-
This is what I’ve done too. Every developer I’ve ever interviewed, we kept the conversation to 30min-1hr and very conversational. A few questions about, say, Angular if it was listed on their resume, but not questions without any context. It would usually be like- “so what projects are you working on right now? Oh, interesting, how are you solving state management?” etc. Then I could relate that to a project we currently had at work so they could get a sense of what the work would be like. The rapid-fire technical questions I’ve find are quite off-putting to candidates (and off-putting to me when I’ve been asked them like that).
As a side note, any company that interviews me in this conversational style (a conversation like a real human being) automatically gets pushed to the top of my list.
-
-
-
-
-
I like work examples, open ended coding challenges: Here’s a problem, work on it when you like, how you like, come back in a week and lets discuss the solution. We’ve crafted the problem to match our domain of work.
In an interview I also look out for signs of hostility on the part of the interviewer, suggesting that may not be a good place for me to work.
-
-
-
-
A sample of actual work expected of the prospective employee is fair. There are pros and cons to whether it should be given ahead of time or only shown there, but I lean towards giving it out in advance of the interview and having the candidate talk it through.
Note that this can be a hard sell, as it requires humility on the part of the individual and the institution. If your organization supports an e-commerce platform, you probably don’t get to quiz people on quicksort’s worst-case algorithmic complexity.
-
I certainly don’t have code just sitting around I could call a sample of actual work. The software I write for myself isn’t written in the way I’d write software for someone else. I write software for myself in Haskell using twenty type system extensions or in Python using a single generator comprehension. It’s for fun. The code I’ve written for work is the intellectual and physical copy of my previous employers, and I couldn’t present a sample even if I had access to it, which I don’t.
-
Yup, the code I write for myself is either 1) something quick and ugly just to solve a problem 2) me learning a new language or API. The latter is usually a bunch of basic exercises. Neither really show my skills in a meaningful way. Maybe I shouldn’t just throw things on GitHub for the hell of it.
-
Oh, I think you misinterpreted me. I want the employer to give the employee some sample work to do ahead of time, and then talk to it in person.
As you said, unfortunately, the portfolio approach is more difficult for many people.
-
-
-
-
I recently went through a week of interviewing as the conclusion of the Triplebyte process, and I ended up enjoying 3 of the 4 interviews. There were going to be 5, but there was a scheduling issue on the company’s part. The one I didn’t enjoy involved white board coding. I’ll tell you about the other three.
To put all of this into perspective, I’m a junior engineer with no experience outside of internships, which I imagine puts me into the “relatively easy to interview” bucket, but maybe that’s just my perception.
The first one actually involved no coding whatsoever, which surprised me going in. Of the three technical interviews, two were systems design questions. Structured well, I enjoy these types of questions. Start with the high level description of what’s to be accomplished, come up with the initial design as if there was no load or tricky features to worry about, then add stresses to the problem. Higher volume. New features. New requirements. Dive into the parts that you understand well, talk about how you’d find the right answer for areas you don’t understand as deeply. The other question was a coding design question, centered around data structures and algorithms you’d use to implement a complex, non-distributed application.
The other two companies each had a design question as well, but each also included two coding questions. One company had a laptop prepared for me to use to code up a solution to the problem, and the other had me bring my own computer to solve the questions. In each case, the problem was solvable in an hour, including tests, but getting it to the point of being fully production ready wasn’t feasible, so there was room to stretch.
By the time I got to the fourth company and actually had to write code with a marker on a whiteboard I was shocked at how uncomfortable it felt in comparison. One of my interviews was pretty hostile, which didn’t help at all, but still, there are many, far better alternatives.
-
-
There are extensive resources to help with the evangelism side of things.
-
-
ccleary00
4 months ago
|
link
| on:
Tech Culture Shock: From America to the South Pacific, and Seattle to Chicago
As someone who just went through the interviewing process in Chicago, this pretty much mirrors my experience exactly. I will say though that I did not mind recruiters having me meet with their whole team as I felt like they were able to get a better sense of what I was looking for in my next position. I too am baffled at the IP clause/non-competes in Chicago too… it’s quite unfortunate
-
N64N64
edited
8 months ago
|
link
| on:
Why do some developers at strong companies like Google consider Agile development to be nonsense?
[Comment removed by author]
-
-
-
-
I think the problem is he speaks pretty authoritatively despite his expertise being based on just his experiences, or his perception of his experiences. It sounds good, but a lot of things sound good and are only occasionally true, not always true.
I used to think he was just idiosyncratic til I had an experience that contradicted his claims, and then he just said “wait til you enter the real world.” I’m actually a few years older than him I believe. He’s incapable of imagining that things may be different. Even if he were right, it’s a very rigid view that doesn’t account for contrary evidence. I’m wary of trying to learn anything from people like that.
-
-
-
He showed himself to be pretty out there at Google, when he rage-quit with a particularly nutty letter to the entire company after not getting a promotion.
It wasn’t about not getting a promotion. I was marked down in “Perf” for speaking up about an impending product failure. (Naively, I thought that pointing out the problem would be enough to get it fixed. It was obvious to me what was about to go wrong– and I was later proven right– but I lacked insight into how to convince anyone.) I found out years later that I was put on a suspected unionist list. Needless to say, the whole experience was traumatic. There’s a lot that I haven’t talked about.
The mailing list activity… I’m embarrassed by that. I did not handle the stress well.
Lots of bits of that letter were memes when I left Google (“I have T7-9 vision!”).
Isn’t it a sign of success, if people are talking about your mistakes several years later?
-
-
Personally I think Michael O Church is a genius but I’m keenly aware that there’s a fine line between genius and madness. /u/churchomichael is not Michael O Church but seems to be another very intelligent writer but without the anger and national and international politics interest.
-
doing some digging he seems….. crazy.
I’ve had a lot of difficult experiences, some related to the political exposure that comes from being outspoken in a treacherous industry. I’ve needed treatment for some of the after-effects.
Like, he got banned from Hacker News, and also Wikipedia.
And Quora, too! Wikipedia I actually deserved; that was 2006 and I was being a jerk. The Quora ban was specifically requested by Y Combinator after they bought it.
He just seems to spend an insane amount of time writing ranty comments/articles/etc online and not much else.
It’s not that much of my time.
See /u/churchomichael
That’s not me. I’m as surprised as you are that someone would name his account in homage to me. There are also Reddit accounts (and even a subreddit!) that exist to mock me.
Dude just seems to want to complain.
No, I’d like to fix things, but the odds of that are very, very poor.
He has 45 suspected sockpuppet accounts on Wikipedia
Yeah, most of those accounts don’t exist. That’s a hit piece. I’m embarrassed by some of what I did on Wikipedia in 2003-6, but I never had 45 alternate accounts, though I did use so-called “role accounts” back when it was accepted.
-
-
babak
8 months ago
|
link
| on:
Why do some developers at strong companies like Google consider Agile development to be nonsense?
Businesses tend to derail software development practices because they tend to view it as “hip brand name for how we exert power over employees”.
They will hang on to small pieces of a methodology as a cover for something else.
For example they may weaponise “daily agile standup meeting” for micro-management.
-
-
ccleary00
8 months ago
|
link
| on:
Why do some developers at strong companies like Google consider Agile development to be nonsense?
I think it’s important to ask why Agile is so easy to screw up. We don’t want fragile software applications and certainly shouldn’t want fragile software methodologies either.
-
imho if agile fails, it usually is because people applied some Agile workflow (like Scrum) while losing orientation of the goals these methods want to achieve. For example:
- User stories are unclear / badly written. This is probably a very overlooked problem, but I have seen it many times. Sometimes the wording is not understandable at all, or no acceptance criteria are defined, or they spell out the technical realization instead of the functional requirement, leaving no room tfor engineers to find a better solution / architecture for the change. The solution is to have good refinement meetings were devs read and challenge stories, ask questions, get the PO to remove implementation advice but add intent of functionality and demand proper acceptance criteria.
- Backlog is prioritized sloppily by the PO, this is especially harmful if it is done in a way that delays an initial break through of getting a prototype up and running.
- Confusing “Agile” for only planning the next two weeks. Doing scrum does not mean that you shouldn’t think about a roadmap or plan for the next year. However, it is important to plan on a much coarser level for long -term planning, and not stick to plans that are obsoleted by reality.
- Lousy estimation. Many people think estimation is about planning, and that is partially right. However, estimation is also an indicator for whether a story is well-written. If 2 devs estimate a different workload for a story, chances are good that the story is not clear on what should be done.
-
Is Agile more or less easy to screw up than any other methodology? It could be that all methodologies are hard to follow; I remember reading that the most development popular process in practice (at 60% of those surveyed) was “no process”.
IME Agile mostly gets screwed up by not actually doing it - or by falling back to non-Agile as soon as anything goes slightly wrong. I suspect this is simply a case of people responding to their incentives; management is rewarded for claiming to adopt Agile, but has very little incentive to actually follow it.
-
-
Spiral, Chaos, Unified Method, OOSE, Rational Unified Process… there are few, and while some of them (looking at you RUP) are widely known to be terribad I don’t think all of the others can be dismissed out of hand. One of the challenges is that research into it kinda stopped (TtBoMK) after Agile went big.
-
When I read comments criticising Agile, I often feel that the commenters would rather like to work on their own plans, i.e. with a goal in mind, start implementing and provide a solution. So it would probably be unfair to dismiss all of these attempts as chaos, but from what I have seen it requires above-average people to work. If it works, the work shows all signs of Agility (prioritization, delivering increments, working software over documentation, people over processes, etc.).
I have also seen truly chaotic development that was a pure waste. Also not pretty, and every time I read a critic of Agile, I worry that people would rather work this way.
-
-
-
-
-
Not only do companies doing the interviewing need to change the process, I think developers looking for jobs should start refusing to go through the whole whiteboard trivia nonsense. If that reached critical mass, companies would change their interview process real quick.
-
How many job seekers really want to reject an opportunity over something annoying? When the bills are due and you need health insurance, that’s a rather bold move.
I could only see people with big amounts of savings doing this, and it’d only matter if they were obviously qualified. Otherwise, the recruiting team would shrug and move on, and the job seeker is left wondering if they made a huge mistake. There’s an obvious power dynamic here that can’t be ignored.
-
That might be true if you’re unemployed and short on options, but often I find people interviewing are already employed and looking to make a change. So for them, saying no just means staying at $CURRENT_JOB a bit longer.
-
-
-
-
-
ccleary00
9 months ago
|
link
| on:
Adventures in Programming Interviews: Misleadingly Simple NP-Hard Problem
This was an interesting puzzle, but I don’t really know why people continue to entertain these kinds of questions in interviews. To be fair, it’s possible the job required heavy use of algorithms, but as such a high percentage do not, at least not for day-to-day work, it seems kind of ridiculous.
I think developers collectively shoot themselves in the foot when we take part in such ceremonies and reduce the business value we bring to companies.
This quote from the article is truly disgusting to me - “This specific interview significantly hurt the offer I received. Unfortunately, there’s a lot of luck to the interview process as there is a lot of luck in life.” WTF?? The only thing more preposterous than the fact that messing up this problem hurt the offer is that this guy accepted that as his lot in life.
-
I like Lorin Hochstein’s quote on cycle detection algorithms: “I’m not a fan of expecting interviewees to re-invent the algorithms of famous computer scientists on the spot”.
-
I’m considering making a hobby out of doing these interviews, heh.
-
-
cool - thanks!
-
I think it’s great that you posted this. More people should speak up about it. I also liked that you called out the potential for ableism. It’s ironic that an industry that professes to value diversity goes and shoots itself in the foot with exclusionary tactics like this.
I just found out the company I’m working for is setting up a 4month engagement to build an app with Pivotal, which is all XP. Im excited about the project but dreading having to do pairing 8 hours a day… funny thing is I’ve actually introduced a lot of pair programming into the company and am certainly a proponent of it but only for 1-2hrs a day and in certain situations (onboarding, difficult problems, etc).
-
-
Aside from this, the Mac keyboards just aren’t great on your wrists/hands/fingers to begin with. I switched to an ergo keyboard and mouse about a year ago and have been pretty happy with the change.
(for context: I’m a solid TDD believer and practitioner)
My worry with TDD marketing is that people really get stuck on the “test” word and misunderstand it as “write the kinds of tests you currently write…except before the application code” and that just confuses everyone because the TDD tests are very different from the kinds of unit tests one would typically write. Tests are just a vehicle for the practice and I think they’re used to drive TDD because we typically have infrastructure in place that runs the test code quickly and easily.
Either way, I like the framing that this post gives the practice as a versatile tool with many uses!
That’s an excellent way of describing it! I think you hit the nail on the head - people get tripped up on the “test” part of it.
When I’m “in the zone” with TDD it doesn’t even feel like writing tests at all really, it just becomes an extension of my design or coding process, and the “ceremony” or “separateness” of the tests kind of starts to fall away.
BDD (behavior driven development) kind of moves away from thinking of this as purely a testing practice, at least by using the word “behavior” rather than “test”, but I don’t think many people think of BDD as writing tests first.
I’ve often thought of TDD (and unit testing in general) as kind of like a visual design aid in which instead of a whiteboard or design doc, you visualize the problem by defining your inputs and your expected outputs. I might write another post similar to this one using the “visual learning” concept as a basis for another way of thinking about TDD.