-
Managed by Q is hiring engineers and product managers. We’re building software to run, create, and manage office space. We also employ thousands of maintenance and cleaning operators who make a living wage + benefits, since we believe in providing good jobs for people.
If you’re interested in building a company that believes in sustainable employment and helps small businesses while building interesting tech, get in touch! We have an engineering team of about 20 people in SoHo, NYC. I’m an engineer at the company – email me (eseidohl at our domain) if you have questions or want to talk about MbQ!
-
Do these ghost characters have a sound that goes with them? Or are they completely meaningless?
-
It looks like 彁 might be pronounced sei ka, but I’m not sure where that pronunciation comes from. https://en.wiktionary.org/wiki/%E5%BD%81
-
-
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.
-
-
Other important political aspect of Material Design (and some other UI/web styles that are popular now) is “minimalism”. Your UI should have few buttons. User should have no choices. User should be consumer of content, not a producer. Having play and pause buttons is enough. User should have few choices how and what to consume — recommender system (“algorithmic timeline”, “AI”) should tell them what to consume. This rhetoric is repeated over and over in web and mobile dev blogs.
Imagine graphics editor or DAW with “material design”. It’s just nearly impossible. It’s suitable only for scroll-feed consumption and “personal information sharing” applications.
Also, it’s “mobile-first”, because Google controls mobile (80% market share or something like that). Some pages on Google itself (i.e. account settings) look on desktop like I’m viewing it on giant handset.
P.S. compared with “hipster” modernist things of ~2010, which often were nice and “warm”, Material Design looks really creepy for me even when considering only visual appearance.
-
-
Not sure if such design languages exist, but from what I’ve seen, I have feeling that every “industry” has its own conventions and guidelines, and everything is very inconsistent.
- Word processors: lots of toolbar buttons (still lots of them now, but in “ribbons” which are just tabbed widgets). Use of ancient features like scroll lock key. Other types of apps usually have actions in menus or in searchable “run” dialogs, not toolbar button for each feature.
- Graphics editors: narrow toolbars with very small buttons (popularized by both Adobe and Macromedia, I think). Various non-modal dialogs have widgets of nonstandard small size. Dark themes.
- DAWs: lots of insane skeuomorphism! Everything should look like real synths and effects, with lots of knobs and skinning. Dark themes. Nonstandard widgets everywhere. Single program may have lots of multiple different styles of widgets (i.e. Reason, Fruity Loops).
- 3D: complicated window splits, use of all 3 mouse buttons, also dark themes. Nonstandard widgets, again. UI have heritage from Silicon Graphics workstations and maybe Amiga.
I thought UI guidelines for desktop systems (as opposed to cellphone systems) have lots of recommendations for such data editing programs, but seems that no, they mostly describe how to place standard widgets in dialogs. MacOS guidelines are based on programs that are included with MacOS, which are mostly for regular consumers or “casual office” use. Windows and Gnome guidelines even try to combine desktop and mobile into one thing.
Most “editing” programs ignore these guidelines and have non-native look and feel (often the same look-and-feel on different OSes).
-
I’d suggest–from time spent dealing with CAD, programming, and design tools–that the biggest thing is having common options right there, and not having overly spiffy UI. Ugly Java swing and MFC apps have shipped more content than pretty interfaces with notions of UX (notable exceptions tend to be music tools and DAW stuff, for reasons incomprehensible to me). A serious tool-user will learn their tooling and extend it if necessary if the tool is powerful enough.
-
-
We had a great post about two months back on pie menus. After that, my mind goes to how the Android app Podcast Addict does it: everything is configurable. You can change everything from the buttons it shows to the tabs it has to what happens when you double-click your headset mic. All the good maker applications I’ve used give me as much customization as possible.
-
It’s identical to the material design guidelines but with a section on hotkeys, scripts, and macros.
-
-
-
Stuff like Bootstrap mentioned there, early Instagram, Github. Look-and-feels commonly associated with Silicon Valley startups (even today).
These things usually have the same intentions and sins mentioned in this article, but at least look not as cold-dead as Material Design.
-
-
Bootstrap lookalikes?
-
-
-
This seems off-topic to me. A company is moving, what’s technical about that?
-
-
You’re correct. If it had more information about the logistics of, say, outfitting their new network infra or whatever, that’d be one thing–as it is, it’s a press release. Good catch.
-
-
General rule Ive observed is on/off topic isn’t worth mentioning if it has a lot of upvotes. Many readers already voted for it yo be here at that point. On top of that, several high-voted submissions happened while the people were at RC. That boosts popularity further.
-
-
I’m getting an HTTPS error
-
-
This looks really cool, the quality of the talks looks amazing. I kinda want to submit but I’m afraid I won’t be able to pull together something awesome enough.
-
-
Oh boy, I have a lot of feelings about this. Good on the author for bringing it up.
Junior developers (having been one) are amazing to have around and, if handled properly, are a major force multiplier.
Personally observed benefits of junior devs:
- They are hungry. They are looking to get that paycheck, no matter how small it is compared to a senior developer, and since they’re often hourly they’ll actively look for additional work to do if managed properly to pad out beer money or rent or childcare or family care or whatever. Senior devs begin playing a game (if they’re smart) of “I am salaried…how can I exert minimum effort for maximum possible revenue?” Senior devs also know themselves better, and so they can often say “Yeah, $X is enough, I don’t see the personal upside in taking on more work even with a pecuniary benefit”.
- They don’t know what is hard and what isn’t. They are juniors, and so they attack tasks (architectural and scutwork) with near equal optimism. You can give them something that’s impossible and they’ll come back with solutions that actually are good-enough fudges for business purposes.
- They want to learn. The only way to become a senior developer is by learning things, and a lot of junior devs have a chip on their shoulder (acknowledged or not) about not knowing enough–so, they’ll go do new things and learn about them and try to show off that learning. Senior devs often go with tried-and-true knowledge because they know how to execute most quickly with it; a junior dev can help uncover better solutions that would be ignored otherwise.
- They might know things you don’t. Hell, I learned React in from an excellent junior dev.
- They’ll stick around longer. Similar to being hungry, the friction for a junior dev to switch companies is higher (they underestimate their own knowledge and value, remember?) than for a senior dev. So, if you display even marginal competence and compassion towards them, they probably won’t jump ship. Also, their pay scale starts so much lower so that you can keep giving real raises without worrying about breaking the bank.
However, there are severe pathologies to junior devs:
- They suffer extra from morale-stressing situations (modulo life experience). A junior dev can get stuck in a project or stuck with a bad situation and really just ground down by it, where in the same place a senior might go “well, this sucks, but we can see it through”. They haven’t had a lot of history of failed and successful projects, so they can take things too hard.
- They love learning new things, and want to try them out all the time. Until trained properly, junior devs have very little conservatism in their engineering. They’ll switch from Backbone to Angular to React because they’re learning new and exciting things–even if the original domain just needed a static server-side page.
- They are really bad at software estimates. Like, even moreso than normal, because they lack the breadth of experience to know what paths in a project are probably most filled with spiders and which ones are tedious but quick.
- They are bad at managing others. Juniors are just barely getting their own career and projects in order, and usually lack the technical, political, and engineering proficiency to organize and communicate effectively with others in a leadership role. This does not mean they shouldn’t (with careful and direct supervision) be forced into it–after all, that’s how they learn!
- Modulo life experience, they focus on tech more than customers. Due to their desire for knowledge and improvement, they often miss the essential chatting with customers/users of a software project that can pull out hidden requirements or even allow for shipping partially complete work.
- They can make a huge mess. Given credentials to production system, or given large foundational architecture work, juniors can do bizarrely well-intentioned things that result in total chaos. Seniors can (and do!) have the same problems, but they’re usually more likely to ask for help or exercise caution.
- Modulo life experience, they don’t understand themselves. Juniors have a hard time spotting when they’re getting overloaded or burned out, and they have a hard time figuring out why they feel a certain way about technical and interpersonal conflicts. This results in communication problems, chaos, and general bad vibes until addressed.
- They will dutifully reproduce the dev practices around them. So, if all of the example code for solving something does weird shit, juniors will dutifully continue doing weird shit. If the build process is crackheaded and error-prone, the juniors will dutifully keep running it and running into problems and, as noted above, probably continue creating problems. And they’ll teach other more-junior devs to do the same!
I’ve got thoughts on the care and feeding of junior devs, but this post is already rather long.
-
Thanks for sharing this, you’ve crystallized a lot of my own thoughts on junior devs excellently. I taught at a bootcamp for a while, and my favorite thing about new dev you summed up as, “They don’t know what is hard and what isn’t.” It was so cool to see these fresh students attack problems that I would have immediately dismissed simply because they didn’t know how hard it was. I think this is an excellent lesson for senior devs as well, a kind of “beginner’s mind” that’s hard to obtain.
I think any project is like this: if you knew how tough it would be at the end, you probably wouldn’t have started it. Our ability to over- and under- estimate can sometimes be a huge boon.
-
-
It’s not totally independent of the items you’ve listed, but one thing I’ve noticed about juniors is that they also don’t stop to think whether the things they build upon are designed to be taken to scale. So with juniors around, it can be dangerous to say “OK, let’s embrace the fact that we have 5-10 of these things currently, so we’ll do something quick that relies on this fact, and we’ll switch to something more sensible when we need to scale in this direction.”. The moment you look away, you’ll find that a junior has written a script to auto-generate thousands of those things and built an entire structure around it without questioning whether the rest of the system was ready for it (however obvious that might seem to you).
I think the broader point here is that juniors are much more susceptible to tunnel vision, where they only focus on what they’re trying to solve at a given moment without considering the big picture.
-
I thought this was about rxjs Observables until I got to the end and it wasn’t…
-
There are a lot of great blog posts written by ‘recursers’. Those posts are usually spread out on different blogs though. Does anyone know if they are aggregated somewhere?
-
-
FYI, other projects call this their planet. See http://planet.mozilla.org/ or http://planet.debian.org/ or http://planet.ubuntu.com/
-
-
I’d really like this.
-
-
I was just thinking today that a huge benefit of doing Recurse Center was exposure to so many great blogs/bloggers I otherwise wouldn’t have encountered.
-
-
I’m one of the organizers of !!Con in New York City, an annual programming conference about to be in its fifth year. if you’re interested, I’d be happy to answer any questions you have either here in the comments, or DM me and we can set up a time to chat. :)
-
Thanks! I will reach you as soon as I finish working. I am a big fan of the !!Con, I hope you can upload the 2017 videos :)!
-
Thanks for the reminder, we’ve had a PR open for that for a long time that you just prompted me to merge :|
-
-
My personal favorite is http://thecodelesscode.com/case/41 – I quote it at anyone who tries to comment out chunks of code in production.